[要約] RFC 3296は、LDAPディレクトリ内の名前付き従属参照に関する仕様です。このRFCの目的は、従属参照の使用方法と管理方法を定義することです。

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

Lightweight Directory Access Protocol(LDAP)ディレクトリの下位参照

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.

Copyright(c)The Internet Society(2002)。無断転載を禁じます。

Abstract

概要

This document details schema and protocol elements for representing and managing named subordinate references in Lightweight Directory Access Protocol (LDAP) Directories.

このドキュメントでは、Lightweight Directory Access Protocol(LDAP)ディレクトリで名前の下位参照を表現および管理するためのスキーマとプロトコル要素について詳しく説明しています。

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].

「必須」、「必要」、「必須」、「shall」、「shall "、" obly "、" should "、" nove "、" becommended "、" may "、および" optional "は、このドキュメントで使用されています。BCP 14 [RFC2119]に記載されているように解釈されます。

1. Background and Intended Usage
1. 背景と目的の使用

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(LightWeight Directory Access Protocol)[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(97)[X.511]で説明されているマネージドサービスオプションに類似することを目的としています。

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).

このドキュメントでは、複製された環境や分散操作(たとえば、1つのサーバーから他のサーバーへの操作のチェーンなど)をサポートするための下位の知識参照の使用を詳しく説明していません。

2. Schema
2. スキーマ
2.1. The referral Object Class
2.1. 紹介オブジェクトクラス

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 )

(2.16.840.1.113730.3.2.6 name 'referral' desc '' named named reference object 'structuralは参照しなければなりません)

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]で使用される命名属性をサポートする必要があります。

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)dses [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.

マネージドコントロールの存在下で、紹介オブジェクトはセクション3で説明されているように通常のエントリとして扱われます。REF属性は動作し、要求されたときに検索エントリ応答でのみ返されることに注意してください。

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.

マネージドセイトコントロールがない場合、紹介オブジェクトのコンテンツは、セクション4で説明されているように紹介と検索参照を構築するために使用され、そのため、紹介エントリはそれ自体がクライアントには見えません。

2.2 The ref Attribute Type
2.2 ref属性タイプ

( 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 )

(2.16.840.1.113730.3.1.34名 'ref' desc '' named reference -a labeeduri 'equality caseexactmatch構文1.3.6.1.4.1.1466.115.121.1.15ユーザージーディストリビュー装置)

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の形式を定義し、オプションではWhitespaceとラベルが続きます。このドキュメントでは、構文のラベル部分を使用しません。将来のドキュメントは、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属性を紹介オブジェクトクラスと組み合わせて使用して、下位参照を表します。ref属性は、他のドキュメントで定義されている他の目的に使用できます。

3. The ManageDsaIT Control
3. マネージドコントロール

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(サーバー)情報ツリー内のオブジェクトを管理することを目的としていることを示すために、操作をマネージドコントロールに提供する場合があります。このコントロールにより、タイプに関係なくディレクトリ固有のエントリ(DSE)が通常のエントリとして扱われ、クライアントはLDAP操作を使用してこれらのエントリを尋問および更新できます。

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.

クライアントは、追加、比較、削除、変更、変更、検索要求、またはコントロールが定義されている拡張操作を発行するときに、次のコントロールを指定できます。

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です。コントロールの臨界性は真実であるか、偽の場合は欠席する場合があります。制御値はありません。

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.

リクエストにコントロールが存在する場合、サーバーは紹介オブジェクトに保持されている情報に基づいて紹介または継続リファレンスを生成してはなりません。代わりに、紹介オブジェクトを通常のエントリとして扱います。ただし、サーバーは、他の理由で紹介を自由に返すことができます。存在しない場合、紹介オブジェクトは上記のように処理されます。

The control MAY cause other objects to be treated as normal entries as defined by subsequent documents.

コントロールにより、他のオブジェクトは、後続のドキュメントで定義されているように、通常のエントリとして扱われる場合があります。

4. Named Subordinate References
4. 下位参照と名付けられました

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 = example、dc = net」を保持し、サーバーbが「dc = sub、dc = example、dc = net」を保持する場合、サーバーaには「dc = sub、dc = example」という名前の紹介オブジェクトが含まれる場合があります。、dc = net "には、「ldap:// b/dc = sub、dc = example、dc = net」の値を持つref属性が含まれています。

      dn: DC=sub,DC=example,DC=net
      dc: sub
      ref: ldap://B/DC=sub,DC=example,DC=net
      objectClass: referral
      objectClass: 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に含まれるすべてのDNSは同等でなければなりません。管理者は、紹介を使用してネーミングループの構成を避ける必要があります。

Named references MUST be treated as normal entries if the request includes the ManageDsaIT control as described in section 3.

セクション3で説明されているように、リクエストにマネージドコントロールが含まれている場合、名前付き参照は通常のエントリとして扱わなければなりません。

5. Scenarios
5. シナリオ

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.

このドキュメントでは、検索操作は概念的に2つの異なるシーケンシャルフェーズに分割されていることに注意してください。(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.

特定のリクエストに対して返される検索参照は、任意の順序で返される場合があります。

5.1. Example Configuration
5.1. 構成の例

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:

たとえば、連絡されたサーバー(HOSTA)がエントリ「O = MNN、C = WW」とエントリ「CN = Manager、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=Roles,O=MNN,C=WW
      ou: Roles
      ref: ldap://hostd/OU=Roles,O=MNN,C=WW
      objectClass: referral
      objectClass: 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.

最初の紹介オブジェクトは、サブツリー「ou =人、o = mnn、c = ww」がhostbとhostcによって保持されているという知識をサーバーに提供します(たとえば、1つはマスター、もう1つは影です)。2番目の紹介オブジェクトは、サブツリー「ou = chore、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.

また、このドキュメントのコンテキストでは、「最も近い命名コンテキスト」は、オブジェクトが内部にある最も深いコンテキストを意味します。つまり、オブジェクトが複数の命名コンテキスト内にある場合、最寄りの命名コンテキストは、オブジェクトが内部にある他のすべての命名コンテキストに従属するものです。

5.2. Target Object Considerations
5.2. ターゲットオブジェクトの考慮事項

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部分から構築された紹介応答を返す必要があります紹介オブジェクトの。

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 = manager、ou = chore、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部分は、参照されるサーバーの適切なエントリを指すように変更されていることに注意してください。

5.3. Base Object Considerations
5.3. ベースオブジェクトの考慮事項

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
        
         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.

クライアントがターゲットオブジェクトがサーバーによって保持されない操作を要求し、最寄りのネーミングコンテキストにターゲットオブジェクトが従属する紹介オブジェクトが含まれている場合、サーバーは紹介応答を返す必要があります。紹介オブジェクトのref値。

   Example: If the client issues a base search request for
      "CN=Manager,OU=Roles,O=MNN,C=WW", the server will return
        
         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部分は、参照されるサーバーの適切なエントリを指すように変更されていることに注意してください。

5.4. Search Continuation Considerations
5.4. 継続的な考慮事項を検索します

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つの紹介オブジェクトがスコープ内であるため、Hostaは2つの検索参照も返します。考えられる応答の1つは、次のとおりです。

          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:

1つのレベルの例:

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:

クライアントが「o = mnn、c = ww」の1つのレベルの検索を要求した場合、フィルターに一致する「o = mnn、c = ww」エントリの1つのレベルの1つのレベルに加えて、サーバーは2つの検索も返します2つの紹介オブジェクトとしての参照は、範囲内です。考えられるシーケンスが1つ表示されます。

          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メッセージで返されます。

5.6. Other Considerations
5.6. その他の考慮事項

This section details processing considerations for other operations.

このセクションでは、他の操作の処理に関する考慮事項について詳しく説明しています。

5.6.1 Bind
5.6.1 練る

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または承認ID)が紹介オブジェクトである(または従属する)場合、紹介結果コードを返してはなりませんが、知識情報を使用してBIND要求を処理できます(将来の分散操作仕様をサポートするなど)。サーバーが知識情報を使用しない場合、サーバーは、存在しない認証または承認IDのために必要に応じて要求を通常処理します(たとえば、return validcredentialss)。

5.6.2 Modify DN
5.6.2 DNを変更します

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が紹介オブジェクトであるか、紹介オブジェクトに従属している場合、サーバーはEffectSmultipledsasを返す必要があります。NewRDNが既に存在しているが紹介オブジェクトである場合、サーバーはEntryReadyExistsの代わりにEffectSMultipLedsasを返す必要があります。

6. Security Considerations
6. セキュリティに関する考慮事項

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(およびその他の)サーバーを結び付けるために使用できるメカニズムを定義します。サービスを結び付けるために使用される情報は、不正な変更から保護する必要があります。サーバートポロジー情報が公開情報ではない場合、不正な開示からも保護する必要があります。

7. Acknowledgments
7. 謝辞

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ワーキンググループによる以前の研究から大きく借用しています。特に、この文書は、クリストファー・ルーカス、ティム・ハウズ、マイケル・ロスコフスキー、マーク・C・スミス、マーク・ウォールによる「LDAPディレクトリの名前付き紹介」(期限切れのインターネットドラフト)に基づいています。

8. Normative References
8. 引用文献

[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] Smith、M。、「X.500属性タイプの定義と、ユニフォームリソース識別子(URI)を保持するオブジェクトクラス」、RFC 2079、1997年1月。

[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.

[RFC2251] Wahl、M.、Howes、T。およびS. Killee、「Lightweight Directory Access Protocol(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] Wahl、M.、Coulbeck、A.、Howes、T。およびS. Killee、「Lightweight Directory Access Protocol(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] Wahl、M.、Kille、S。、およびT. Howes、「Lightweight Directory Access Protocol(V3):UTF-8文字列識別名の表現」、RFC 2253、1997年12月。

[RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, December, 1997.

[RFC2255] Howes、T。およびM. Smith、「The 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] Berners-Lee、T.、Fielding、R。and L. Masinter、「Uniform Resource Identiers(URI):Generic Syntax」、RFC 2396、1998年8月。

[X.501] ITU-T, "The Directory: Models", X.501, 1993.

[X.501] ITU-T、「ディレクトリ:モデル」、X.501、1993。

9. Informative References
9. 参考引用

[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。

10. Author's Address
10. 著者の連絡先

Kurt D. Zeilenga OpenLDAP Foundation

Kurt D. Zeilenga OpenLdap Foundation

   EMail: Kurt@OpenLDAP.org
        
11. 完全な著作権声明

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

Copyright(c)The Internet Society(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エディター機能の資金は現在、インターネット協会によって提供されています。