RFC2164 日本語訳

2164 Use of an X.500/LDAP directory to support MIXER address mapping.S. Kille. January 1998. (Format: TXT=16701 bytes) (Obsoletes RFC1838) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                         S. Kille
Request for Comments: 2164                                  Isode Ltd.
Obsoletes: 1838                                           January 1998
Category: Standards Track

Killeがコメントのために要求するワーキンググループS.をネットワークでつないでください: 2164Isode Ltd.は以下を時代遅れにします。 1838 1998年1月のカテゴリ: 標準化過程

    Use of an X.500/LDAP directory to support MIXER address mapping

MIXERがアドレス・マッピングであるとサポートするX.500/LDAPディレクトリの使用

Status of this Memo

このMemoの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Copyright(C)インターネット協会(1998)。 All rights reserved。

1  MIXER X.400/RFC 822 Mappings

1 ミキサーX.400/RFC822マッピング

   MIXER (RFC 2156) defines an algorithm for use of a set of global
   mapping between X.400 and RFC 822 addresses [4].  This specification
   defines how to represent and maintain these mappings (MIXER
   Conformant Global Address Mappings of MCGAMs) in an X.500 or LDAP
   directory.  Mechanisms for representing OR Address and Domain
   hierarchies within the DIT are defined in [5, 2].  These techniques
   are used to define two independent subtrees in the DIT, which contain
   the mapping information.  The benefits of this approach are:

MIXER(RFC2156)はX.400とRFCの間で822のアドレス[4]を写像するグローバルのセットの使用のためのアルゴリズムを定義します。 この仕様はX.500かLDAPディレクトリでどのように、これらのマッピング(MCGAMsのMIXER Conformant Global Address Mappings)を表して、維持するかを定義します。 DITの中にOR AddressとDomain階層構造を表すためのメカニズムは[5、2]で定義されます。 これらのテクニックは、マッピング情報を含むDITの2つの独立している下位木を定義するのに使用されます。 このアプローチの恩恵は以下の通りです。

   1.  The mapping information is kept in a clearly defined area which
       can be widely replicated in an efficient manner.  The tree is
       constrained to hold only information needed to support the
       mapping.  This is important as gateways need good access to the
       entire mapping.

1. 効率的な方法でどれを広く模写できるかというマッピング情報は明確に定義された領域に保たれます。 木がマッピングをサポートするのに必要である情報だけを保持するのが抑制されます。 ゲートウェイが全体のマッピングへの良いアクセスを必要とするとき、これは重要です。

   2.  It facilitates migration from a table-based approach.

2. それはテーブルベースのアプローチから移行を容易にします。

   3.  It handles the issues of "missing components" in a natural
       manner.

3. それは自然な態度で「なくなったコンポーネント」の問題を扱います。

          An alternative approach which is not taken is to locate the
          information in the routing subtrees.  The benefits of this
          would be:

取られない代替的アプローチはルーティング下位木における情報の場所を見つけることです。 この利益は以下の通りでしょう。

Kille                       Standards Track                     [Page 1]

RFC 2164         X.500/LDAP Directory to Support MIXER      January 1998

ミキサー1998年1月にサポートするKille標準化過程[1ページ]RFC2164X.500/LDAPディレクトリ

        o  It is the "natural" location, and will also help to
           ensure correct administrative authority for a mapping
           definition.

o それは、「自然な」位置であり、また、マッピング定義のために正しい職務権限を確実にするのを助けるでしょう。

        o  The tree will usually be accessed for routing, and so it
           will be efficient for addresses which are being routed.

o 木がルーティングのために通常アクセスされるので、それは発送されているアドレスに効率的になるでしょう。

          This is not done, as the benefits of the approach proposed are
          greater.

提案されたアプローチの恩恵が、よりすばらしいので、これをしません。

   MCGAMs are global.  A MIXER gateway may use any set of MCGAMs.  A key
   use of the directory is to enable MIXER gateways to share MCGAMs and
   to share the effort of maintaining and publishing MCGAMs.  This
   specification and MIXER also recognise that there is not a single
   unique location for publication of all MCGAMs.  This specification
   allows for multiple sets of MCGAMs to be published.  Each set of
   MCGAMs is published under a single part of the directory.  There are
   four mappings, which are represented by two subtrees located under
   any part of the DIT. For the examples the location defined below is
   used:

MCGAMsはグローバルです。 MIXERゲートウェイはMCGAMsのどんなセットも使用するかもしれません。ディレクトリの主要な使用はMIXERゲートウェイがMCGAMsを共有して、MCGAMsを維持して、発行する取り組みを共有するのを可能にすることです。また、この仕様とMIXERは、すべてのMCGAMsの公表のための単一のユニークな位置がないと認めます。この仕様は、MCGAMsの複数のセットが発行されるのを許容します。 MCGAMsの各セットはディレクトリのただ一つの部分の下で発行されます。 4つのマッピングがあります。(マッピングはDITのどんな部分の下でも位置する2つの下位木によって表されます)。 例に関しては、以下で定義された位置は使用されています:

   OU=MIXER MCGAMs, O=Zydeco Plc,  C=GB

OUはミキサーMCGAMs、O=Zydeco Plcと等しく、CはGBと等しいです。

   These subtree roots are of object class subtree, and use the
   mechanism for representing subtrees defined in [1].

これらの下位木のルーツは、オブジェクトクラス下位木があって、[1]で定義された下位木を表すのにメカニズムを使用します。

   X.400 to RFC 822 This table gives the equivalence mapping from X.400
       to RFC 822.  There is an OR Address tree under this.  An example
       entry is:

RFC822ThisテーブルへのX.400はX.400からRFC822まで等価性マッピングを与えます。 これの下にOR Address木があります。 例のエントリーは以下の通りです。

       PRMD=Isode, ADMD=Mailnet, C=FI, CN=X.400 to RFC 822,
       OU=MIXER MCGAMs, O=Zydeco Plc,  C=GB

PRMD=Isode(ADMD=Mailnet、ミキサーC=FI、RFC822、OUへのCN=X.400=MCGAMs O=Zydeco Plc、C)はGBと等しいです。

   RFC 822 to X.400 There is a domain tree under this.  This table holds
       the equivalence mapping from RFC 822 to X.400, and the gateway
       mapping defined in RFC 1327.  An example entry is:

X.400 ThereへのRFC822はこれの下のドメイン木です。 このテーブルはRFC822からX.400までの等価性マッピング、およびRFC1327で定義されたゲートウェイマッピングを保持します。 例のエントリーは以下の通りです。

       DomainComponent=ISODE, DomainComponent=COM,
       CN=RFC 822 to X.400,
       OU=MIXER MCGAMs, O=Zydeco Plc,  C=GB

DomainComponent=ISODE(DomainComponent=COM、ミキサーX.400、OUへのCN=RFC822=MCGAMs O=Zydeco Plc、C)はGBと等しいです。

   The values of the table mapping are defined by use of two new object
   classes, as specified in Figure 1.  The objects give pointers to the
   mapped components.

テーブルマッピングの値は図1で指定されるように2つの新しいオブジェクトのクラスの使用で定義されます。 オブジェクトは写像しているコンポーネントに指針を与えます。

Kille                       Standards Track                     [Page 2]

RFC 2164         X.500/LDAP Directory to Support MIXER      January 1998

ミキサー1998年1月にサポートするKille標準化過程[2ページ]RFC2164X.500/LDAPディレクトリ

2  Omitted Components

2 省略されたコンポーネント

   In MIXER, it is possible to have omitted components in OR Addresses
   on either side of the mapping.  A mechanism to represent such omitted
   components is defined in Figure 2.  The attribute at-or-address-
   component-type is set to the X.500 attribute type associated with the
   omitted component (e.g.,

MIXERでは、マッピングのどちらかの側のOR Addressesでコンポーネントを省略したのは可能です。 そのような省略されたコンポーネントを表すメカニズムは図2で定義されます。 属性、-、-アドレスコンポーネント型が省略されたコンポーネントに関連づけられたX.500属性タイプに設定される、(例えば。

rFC822ToX400Mapping OBJECT-CLASS ::= {
    SUBCLASS OF {domain-component}
    MAY CONTAIN {
        associatedORAddress|
        associatedX400Gateway}
    ID oc-rfc822-to-x400-mapping}

rFC822ToX400Mappingは以下をオブジェクトで分類します:= SUBCLASS OFドメインコンポーネントMAY CONTAIN、associatedORAddress| associatedX400Gateway、IDのoc-rfc822からx400マッピング

x400ToRFC822Mapping OBJECT-CLASS ::= {
    SUBCLASS OF {top}
    MAY CONTAIN {                                                   10
        associatedDomain|
        associatedInternetGateway}
    ID oc-x400-to-rfc822-mapping}

x400ToRFC822Mappingは以下をオブジェクトで分類します:= SUBCLASS OFがMAY CONTAINを上回っている、10associatedDomain| associatedInternetGateway、IDのoc-x400からrfc822マッピング

associatedORAddress ATTRIBUTE ::= {
    SUBTYPE OF distinguishedName
    SINGLE VALUE
    ID at-associated-or-address}

associatedORAddressは以下を結果と考えます:= SUBTYPE OF distinguishedName SINGLE VALUE ID、関連づけるか、扱う。

                                                                    20
associatedX400Gateway ATTRIBUTE ::= {
    SUBTYPE OF mhs-or-addresses
    MULTI VALUE
    ID at-associated-x400-gateway}

20 associatedX400Gatewayは以下を結果と考えます:= SUBTYPE OF mhsかアドレスMULTI VALUE ID、関連x400ゲートウェイ

associatedDomain ATTRIBUTE ::= {
    SUBTYPE OF name
    WITH SYNTAX caseIgnoreIA5String
    SINGLE VALUE
    ID at-associated-domain}                                        30

associatedDomainは以下を結果と考えます:= SUBTYPE OFがWITH SYNTAX caseIgnoreIA5String SINGLE VALUEをIDと関連ドメインで命名する、30

associatedInternetGateway ATTRIBUTE ::= {
    SUBTYPE OF name
    WITH SYNTAX caseIgnoreIA5String
    MULTI VALUE
    ID at-associated-internet-gateway}

associatedInternetGatewayは以下を結果と考えます:= SUBTYPE OFはWITH SYNTAX caseIgnoreIA5String MULTI VALUEをIDと関連インターネットゲートウェイで命名します。

              Figure 1:  Object Classes for MIXER mappings

図1: MIXERマッピングのためのオブジェクトClasses

Kille                       Standards Track                     [Page 3]

RFC 2164         X.500/LDAP Directory to Support MIXER      January 1998

ミキサー1998年1月にサポートするKille標準化過程[3ページ]RFC2164X.500/LDAPディレクトリ

omittedORAddressComponent OBJECT-CLASS ::=
        SUBCLASS OF {top}
        MUST Contain {
                oRAddressComponentType
        }
        ID oc-omitted-or-address-component}

omittedORAddressComponentは以下をオブジェクトで分類します:= SUBCLASS OF先端がそうしなければならない、Contain oRAddressComponentType、IDの省略されたocかアドレス構成要素

oRAddressComponentType ATTRIBUTE ::= {
        SUBTYPE OF  objectIdentifier                                10
        SINGLE VALUE
        ID at-or-address-component-type}

oRAddressComponentTypeは以下を結果と考えます:= SUBTYPE OF objectIdentifier10SINGLE VALUE ID、コンポーネント型を扱ってください。

                Figure 2:  Omitted OR Address Component

図2: コンポーネントを省略するか、または扱ってください。

   at-prmd-name).  This mechanism is for use only within the X.400 to
   RFC 822 subtree and for the at-associated-or-address attribute.

prmd名、) そして、X.400だけの中にRFC822下位木にはこのメカニズムが使用のためにある、関連づけるか、扱う、属性。

3  Mapping from X.400 to RFC 822

X.400からRFC822までの3マッピング

   As an example, consider the mapping from the OR Address:

例と、OR Addressからのマッピングを考えてください:

   P=Isode; A=Mailnet; C=FI

P=Isode。 A=Mailnet。 CはFIと等しいです。

   This would be keyed by the directory entry:

これはディレクトリエントリによって合わせられるでしょう:

   PRMD=Isode, ADMD=Mailnet, C=FI, CN=X.400 to RFC 822,
   OU=MIXER MCGAMs, O=Zydeco Plc,  C=GB

PRMD=Isode(ADMD=Mailnet、ミキサーC=FI、RFC822、OUへのCN=X.400=MCGAMs O=Zydeco Plc、C)はGBと等しいです。

   and return the mapping from the associatedDomain attribute, which
   gives the domain which this OR address maps to.  This attribute is
   used to define authoritative mappings, which are placed in the open
   community tree.  The manager of an MCGAM shall make the appropriate
   entry.

そして、associatedDomain属性からマッピングを返してください。(それは、このORが地図を扱うドメインを与えます)。 この属性は、正式のマッピングを定義するのに使用されます。(マッピングは疎生群落木に置かれます)。 MCGAMのマネージャは適切なエントリーをするものとします。

   The Internet gateway mapping defined in MIXER[4] is provided by the
   associatedInternetGateway attribute.  This value may identify
   multiple possible associated gateways.  This information is looked up
   at the same time as mapped OR addresses.  In effect, this provides a
   fallback mapping, which is found if there is no equivalence mapping.
   Because of the nature of the mapping an OR Address will map to either
   a gateway or a domain, but not both.  Thus, there shall never be both

associatedInternetGateway属性でMIXER[4]で定義されたインターネット・ゲートウェイマッピングを提供します。 この値は複数の可能な関連ゲートウェイを特定するかもしれません。 この情報は写像しているORアドレスと同時に調べられます。 事実上、これは後退マッピングを提供します。(等価性が全くなければ、それは、写像しながら、見つけられます)。 マッピングの本質のために、OR Addressはゲートウェイかドメインをどちらかに写像しますが、ともに写像するというわけではないでしょう。 したがって、両方が決してないでしょう。

Kille                       Standards Track                     [Page 4]

RFC 2164         X.500/LDAP Directory to Support MIXER      January 1998

ミキサー1998年1月にサポートするKille標準化過程[4ページ]RFC2164X.500/LDAPディレクトリ

   an associatedDomain and associatedInternetGateway attribute present
   in the same entry.  Functionally, mapping takes place exactly
   according to MIXER. The longest match is found by the following
   algorithm.

associatedDomainとassociatedInternetGatewayは同じエントリーでプレゼントを結果と考えます。 ちょうどMIXERによると、機能上、マッピングは行われます。 最も長いマッチは以下のアルゴリズムによって見つけられます。

   1.  Take the OR Address, and derive a directory name.  This will be
       the OR Address as far as the lowest OU.

1. OR Addressを取ってください、そして、ディレクトリ名を引き出してください。 これは最も低いOUと同じくらい遠いOR Addressになるでしょう。

   2.  Look up the entire name derived from the MIXER key in the in the
       X.400 to RFC 822 subtree.  This lookup will either succeed, or it
       will fail and indicate the longest possible match, which can then
       be looked up.

2. コネで主要なMIXERから得られた全体の名前にほら、RFC822下位木へのX.400。 このルックアップが成功するか、それは、可能な限り長いマッチに失敗して、示すでしょう。(次に、それを見上げることができます)。

   3.  Check for an associatedDomain or associatedInternetGateway
       attribute in the matched entry.

3. 取り組んでいるエントリーにおけるassociatedDomainやassociatedInternetGateway属性がないかどうかチェックしてください。

   The mapping can always be achieved with two lookups.  Because of the
   availability of aliases, some of the table mappings may be
   simplified.  In addition, the directory can support mapping from
   addresses using the numeric country codes.

いつも2つのルックアップでマッピングを達成できます。 別名の有用性のために、テーブルマッピングのいくつかが簡素化されるかもしれません。 さらに、ディレクトリは、数値国名略号を使用することでアドレスからのマッピングをサポートすることができます。

4  Mapping from RFC 822 to X.400

RFC822からX.400までの4マッピング

   There is an analogous structure for mappings in the reverse
   direction.  The domain hierarchy is represented in the DIT according
   to RFC 1279.  The domain:

マッピングのための類似の構造が反対の方向にあります。 RFC1279に従って、ドメイン階層構造はDITに表されます。 ドメイン:

   ISODE.COM

ISODE.COM

   Is represented in the DIT as:

表されたコネは以下としてDITですか?

   DomainComponent=ISODE, DomainComponent=COM,  CN=RFC 822 to X.400,
   OU=MIXER MCGAMs, O=Zydeco Plc,  C=GB

DomainComponent=ISODE(DomainComponent=COM、ミキサーX.400、OUへのCN=RFC822=MCGAMs O=Zydeco Plc、C)はGBと等しいです。

   This has associated with it the attribute associatedORAddress encoded
   as a distinguished name with a value: PRMD=Isode, ADMD=Mailnet, C=FI

これは分類名として値でコード化された属性associatedORAddressをそれに関連づけました: PRMD=Isode、ADMD=Mailnet、CはFIと等しいです。

   The X.400 gateway mapping defined in MIXER[4] is provided by the
   associatedX400Gateway attribute.  This value may identify multiple
   possible associated gateways.  This information is looked up at the
   same time as mapped OR addresses.  In effect, this provides a
   fallback mapping, which is found if there is no equivalence mapping.
   Because of the nature of the mapping a domain will map to either a
   gateway or a domain, but not both.  Thus, there shall never be both
   an associatedX400Gateway and associatedORAddress attribute present in
   the same entry.  Functionally, mapping takes place exactly according
   to MIXER. The longest match is found by the following algorithm.

associatedX400Gateway属性でMIXER[4]で定義されたX.400ゲートウェイマッピングを提供します。 この値は複数の可能な関連ゲートウェイを特定するかもしれません。 この情報は写像しているORアドレスと同時に調べられます。 事実上、これは後退マッピングを提供します。(等価性が全くなければ、それは、写像しながら、見つけられます)。 マッピングの本質のために、ドメインは、ゲートウェイかドメインをどちらかに写像しますが、ともに写像するというわけではないでしょう。 したがって、associatedX400GatewayとassociatedORAddress属性が同じエントリーに提示する両方が決してないでしょう。 ちょうどMIXERによると、機能上、マッピングは行われます。 最も長いマッチは以下のアルゴリズムによって見つけられます。

Kille                       Standards Track                     [Page 5]

RFC 2164         X.500/LDAP Directory to Support MIXER      January 1998

ミキサー1998年1月にサポートするKille標準化過程[5ページ]RFC2164X.500/LDAPディレクトリ

   1.  Derive a directory name from the domain part of the RFC 822
       address.

1. RFC822アドレスのドメイン部分からディレクトリ名を得てください。

   2.  Look up this name in the RFC 822 to X.400 subtree to find the
       mapped value (either associatedORAddress or
       associatedX400Gateway.).  If the lookup fails, the error will
       indicate the longest match, which can then be looked up.

2. RFC822のこの名前をX.400下位木に調べて、写像している値(associatedORAddressかassociatedX400Gatewayのどちらか)を見つけてください。 ルックアップが失敗すると、誤りは次に、見上げることができる中で最も長いマッチを示すでしょう。

   If associatedORAddress is found, this will define the mapped OR
   Address.  The mapping can always be achieved with two lookups.  If an
   associatedX400Gateway is present, the address in question will be
   encoded as a domain defined attribute, relative to the OR Address
   defined by this attribute.  If multiple associatedX400Gateway
   attributes are found, the MTA may select the one it chooses to use.

associatedORAddressが見つけられると、これは写像しているOR Addressを定義するでしょう。 いつも2つのルックアップでマッピングを達成できます。 associatedX400Gatewayが存在していると、ドメインが属性を定義したので、問題のアドレスはコード化されるでしょう、この属性によって定義されたOR Addressに比例して。 複数のassociatedX400Gateway属性が見つけられるなら、MTAはそれが使用するのを選ぶものを選択するかもしれません。

   Because of the availability of aliases, some of the table mappings
   may be simplified.  In addition, the directory can support mapping
   from addresses using the numeric country codes.

別名の有用性のために、テーブルマッピングのいくつかが簡素化されるかもしれません。 さらに、ディレクトリは、数値国名略号を使用することでアドレスからのマッピングをサポートすることができます。

5  Gateway Selection of MCGAMs

5 MCGAMsのゲートウェイ品揃え

   The directory information to support identification of MCGAMs is
   given in Figure 3.  A MIXER gateway simply identifies the an ordered
   lists of MCGAM collections that it will use for lookup.  These are
   referenced by name.  A gateway is not required to use any MCGAMs.
   Where MCGAMs are accessed from multiple sources, it is recommended
   that all of the sources be accessed in order to determine the MCGAM
   which gives the

図3でMCGAMsの識別をサポートするディレクトリ情報を与えます。 MIXERゲートウェイが単に特定する、それがルックアップに使用するMCGAM収集の規則正しいリスト。 これらは名前によって参照をつけられます。 ゲートウェイは、どんなMCGAMsも使用するのに必要ではありません。MCGAMsが複数のソースからアクセスされるところでソースのすべてがMCGAMを決定するためにアクセスされるのが、お勧めである、どれ、付与

mixerGateway OBJECT-CLASS ::=
        KIND auxiliary
        SUBCLASS OF {mhs-message-transfer-agent}
        MUST Contain {
                mcgamTables
        }
        ID oc-mixer-gateway}

mixerGatewayは以下をオブジェクトで分類します:= KINDの補助のSUBCLASS OF mhs-メッセージ転送エージェントがそうしなければならない、Contain mcgamTables、ID ocミキサーゲートウェイ

mcgamTables ATTRIBUTE ::= {                                         10
        WITH SYNTAX SEQUENCE OF DistinguishedName
        SINGLE VALUE
        ID at-mcgam-tables}

mcgamTablesは以下を結果と考えます:= 10WITH SYNTAX SEQUENCE OF DistinguishedName SINGLE VALUE ID、mcgamテーブル

             Figure 3:  Object Classes for MCGAM selection

図3: MCGAM選択のためのオブジェクトClasses

best match.

最もよく合ってください。

Kille                       Standards Track                     [Page 6]

RFC 2164         X.500/LDAP Directory to Support MIXER      January 1998

ミキサー1998年1月にサポートするKille標準化過程[6ページ]RFC2164X.500/LDAPディレクトリ

6  Acknowledgements

6つの承認

   Acknowledgements for work on this document are given in [3].

[3]でこのドキュメントへの作業のための承認を与えます。

References

参照

   [1] Kille, S., "Representing tables and subtrees in the X.500
       directory", RFC 1837, August 1995.

[1]Kille、S.、「X.500ディレクトリのテーブルと下位木を表します」、RFC1837、1995年8月。

   [2] Kille, S., "Representing the O/R Address hierarchy in the X.500
       directory information tree," RFC 1836, August 1995.

[2]Kille、S.、「X.500ディレクトリ情報木にO/R Address階層構造を表します」、RFC1836、1995年8月。

   [3] Kille, S., " X.400-MHS use of the X.500 directory to support
       X.400-MHS routing," RFC 1801, June 1995.

[3]Kille、S.、「X.400-MHSがルーティングであるとサポートするX.500ディレクトリのX.400-MHS使用」、RFC1801、1995年6月。

   [4] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay):
       Mapping between X.400 and RFC 822/MIME," RFC 2156, January 1998.

[4]Kille、S.、「ミキサー(パントマイムインターネットX.400はリレーを機能アップしました):」 「X.400とRFC822/の間でMIMEを写像します」、RFC2156、1998年1月。

   [5] Kille, S., Wahl, M., Grimsatd, A., Huber, R., and S. Sataluri,
       "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,
       January 1998.

[5]Kille、S.、ウォール、M.、Grimsatd、A.、ヒューバー、R.、およびS.Sataluri、「LDAP/X.500分類名にドメインを使用します」、RFC2247(1998年1月)。

7  Security Considerations

7 セキュリティ問題

   This document specifies a means by which the X.500/LDAP directory
   service can direct the translation between X.400 and Internet mail
   addresses.  This can indirectly affect the routing of messages across
   a gateway between X.400 and Internet Mail.  A succesful attack on
   this service could cause incorrect translation of an originator
   address (thus "forging" the originator address), or incorrect
   translation of a recipient address (thus directing the mail to an
   unauthorized recipient, or making it appear to an authorized
   recipient, that the message was intended for recipients other than
   those chosen by the originator).  When cryptographic authentication
   is available for directory responses, clients shall employ those
   mechanisms to verify the authenticity and integrity of those
   responses.

このドキュメントはX.500/LDAPディレクトリサービスがX.400とインターネット郵便の宛先の間の翻訳を指示できる手段を指定します。 これはX.400とインターネットメールの間のゲートウェイの向こう側に間接的にメッセージのルーティングに影響できます。 このサービスに対するsuccesful攻撃が創始者アドレス(その結果、創始者アドレスを「鍛造する」)に関する誤訳、または受取人アドレスに関する誤訳を引き起こす場合があった、(その結果、権限のない受取人にメールを向ける、または、それを作るのは認可された受取人にとって現れて、メッセージは創始者によって選ばれたもの以外の受取人のために意図しました) 暗号の認証がディレクトリ応答に利用可能であるときに、クライアントは、それらの応答の信憑性と保全について確かめるのにそれらのメカニズムを使うものとします。

Kille                       Standards Track                     [Page 7]

RFC 2164         X.500/LDAP Directory to Support MIXER      January 1998

ミキサー1998年1月にサポートするKille標準化過程[7ページ]RFC2164X.500/LDAPディレクトリ

8  Author's Address

8作者のアドレス

   Steve Kille
   Isode Ltd.
   The Dome
   The Square
   Richmond
   TW9 1DT
   England

スティーブKille Isode Ltd.のドームの正方形のリッチモンドTW9 1DTイギリス

   Phone:  +44-181-332-9091
   Internet EMail:  S.Kille@ISODE.COM

以下に電話をしてください。 +44-181-332-9091 インターネットメール: S.Kille@ISODE.COM

Kille                       Standards Track                     [Page 8]

RFC 2164         X.500/LDAP Directory to Support MIXER      January 1998

ミキサー1998年1月にサポートするKille標準化過程[8ページ]RFC2164X.500/LDAPディレクトリ

A  Object Identifier Assignment

オブジェクト識別子課題

mhs-ds OBJECT IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1) private(4)
          enterprises(1) isode-consortium (453) mhs-ds (7)}

mhs-ds OBJECT IDENTIFIER:、:= 個人的なiso(1) org(3) dod(6)の企業(1)isode-共同体(453)mhs-dsインターネット(1)(4)(7)

mapping OBJECT IDENTIFIER ::= {mhs-ds 4}

OBJECT IDENTIFIERを写像します:、:= mhs-ds4

oc OBJECT IDENTIFIER ::= {mapping 1}
at OBJECT IDENTIFIER ::= {mapping 2}

oc OBJECT IDENTIFIER:、:= オブジェクト識別子で1を写像します:、:= 2を写像します。

oc-rfc822-to-x400-mapping OBJECT IDENTIFIER ::= {oc 1}              10
oc-x400-to-rfc822-mapping OBJECT IDENTIFIER ::= {oc 2}
oc-omitted-or-address-component OBJECT IDENTIFIER ::= {oc 3}
oc-mixer-gateway ::= {oc 4}

oc-rfc822からx400マッピングへのOBJECT IDENTIFIER:、:= oc1 10oc-x400からrfc822マッピングへのOBJECT IDENTIFIER:、:= oc2省略されたocかアドレス構成要素OBJECT IDENTIFIER:、:= oc3ocミキサーゲートウェイ:、:= oc4

at-associated-or-address OBJECT IDENTIFIER ::= {at 6}
at-associated-x400-gateway OBJECT IDENTIFIER ::= {at 3}
at-associated-domain OBJECT IDENTIFIER ::= {at 4}
at-or-address-component-type OBJECT IDENTIFIER ::= {at 7}
at-associated-internet-gateway OBJECT IDENTIFIER ::= {at 8}
at-mcgam-tables ::= {at 9}                                          20

関連づけるか、扱う、OBJECT IDENTIFIER:、:= 6時に関連x400ゲートウェイのOBJECT IDENTIFIER:、:= 3時に関連ドメインのOBJECT IDENTIFIER:、:= 4、コンポーネント型を扱ってください、OBJECT IDENTIFIER:、:= 7時に関連インターネットゲートウェイのOBJECT IDENTIFIER:、:= 8、mcgamテーブル:、:= 9、20

                Figure 4:  Object Identifier Assignment

図4: オブジェクト識別子課題

Kille                       Standards Track                     [Page 9]

RFC 2164         X.500/LDAP Directory to Support MIXER      January 1998

ミキサー1998年1月にサポートするKille標準化過程[9ページ]RFC2164X.500/LDAPディレクトリ

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Copyright(C)インターネット協会(1998)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Kille                       Standards Track                    [Page 10]

Kille標準化過程[10ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

<AREA> クリッカブルマップの領域を設定する

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る