Network Working Group K. Zeilenga
Request for Comments: 3296 OpenLDAP Foundation
Category: Standards Track July 2002
Named Subordinate References in
Lightweight Directory Access Protocol (LDAP) Directories
Status of this 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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This document details schema and protocol elements for representing and managing named subordinate references in Lightweight Directory Access Protocol (LDAP) Directories.
この文書では、代表とのLDAP（Lightweight Directory Access Protocol）ディレクトリ内の名前付きの下位参照を管理するためのスキーマとプロトコルの要素を詳述します。
Conventions
表記
Schema definitions are provided using LDAPv3 description formats [RFC2252]. Definitions provided here are formatted (line wrapped) for readability.
スキーマ定義は、LDAPv3の記述形式[RFC2252]を使用して提供されます。ここで提供される定義は、読みやすくするために（ラップラインを）フォーマットされています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" used in this document are to be interpreted as described in BCP 14 [RFC2119].
この文書で使用されているキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHOULD"、 "ないもの"、 "推奨" "ない（SHOULD NOT）"、 "MAY"、および "オプション" BCP 14 [RFC2119]で説明されるように解釈されるべきです。
The broadening of interest in LDAP (Lightweight Directory Access Protocol) [RFC2251] directories beyond their use as front ends to X.500 [X.500] directories has created a need to represent knowledge information in a more general way. Knowledge information is information about one or more servers maintained in another server, used to link servers and services together.
LDAPへの関心の広がり（ライトウェイトディレクトリアクセスプロトコル）の使用を越えて[RFC2251]ディレクトリフロントはX.500 [X.500]ディレクトリに終わるとしては、より一般的な方法で知識情報を表現する必要性を作成しました。知識情報は、一緒にサーバーとサービスをリンクするために使用される別のサーバーに維持される1つまたは複数のサーバに関する情報です。
This document details schema and protocol elements for representing and manipulating named subordinate references in LDAP directories. A referral object is used to hold subordinate reference information in the directory. These referral objects hold one or more URIs [RFC2396] contained in values of the ref attribute type and are used to generate protocol referrals and continuations.
このドキュメントでは、LDAPディレクトリ内の名前付きの下位参照を表現し、操作するためのスキーマとプロトコルの要素を詳述します。照会オブジェクトは、ディレクトリ内の下位の参照情報を保持するために使用されます。これらの照会オブジェクトは、ref属性の型の値に含まれる1つの以上のURI [RFC2396]を保持し、プロトコルの紹介と継続を生成するために使用されます。
A control, ManageDsaIT, is defined to allow manipulation of referral and other special objects as normal objects. As the name of control implies, it is intended to be analogous to the ManageDsaIT service option described in X.511(97) [X.511].
コントロールなManageDsaITは、照会及び正常オブジェクトのような他の特別なオブジェクトの操作を可能にするように定義されています。コントロールの名前が示すように、[X.511] X.511（97）に記載のなManageDsaITサービスオプションに類似であることが意図されます。
Other forms of knowledge information are not detailed by this document. These forms may be described in subsequent documents.
知識情報の他の形態は、この文書で詳しく説明されていません。これらのフォームは、後続の文書に記載することができます。
This document details subordinate referral processing requirements for servers. This document does not describe protocol syntax and semantics. This is detailed in RFC 2251 [RFC2251].
この文書では、サーバー用の下位参照処理の要件を詳しく説明しています。この文書では、プロトコルの構文とセマンティクスを説明していません。これは、RFC 2251 [RFC2251]に詳述されています。
This document does not detail use of subordinate knowledge references to support replicated environments nor distributed operations (e.g., chaining of operations from one server to other servers).
この文書は、複製された環境でも、分散操作をサポートするために、従属ナレッジ参照のない詳細な使用（他のサーバーにあるサーバーからの操作、例えば、チェーン）を行います。
A referral object is a directory entry whose structural object class is (or is derived from) the referral object class.
紹介の目的は、構造化オブジェクトクラス（または由来する）ディレクトリエントリ照会オブジェクト・クラスです。
( 2.16.840.1.113730.3.2.6 NAME 'referral' DESC 'named subordinate reference object' STRUCTURAL MUST ref )
（構造マストREF「下位基準オブジェクト命名」2.16.840.1.113730.3.2.6 NAME「紹介」DESC）
The referral object class is a structural object class used to represent a subordinate reference in the directory. The referral object class SHOULD be used in conjunction with the extensibleObject object class to support the naming attributes used in the entry's Distinguished Name (DN) [RFC2253].
照会オブジェクトクラスは、ディレクトリ内の下位基準を表すために使用される構造化オブジェクト・クラスです。照会オブジェクト・クラスは、エントリの識別名（DN）[RFC2253]で使用されるネーミング属性をサポートするためにextensibleObjectオブジェクトクラスに関連して使用されるべきです。
Referral objects are normally instantiated at DSEs immediately subordinate to object entries within a naming context held by the DSA. Referral objects are analogous to X.500 subordinate knowledge (subr) DSEs [X.501].
照会オブジェクトは、通常、直ちにDSAに保持された名前付けコンテキスト内のエントリをオブジェクトに従属DSE群でインスタンス化されます。照会オブジェクトは、X.500下位知識（subrの）DSE群[X.501]に類似しています。
In the presence of a ManageDsaIT control, referral objects are treated as normal entries as described in section 3. Note that the ref attribute is operational and will only be returned in a search entry response when requested.
REF属性が動作可能であり、要求されたときのみ検索エントリ応答で返されること部3注記に記載されているようにManageDSAITコントロールの存在下で、照会オブジェクトは、通常のエントリとして扱われます。
In the absence of a ManageDsaIT control, the content of referral objects are used to construct referrals and search references as described in Section 4 and, as such, the referral entries are not themselves visible to clients.
ManageDSAITコントロールの非存在下で、照会オブジェクトの内容のような、セクション4で説明したように照会して検索基準を構築するために使用され、照会エントリ自体がクライアントに表示されません。
( 2.16.840.1.113730.3.1.34
NAME 'ref'
DESC 'named reference - a labeledURI'
EQUALITY caseExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
USAGE distributedOperation )
The ref attribute type has directoryString syntax and is case sensitive. The ref attribute is multi-valued. Values placed in the attribute MUST conform to the specification given for the labeledURI attribute [RFC2079]. The labeledURI specification defines a format that is a URI, optionally followed by whitespace and a label. This document does not make use of the label portion of the syntax. Future documents MAY enable new functionality by imposing additional structure on the label portion of the syntax as it appears in the ref attribute.
ref属性タイプはdirectoryString構文を持っており、大文字と小文字が区別されます。 ref属性は、多値です。属性に置かれた値は、labeledURI属性[RFC2079]のために与えられた仕様に準拠しなければなりません。れたlabeledURI仕様はURI、必要に応じて空白ラベルが続く形式を定義します。この文書では、構文のラベル部分を使用しません。それはref属性に表示される今後の文書は、構文のラベル部分に付加的な構造を課すことによって、新しい機能を有効にすることができます。
If the URI contained in a ref attribute value refers to a LDAP [RFC2251] server, it MUST be in the form of a LDAP URL [RFC2255]. The LDAP URL SHOULD NOT contain an explicit scope specifier, filter, attribute description list, or any extensions. The LDAP URL SHOULD contain a non-empty DN. The handling of LDAP URLs with absent or empty DN parts or with explicit scope specifier is not defined by this specification.
REF属性値に含まれるURIはLDAPを参照している場合は、[RFC2251]サーバーは、LDAPのURL [RFC2255]の形式でなければなりません。 LDAP URLは、明示的なスコープ指定子、フィルタ、属性記述リスト、または任意の拡張子を含めることはできません。 LDAP URLは空でないDNを含むべきです。存在しないか、または空のDNの部分とまたは明示的な範囲指定を持つLDAP URLの取り扱いは、この仕様で定義されていません。
Other URI schemes MAY be used so long as all operations returning referrals based upon the value could be performed. This document does not detail use of non-LDAP URIs. This is left to future specifications.
他のURIスキームは、値に基づいて紹介を返すすべての操作を実行することができる限り、使用されるかもしれません。この文書では、非LDAP URIの詳細は使用されません。これは、将来の仕様に任されています。
The referential integrity of the URI SHOULD NOT be validated by the server holding or returning the URI (whether as a value of the attribute or as part of a referral result or search reference response).
URIの参照整合性は、サーバURIを保持しているかを返す（属性の値として、または照会結果や検索参照応答の一部としてかどうか）によって検証されるべきではありません。
When returning a referral result or search continuation, the server MUST NOT return the separator or label portions of the attribute values as part of the reference. When the attribute contains multiple values, the URI part of each value is used to construct the referral result or search continuation.
照会結果や検索継続を返すとき、サーバーが参照の一部として、属性値の区切りやラベル部分を返してはなりません。属性が複数の値が含まれている場合、それぞれの値のURI部分は、照会結果や検索継続を構築するために使用されます。
The ref attribute values SHOULD NOT be used as a relative name-component of an entry's DN [RFC2253].
ref属性の値は、エントリのDN [RFC2253]の相対名前成分として使用することはできません。
This document uses the ref attribute in conjunction with the referral object class to represent subordinate references. The ref attribute may be used for other purposes as defined by other documents.
この文書では、下位の参照を表すために照会オブジェクトクラスと併せて参照属性を使用しています。他の文書で定義されたref属性は、他の目的に使用することができます。
The client may provide the ManageDsaIT control with an operation to indicate that the operation is intended to manage objects within the DSA (server) Information Tree. The control causes Directory-specific entries (DSEs), regardless of type, to be treated as normal entries allowing clients to interrogate and update these entries using LDAP operations.
クライアントは、操作がDSA（サーバー）情報ツリー内のオブジェクトを管理するために意図されていることを示すために、操作をManageDSAITコントロールを提供することができます。コントロールは、クライアントがLDAP操作を使用してこれらのエントリを調べると更新することを可能にする通常のエントリとして処理すべき、タイプに関係なく、ディレクトリ固有のエントリ（DSE群）を引き起こします。
A client MAY specify the following control when issuing an add, compare, delete, modify, modifyDN, search request or an extended operation for which the control is defined.
クライアントには、アドオンを発行するとき、次のような制御を指定し、比較、削除、変更、識別名の変更、検索要求または制御が定義されている拡張操作してもよい（MAY）。
The control type is 2.16.840.1.113730.3.4.2. The control criticality may be TRUE or, if FALSE, absent. The control value is absent.
制御タイプは2.16.840.1.113730.3.4.2です。制御臨界はTRUEまたはFALSEの場合、存在しなくてもよいです。制御値は存在しません。
When the control is present in the request, the server SHALL NOT generate a referral or continuation reference based upon information held in referral objects and instead SHALL treat the referral object as a normal entry. The server, however, is still free to return referrals for other reasons. When not present, referral objects SHALL be handled as described above.
制御要求に存在する場合、サーバは、照会オブジェクトに保持された情報に基づいて紹介または継続参照を生成しないものとし、代わりに通常のエントリとして紹介オブジェクトを扱うものとします。サーバーは、しかし、まだ他の理由のためにリフェラルを返すように自由です。存在する場合ではない上記のように、参照オブジェクトを扱うことSHALL。
The control MAY cause other objects to be treated as normal entries as defined by subsequent documents.
制御は、その後の文書で定義されている他のオブジェクトが通常のエントリとして扱われる可能性があります。
A named subordinate reference is constructed by instantiating a referral object in the referencing server with ref attribute values which point to the corresponding subtree maintained in the referenced server. In general, the name of the referral object is the same as the referenced object and this referenced object is a context prefix [X.501].
名前の下位基準は、点、参照サーバに維持対応するサブツリーにREF属性値と参照サーバに照会オブジェクトをインスタンス化することによって構築されます。一般的に、参照オブジェクトの名前は、参照されるオブジェクトと同じであり、この参照されたオブジェクトは、コンテキスト接頭辞[X.501]です。
That is, if server A holds "DC=example,DC=net" and server B holds "DC=sub,DC=example,DC=net", server A may contain a referral object named "DC=sub,DC=example,DC=net" which contains a ref attribute with value of "ldap://B/DC=sub,DC=example,DC=net".
すなわち、サーバAが保持している場合、 "DC =例、DC =ネット" とサーバーBは "DC =副は、DCは=の例では、DCは=ネット"、サーバAは=サブ、DC =例DC」という名前の紹介オブジェクトを含むことができる保持し、あります、LDAP「の値でREF属性が含まれている "ネットDC =：// B / DC =サブ、DC =例、DC =ネット"。
dn: DC=sub,DC=example,DC=net dc: sub ref: ldap://B/DC=sub,DC=example,DC=net objectClass: referral objectClass: extensibleObject
DN：DC =サブ、DC =例えば、DCは=正味DC：サブREF：LDAP：// B / DC =サブ、DC =例えば、DCは=ネットオブジェクトクラス：紹介オブジェクトクラス：extensibleObjectという
Typically the DN of the referral object and the DN of the object in the referenced server are the same.
典型的には、照会オブジェクトのDNと参照サーバ内のオブジェクトのDNは同じです。
If the ref attribute has multiple values, all the DNs contained within the LDAP URLs SHOULD be equivalent. Administrators SHOULD avoid configuring naming loops using referrals.
REF属性が複数の値を持つ場合、LDAPのURLに含まれるすべてのDNは同等であるべきです。管理者は、紹介を使用して命名ループを設定することは避けてください。
Named references MUST be treated as normal entries if the request includes the ManageDsaIT control as described in section 3.
セクション3に記載されるように要求ManageDSAITコントロールを含む場合という名前の参照は通常のエントリとして扱わなければなりません。
The following sections contain specifications of how referral objects should be used in different scenarios followed by examples that illustrate that usage. The scenarios described here consist of referral object handling when finding target of a non-search operation, when finding the base of a search operation, and when generating search references. Lastly, other operation processing considerations are presented.
以下のセクションでは、その使用方法を説明する実施例によって、その後さまざまなシナリオで使用されるべき方法を紹介オブジェクトの仕様を含みます。検索基準を生成する際に検索操作のベースを見つけ、そして場合、非検索操作の対象を発見するとき、ここで説明したシナリオは、参照オブジェクトの処理から成ります。最後に、他の演算処理の考慮事項が提示されています。
It is to be noted that, in this document, a search operation is conceptually divided into two distinct, sequential phases: (1) finding the base object where the search is to begin, and (2) performing the search itself. The first phase is similar to, but not the same as, finding the target of a non-search operation.
なお、この文書では、検索操作を概念的に二つの別個の、逐次フェーズに分割されることに留意すべきである：（1）検索を開始するベースオブジェクトを見つけること、及び（2）検索自体を実行します。第一段階は、非検索操作の対象を見つけると同様、しかし同じではありません。
It should also be noted that the ref attribute may have multiple values and, where these sections refer to a single ref attribute value, multiple ref attribute values may be substituted and SHOULD be processed and returned (in any order) as a group in a referral or search reference in the same way as described for a single ref attribute value.
また、複数refが値が照会にグループとして置換されていてもよく、（任意の順序で）処理され、返されるべきである属性これらのセクションは、単一ref属性値を参照する場合ref属性は、複数の値を持つとしてもよいことに留意すべきですまたは、単一のREF属性値のために説明したのと同じ方法で参照を検索します。
Search references returned for a given request may be returned in any order.
与えられた要求に対して返さ検索参照は、任意の順序で返されることがあります。
For example, suppose the contacted server (hosta) holds the entry "O=MNN,C=WW" and the entry "CN=Manager,O=MNN,C=WW" and the following referral objects:
例えば、接触サーバ（ギボウシ）はエントリ「O = MNN、C = WW」エントリ「CN =マネージャ、O = MNN、C = WW」と次の照会オブジェクトを保持していると仮定する。
dn: OU=People,O=MNN,C=WW ou: People ref: ldap://hostb/OU=People,O=MNN,C=US ref: ldap://hostc/OU=People,O=MNN,C=US objectClass: referral objectClass: extensibleObject
DN：OU =人、O = MNNは、C = WWは、OU：人々はREF：LDAP：// HOSTB / OU =人、O = MNN、C = US REF：LDAP：// HOSTC / OU =人、O = MNN 、C = USオブジェクトクラス：紹介のobjectClass：extensibleObjectという
dn: OU=Roles,O=MNN,C=WW ou: Roles ref: ldap://hostd/OU=Roles,O=MNN,C=WW objectClass: referral objectClass: extensibleObject
DN：OU =ロール、O = MNN、C = WWはOU：ロールのREF：LDAP：// hostdを/ OU =ロール、O = MNN、C = WWオブジェクトクラス：紹介オブジェクトクラス：extensibleObjectという
The first referral object provides the server with the knowledge that subtree "OU=People,O=MNN,C=WW" is held by hostb and hostc (e.g., one is the master and the other a shadow). The second referral object provides the server with the knowledge that the subtree "OU=Roles,O=MNN,C=WW" is held by hostd.
第1のレフェラルオブジェクトはHOSTBとHOSTCに保持されているサブツリー知識「OU =人物を、O = MNN、C = WW」のサーバを提供する（例えば、一方がマスタであり、他の影）。第紹介オブジェクトはサブツリーという知識を使用してサーバーを提供する「OU =ロール、O = MNN、C = WW」がhostdを保持されています。
Also, in the context of this document, the "nearest naming context" means the deepest context which the object is within. That is, if the object is within multiple naming contexts, the nearest naming context is the one which is subordinate to all other naming contexts the object is within.
また、本文書の文脈では、「最寄りのネーミングコンテキストは、」オブジェクトが内部で最も深いコンテキストを意味します。オブジェクトが複数のネーミング・コンテキスト内であれば、最寄りのネーミングコンテキストは、他のすべての命名に従属する1オブジェクトが内にあるコンテキストです。
This section details referral handling for add, compare, delete, modify, and modify DN operations. If the client requests any of these operations, there are four cases that the server must handle with respect to the target object.
このセクションの詳細は、追加の比較、削除、変更、およびDNの変更操作のために取り扱う紹介します。クライアントは、これらの操作のいずれかを要求する場合、サーバはターゲットオブジェクトに対する対処しなければならない4つの場合があります。
The DN part MUST be modified such that it refers to the appropriate target in the referenced server (as detailed below). Even where the DN to be returned is the same as the target DN, the DN part SHOULD NOT be trimmed.
DN部分は、（以下に詳述するように）、それは、参照サーバ内の適切な標的を指すように修正されなければなりません。返されるDNをターゲットDNと同じである場合でも、DN部分がトリミングされるべきではありません。
In cases where the URI to be returned is a LDAP URL, the server SHOULD trim any present scope, filter, or attribute list from the URI before returning it. Critical extensions MUST NOT be trimmed or modified.
返されるURIはLDAPのURLである場合には、サーバーは、任意の現在のスコープ、フィルタをトリミングすべきである、またはそれを返す前にURIから属性リスト。重要な機能拡張は、トリミングまたは変更してはいけません。
Case 1: The target object is not held by the server and is not within or subordinate to any naming context nor subordinate to any referral object held by the server.
ケース1：ターゲット・オブジェクトがサーバーによって保持されていないとの範囲内でない場合、または任意のネーミングコンテキストの下位にもサーバーが保持している任意の照会オブジェクトに従属しています。
The server SHOULD process the request normally as appropriate for a non-existent base which is not within any naming context of the server (generally return noSuchObject or a referral based upon superior knowledge reference information). This document does not detail management or processing of superior knowledge reference information.
サーバは、サーバの任意のネーミング・コンテキスト内ではありません存在しない塩基ため、通常、適切な要求を処理する（一般noSuchObjectまたは優れた知識基準情報に基づいて、参照を返します）。この文書は、詳細管理または優れた知識参照情報を処理しません。
Case 2: The target object is held by the server and is a referral object.
ケース2：ターゲット・オブジェクトは、サーバーが保持していると紹介オブジェクトです。
The server SHOULD return the URI value contained in the ref attribute of the referral object appropriately modified as described above.
サーバは、適宜上記のように修飾された照会オブジェクトのREF属性に含まれているURI値を返すべきです。
Example: If the client issues a modify request for the target object of "OU=People,O=MNN,c=WW", the server will return:
例：クライアントが目標オブジェクトに対する変更要求を発行した場合、「OU =人々を、O = MNN、C = WW」、サーバが返します。
ModifyResponse (referral) {
ldap://hostb/OU=People,O=MNN,C=WW
ldap://hostc/OU=People,O=MNN,C=WW
}
Case 3: The target object is not held by the server, but the nearest naming context contains no referral object which the target object is subordinate to.
ケース3：ターゲット・オブジェクトは、サーバーが保持しているが、最寄りのネーミングコンテキストは、ターゲットオブジェクトに従属である何の紹介オブジェクトが含まれていないされていません。
If the nearest naming context contains no referral object which the target is subordinate to, the server SHOULD process the request as appropriate for a nonexistent target (generally return noSuchObject).
最寄りの名前付けコンテキストをターゲットに従属されない照会オブジェクトが含まれていない場合、サーバは存在しない対象（一般noSuchObjectを返す）に応じて、要求を処理しなければなりません。
Case 4: The target object is not held by the server, but the nearest naming context contains a referral object which the target object is subordinate to.
ケース4：ターゲット・オブジェクトは、サーバーが保持しているが、最寄りのネーミングコンテキストは、ターゲットオブジェクトに従属で紹介オブジェクトが含まれていません。
If a client requests an operation for which the target object is not held by the server and the nearest naming context contains a referral object which the target object is subordinate to, the server SHOULD return a referral response constructed from the URI portion of the ref value of the referral object.
クライアントが目標オブジェクトがサーバーによって保持され、最寄りのネーミングコンテキストは、ターゲットオブジェクトに従属で紹介オブジェクトが含まれていますされていない操作を要求した場合、サーバーは、REF値のURI部分から構築紹介応答を返すべきですreferralオブジェクトの。
Example: If the client issues an add request where the target object has a DN of "CN=Manager,OU=Roles,O=MNN,C=WW", the server will return:
例：クライアントが目標オブジェクトは、「CN =マネージャ、OU =役割、O = MNN、C = WW」のDNを持つ追加要求を発行した場合、サーバが返します。
AddResponse (referral) {
ldap://hostd/CN=Manager,OU=Roles,O=MNN,C=WW"
}
Note that the DN part of the LDAP URL is modified such that it refers to the appropriate entry in the referenced server.
LDAPのURLのDN部分は、それが参照されるサーバ内の適切なエントリを指すように修正されることに注意してください。
This section details referral handling for base object processing within search operations. Like target object considerations for non-search operations, there are the four cases.
このセクションの詳細は、検索操作内のベースオブジェクト処理のために取り扱い紹介します。非検索操作のターゲットオブジェクトの考慮事項と同様に、4例があります。
In cases where the URI to be returned is a LDAP URL, the server MUST provide an explicit scope specifier from the LDAP URL prior to returning it. In addition, the DN part MUST be modified such that it refers to the appropriate target in the referenced server (as detailed below).
返されるURIはLDAPのURLである場合には、サーバはLDAPのURLから事前にそれを返すへの明示的なスコープ指定子を提供しなければなりません。また、DN部分は、（以下に詳述するように）、それは、参照サーバ内の適切な標的を指すように修正されなければなりません。
If aliasing dereferencing was necessary in finding the referral object, the DN part of the URI MUST be replaced with the base DN as modified by the alias dereferencing such that the return URL refers to the new target object per [RFC2251, 4.1.11].
エイリアシング間接参照は、参照オブジェクトを見つけることに必要であった場合は、URIのDN部分は、戻り先URLは[RFC2251、4.1.11]あたりの新しいターゲットオブジェクトを参照するように間接参照エイリアスによって修正され、ベースDNと交換しなければなりません。
Critical extensions MUST NOT be trimmed nor modified.
重要な機能拡張は、トリミングも変更してはいけません。
Case 1: The base object is not held by the server and is not within nor subordinate to any naming context held by the server.
ケース1：ベースオブジェクトは、サーバーが保持していないとの範囲内でも、サーバーが保持しているすべてのネーミングコンテキストの下位ではありません。
The server SHOULD process the request normally as appropriate for a non-existent base which not within any naming context of the server (generally return a superior referral or noSuchObject). This document does not detail management or processing of superior knowledge references.
サーバではなく、サーバーのいずれかの名前付けコンテキスト内に存在しない塩基（一般に優れた照会またはnoSuchObjectを戻す）ため、通常、適切な要求を処理しなければなりません。このドキュメントではなく、優れたナレッジ参照の詳細管理や処理を行います。
Case 2: The base object is held by the server and is a referral object.
ケース2：ベースオブジェクトは、サーバーが保持していると紹介オブジェクトです。
The server SHOULD return the URI value contained in the ref attribute of the referral object appropriately modified as described above.
サーバは、適宜上記のように修飾された照会オブジェクトのREF属性に含まれているURI値を返すべきです。
Example: If the client issues a subtree search in which the base object is "OU=Roles,O=MNN,C=WW", the server will return
例：クライアントは「O = MNN、C = WWをOU =役割」ベースオブジェクトがある、サブツリー検索を発行した場合、サーバが返されます
SearchResultDone (referral) {
ldap://hostd/OU=Roles,O=MNN,C=WW??sub
}
If the client were to issue a base or oneLevel search instead of subtree, the returned LDAP URL would explicitly specify "base" or "one", respectively, instead of "sub".
クライアントがベースを発行したりONELEVELサブツリーの代わりに検索した場合は、返されたLDAPのURLを明示的に代わりに「サブ」の、それぞれ、「ベース」または「1」を指定します。
Case 3: The base object is not held by the server, but the nearest naming context contains no referral object which the base object is subordinate to.
ケース3：ベースオブジェクトは、サーバーが保持しているが、最寄りのネーミングコンテキストは、ベースオブジェクトに従属である何の紹介オブジェクトが含まれていないされていません。
If the nearest naming context contains no referral object which the base is subordinate to, the request SHOULD be processed normally as appropriate for a nonexistent base (generally return noSuchObject).
最寄りの名前付けコンテキストベースのに従属しない照会オブジェクトが含まれていない場合、要求は存在しない塩基（一般noSuchObjectを返す）に応じて、通常処理されるべきです。
Case 4: The base object is not held by the server, but the nearest naming context contains a referral object which the base object is subordinate to.
ケース4：ベースオブジェクトは、サーバーが保持しているが、最寄りのネーミングコンテキストは、ベースオブジェクトに従属で紹介オブジェクトが含まれていません。
If a client requests an operation for which the target object is not held by the server and the nearest naming context contains a referral object which the target object is subordinate to, the server SHOULD return a referral response which is constructed from the URI portion of the ref value of the referral object.
クライアントが目標オブジェクトがサーバーによって保持され、最寄りのネーミングコンテキストは、ターゲットオブジェクトに従属で紹介オブジェクトが含まれていますされていない操作を要求した場合、サーバーはのURI部分から構成された紹介応答を返すべきですreferralオブジェクトの参照値。
Example: If the client issues a base search request for "CN=Manager,OU=Roles,O=MNN,C=WW", the server will return
例：クライアントは「= MNC = WITH OF CN =マネージャ、OU =役割、」のための基本検索要求を発行した場合、サーバが返されます
SearchResultDone (referral) {
ldap://hostd/CN=Manager,OU=Roles,O=MNN,C=WW??base"
}
If the client were to issue a subtree or oneLevel search instead of subtree, the returned LDAP URL would explicitly specify "sub" or "one", respectively, instead of "base".
クライアントは、サブツリーを発行したりONELEVELサブツリーの代わりに検索した場合は、返されたLDAPのURLを明示的に代わりに「ベース」の、それぞれ、「サブ」または「1」を指定します。
Note that the DN part of the LDAP URL is modified such that it refers to the appropriate entry in the referenced server.
LDAPのURLのDN部分は、それが参照されるサーバ内の適切なエントリを指すように修正されることに注意してください。
For search operations, once the base object has been found and determined not to be a referral object, the search may progress. Any entry matching the filter and scope of the search which is not a referral object is returned to the client normally as described in [RFC2251].
ベースオブジェクトが見つかったと紹介対象ではないと判断された後に検索操作のために、検索が進行してもよいです。照会オブジェクトでない検索のフィルタと範囲に一致するエントリが[RFC2251]に記載の通常のようにクライアントに返されます。
For each referral object within the requested scope, regardless of the search filter, the server SHOULD return a SearchResultReference which is constructed from the URI component of values of the ref attribute. If the URI component is not a LDAP URL, it should be returned as is. If the LDAP URL's DN part is absent or empty, the DN part must be modified to contain the DN of the referral object. If the URI component is a LDAP URL, the URI SHOULD be modified to add an explicit scope specifier.
要求された範囲内の各照会オブジェクトのためにかかわらず、検索フィルタの、サーバは、ref属性の値のURIコンポーネントから構成されているのSearchResultReferenceを返すべきです。 URIコンポーネントは、LDAPのURLでない場合は、そのまま返されるべきです。 LDAP URLのDN部分が存在しないか、または空の場合、DN部分は、紹介オブジェクトのDNを含むように改変されなければなりません。 URIコンポーネントは、LDAPのURLである場合、URIは、明示的なスコープ指定子を追加するために変更する必要があります。
Subtree Example:
サブツリー例：
If a client requests a subtree search of "O=MNN,C=WW", then in addition to any entries within scope which match the filter, hosta will also return two search references as the two referral objects are within scope. One possible response might be:
クライアントが「O = MNN、C = WW」のサブツリー検索を要求した場合2つの参照オブジェクトがスコープ内にあるとして、その後、フィルタに一致する範囲内の任意のエントリに加えて、ギボウシは、2つの検索の参照を返します。一つの可能な応答は次のようになります。
SearchEntry for O=MNN,C=WW
SearchResultReference {
ldap://hostb/OU=People,O=MNN,C=WW??sub
ldap://hostc/OU=People,O=MNN,C=WW??sub
}
SearchEntry for CN=Manager,O=MNN,C=WW
SearchResultReference {
ldap://hostd/OU=Roles,O=MNN,C=WW??sub
}
SearchResultDone (success)
One Level Example:
一つのレベルの例：
If a client requests a one level search of "O=MNN,C=WW" then, in addition to any entries one level below the "O=MNN,C=WW" entry matching the filter, the server will also return two search references as the two referral objects are within scope. One possible sequence is shown:
クライアントは1つのレベルの検索要求した場合、「O = MNNを、C = WW」は、その後、1つのレベルのフィルタに一致する「Oは= MNN、C = WW」エントリの下のすべてのエントリに加えて、サーバーは、2件の検索を返します。 2つの参照オブジェクトとして参照が範囲内です。一つの可能なシーケンスが示されています：
SearchResultReference {
ldap://hostb/OU=People,O=MNN,C=WW??base
ldap://hostc/OU=People,O=MNN,C=WW??base
}
SearchEntry for CN=Manager,O=MNN,C=WW
SearchResultReference {
ldap://hostd/OU=Roles,O=MNN,C=WW??base
}
SearchResultDone (success)
Note: Unlike the examples in Section 4.5.3.1 of RFC 2251, the LDAP URLs returned with the SearchResultReference messages contain, as required by this specification, an explicit scope specifier.
注意：この仕様書、明示的な範囲指定で必要とされるRFC 2251のセクション4.5.3.1の例とは異なり、LDAPのURLは、メッセージが含まれているのSearchResultReferenceに戻りました。
This section details processing considerations for other operations.
他の操作のためのこのセクションの詳細処理が配慮。
Servers SHOULD NOT return referral result code if the bind name (or authentication identity or authorization identity) is (or is subordinate to) a referral object but MAY use the knowledge information to process the bind request (such as in support a future distributed operation specification). Where the server makes no use of the knowledge information, the server processes the request normally as appropriate for a non-existent authentication or authorization identity (e.g., return invalidCredentials).
こうした将来の分散動作仕様のサポートのように、サーバーのバインド名（または認証アイデンティティや認可ID）がある（またはそれに従属する）場合は、紹介オブジェクトを照会結果コードを返すべきではありませんが、バインド要求を処理するための知識情報を使用することができます（ ）。サーバは、知識情報の一切利用しない場合、サーバは存在しない認証または認可アイデンティティ（例えば、invalidCredentialsを返す）ため、通常、適切な要求を処理します。
If the newSuperior is a referral object or is subordinate to a referral object, the server SHOULD return affectsMultipleDSAs. If the newRDN already exists but is a referral object, the server SHOULD return affectsMultipleDSAs instead of entryAlreadyExists.
newSuperiorが紹介オブジェクトであるか、紹介オブジェクトに従属する場合、サーバはaffectsMultipleDSAsを返すべきです。 newRDNがすでに存在しているが、紹介のオブジェクトである場合、サーバーではなくentryAlreadyExistsのaffectsMultipleDSAsを返すべきです。
This document defines mechanisms that can be used to tie LDAP (and other) servers together. The information used to tie services together should be protected from unauthorized modification. If the server topology information is not public information, it should be protected from unauthorized disclosure as well.
このドキュメントでは、LDAP（および他の）サーバを一緒に結ぶために使用することができるメカニズムを定義します。一緒にサービスを結び付けるために使用される情報は、不正な変更から保護されなければなりません。サーバートポロジ情報は公開情報ではない場合、それは同様に不正な開示から保護されなければなりません。
This document borrows heavily from previous work by IETF LDAPext Working Group. In particular, this document is based upon "Named Referral in LDAP Directories" (an expired Internet Draft) by Christopher Lukas, Tim Howes, Michael Roszkowski, Mark C. Smith, and Mark Wahl.
この文書は、IETF LDAPEXTワーキンググループによって前作から大きく借ります。特に、この文書はクリストファー・ルーカス、ティムハウズ、マイケルRoszkowski、マーク・C・スミス、そしてマーク・ワールによる「LDAPディレクトリで名前付き紹介」（期限切れのインターネットドラフト）に基づいています。
[RFC2079] Smith, M., "Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs)", RFC 2079, January 1997.
[RFC2079]スミス、M.、RFC 2079、1997年1月 "Uniform Resource Identifier（URI）を保持するために、X.500属性タイプとオブジェクトクラスの定義"。
[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[RFC2251]ワール、M.、ハウズ、T.およびS. Kille、 "軽量のディレクトリアクセスプロトコル（V3）"、RFC 2251、1997年12月。
[RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997.
[RFC2252]ワール、M.、Coulbeck、A.、ハウズ、T.およびS. Kille、 "軽量のディレクトリアクセスプロトコル（V3）：属性の構文定義"、RFC 2252、1997年12月。
[RFC2253] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997.
[RFC2253]ワール、M.、Kille、S.とT.ハウズ、 "ライトウェイトディレクトリアクセスプロトコル（v3の）：識別名のUTF-8文字列表現"、RFC 2253、1997年12月。
[RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, December, 1997.
[RFC2255]ハウズ、T.およびM.スミス、 "LDAPのURLの形式"、RFC 2255、1997年12月。
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC2396]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
[X.501] ITU-T, "The Directory: Models", X.501, 1993.
[X.501] ITU-T、 "ディレクトリ：モデル"、X.501、1993。
[X.500] ITU-T, "The Directory: Overview of Concepts, Models, and Services", X.500, 1993.
[X.500] ITU-T、 "ディレクトリ：概念の概要、モデル、およびサービス"、X.500、1993。
[X.511] ITU-T, "The Directory: Abstract Service Definition", X.500, 1997.
[X.511] ITU-T、 "ディレクトリ：抽象サービス定義"、X.500、1997。
Kurt D. Zeilenga OpenLDAP Foundation
クルトD. ZeilengaのOpenLDAP財団
EMail: Kurt@OpenLDAP.org
メールアドレス：Kurt@OpenLDAP.org
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。