[要約] RFC 3672は、LDAPでサブエントリをサポートするための仕様です。目的は、LDAPディレクトリツリー内のエントリの階層構造をより柔軟に管理することです。
Network Working Group K. Zeilenga
Request for Comments: 3672 OpenLDAP Foundation
Category: Standards Track S. Legg
Adacel Technologies
December 2003
Subentries in the Lightweight Directory Access Protocol (LDAP)
軽量ディレクトリアクセスプロトコル（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 (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
In X.500 directories, subentries are special entries used to hold information associated with a subtree or subtree refinement. This document adapts X.500 subentries mechanisms for use with the Lightweight Directory Access Protocol (LDAP).
X.500ディレクトリでは、Subentriesは、サブツリーまたはサブツリーの改良に関連する情報を保持するために使用される特別なエントリです。このドキュメントは、Lightweight Directory Access Protocol（LDAP）で使用するX.500 Subentriesメカニズムを適合させます。
From [X.501]:
[x.501]から：
A subentry is a special kind of entry immediately subordinate to an administrative point. It contains attributes that pertain to a subtree (or subtree refinement) associated with its administrative point. The subentries and their administrative point are part of the same naming context.
サブエントリーは、管理ポイントにすぐに従属する特別な種類のエントリです。これには、管理ポイントに関連するサブツリー（またはサブツリー洗練）に関係する属性が含まれています。Subentriesとその管理ポイントは、同じ命名コンテキストの一部です。
A single subentry may serve all or several aspects of administrative authority. Alternatively, a specific aspect of administrative authority may be handled through one or more of its own subentries.
単一のサブエントリーは、行政当局のすべてまたはいくつかの側面に役立つ場合があります。あるいは、行政当局の特定の側面は、1つ以上の独自のサブエントリを介して処理される場合があります。
Subentries in the Lightweight Directory Access Protocol (LDAP) [RFC3377] SHALL behave in accordance with X.501 unless noted otherwise in this specification.
Lightweight Directory Access Protocol（LDAP）[RFC3377]のサブエントリは、この仕様で特に記載されていない限り、X.501に従って動作するものとします。
In absence of the subentries control (detailed in Section 3), subentries SHALL NOT be considered in one-level and subtree scope search operations. For all other operations, including base scope search operations, subentries SHALL be considered.
Subentries Control（セクション3で詳細）がない場合、Subentriesは、1レベルおよびサブツリースコープ検索操作で考慮されないものとします。ベーススコープ検索操作を含む他のすべての操作については、サブエントリを考慮するものとします。
Schema definitions are provided using LDAP description formats [RFC2252]. Definitions provided here are formatted (line wrapped) for readability.
スキーマ定義は、LDAP説明形式[RFC2252]を使用して提供されます。ここで提供される定義は、読みやすさのためにフォーマットされています（ラインラップ）。
Protocol elements are described using ASN.1 [X.680]. The term "BER-encoded" means the element is to be encoded using the Basic Encoding Rules [X.690] under the restrictions detailed in Section 5.1 of [RFC2251].
プロトコル要素は、asn.1 [x.680]を使用して説明されています。「BERENCODED」という用語は、[RFC2251]のセクション5.1で詳述されている制限の下で、基本的なエンコードルール[x.690]を使用して要素をエンコードすることを意味します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14 [RFC2119]に記載されているように解釈される。
The Subtree Specification syntax provides a general purpose mechanism for the specification of a subset of entries in a subtree of the Directory Information Tree (DIT). A subtree begins at some base entry and includes the subordinates of that entry down to some identified lower boundary, possibly extending to the leaf entries. A subtree specification is always used within a context or scope which implicitly determines the bounds of the subtree. For example, the scope of a subtree specification for a subschema administrative area does not include the subtrees of any subordinate administrative point entries for subschema administration. Where a subtree specification does not identify a contiguous subset of the entries within a single subtree the collection is termed a subtree refinement.
サブツリー仕様の構文は、ディレクトリ情報ツリー（DIT）のサブツリーにエントリのサブセットを仕様を仕様するための汎用メカニズムを提供します。サブツリーは、ある基盤のエントリから始まり、そのエントリの部下が識別された下の境界線まで、おそらく葉のエントリに拡張されます。サブツリーの仕様は、常にコンテキストまたは範囲内で使用され、サブツリーの境界を暗黙的に決定します。たとえば、サブスキーマ管理領域のサブツリー仕様の範囲には、サブスキーマ管理の下位管理ポイントエントリのサブツリーは含まれていません。サブツリー仕様が単一のサブツリー内のエントリの連続したサブセットを識別しない場合、コレクションはサブツリーの改良と呼ばれます。
This syntax corresponds to the SubtreeSpecification ASN.1 type described in [X.501], Section 11.3. This ASN.1 data type definition is reproduced here for completeness.
この構文は、[x.501]、セクション11.3で説明されているサブトリースの仕様asn.1タイプに対応しています。このASN.1データ型定義は、完全性のためにここに再現されています。
SubtreeSpecification ::= SEQUENCE {
base [0] LocalName DEFAULT { },
COMPONENTS OF ChopSpecification,
specificationFilter [4] Refinement OPTIONAL }
LocalName ::= RDNSequence
ChopSpecification ::= SEQUENCE {
specificExclusions [1] SET OF CHOICE {
chopBefore [0] LocalName,
chopAfter [1] LocalName } OPTIONAL,
minimum [2] BaseDistance DEFAULT 0,
maximum [3] BaseDistance OPTIONAL }
BaseDistance ::= INTEGER (0 .. MAX)
Refinement ::= CHOICE {
item [0] OBJECT-CLASS.&id,
and [1] SET OF Refinement,
or [2] SET OF Refinement,
not [3] Refinement }
The components of SubtreeSpecification are: base, which identifies the base entry of the subtree or subtree refinement, and specificExclusions, minimum, maximum and specificationFilter, which then reduce the set of subordinate entries of the base entry. The subtree or subtree refinement contains all the entries within scope that are not excluded by any of the components of the subtree specification. When all of the components of SubtreeSpecification are absent (i.e., when a value of the Subtree Specification syntax is the empty sequence, {}), the specified subtree implicitly includes all the entries within scope.
サブトレーズフィクチャ化のコンポーネントは次のとおりです。ベースは、サブツリーまたはサブツリーの改良のベースエントリ、およびspecificexclusions、最小、最大、および仕様フィルターを識別し、ベースエントリのサブワーディングエントリのセットを削減します。サブツリーまたはサブツリーの洗練には、サブツリー仕様のコンポーネントのいずれによっても除外されないスコープ内のすべてのエントリが含まれています。サブトレーズフィク化のすべてのコンポーネントが存在しない場合（つまり、サブツリー仕様の値が空のシーケンス{}である場合）、指定されたサブツリーには、範囲内のすべてのエントリが含まれます。
Any particular use of this mechanism MAY impose limitations or constraints on the components of SubtreeSpecification.
このメカニズムの特定の使用は、サブトレーズフィクチャ化のコンポーネントに制限または制約を課す可能性があります。
The LDAP syntax specification is:
LDAP構文仕様は次のとおりです。
( 1.3.6.1.4.1.1466.115.121.1.45 DESC 'SubtreeSpecification' )
（1.3.6.1.4.1.1466.115.121.1.45 DESC 'Subtreesepecification'）
The LDAP-specific encoding of values of this syntax is defined by the Generic String Encoding Rules [RFC3641]. Appendix A provides an equivalent Augmented Backus-Naur Form (ABNF) [RFC2234] for this syntax.
この構文の値のLDAP固有のエンコードは、一般的な文字列エンコードルール[RFC3641]によって定義されます。付録Aは、この構文について、同等の拡張バックスノーフォーム（ABNF）[RFC2234]を提供します。
The base component of SubtreeSpecification nominates the base entry of the subtree or subtree refinement. The base entry may be an entry which is subordinate to the root entry of the scope in which the subtree specification is used, in which case the base component contains a sequence of Relative Distinguished Names (RDNs) relative to the root entry of the scope, or may be the root entry of the scope itself (the default), in which case the base component is absent or contains an empty sequence of RDNs.
サブトレースフィシフィケーションのベースコンポーネントは、サブツリーまたはサブツリーの改良のベースエントリを指名します。ベースエントリは、サブツリー仕様が使用されるスコープのルートエントリに従属するエントリである場合があります。この場合、ベースコンポーネントには、スコープのルートエントリと比較して相対的な識別名（RDN）のシーケンスが含まれています。または、スコープ自体のルートエントリ（デフォルト）である場合があります。この場合、ベースコンポーネントは存在しないか、RDNの空のシーケンスが含まれています。
Entries that are not subordinates of the base entry are excluded from the subtree or subtree refinement.
ベースエントリの部下ではないエントリは、サブツリーまたはサブツリーの改良から除外されます。
The specificExclusions component of a ChopSpecification is a list of exclusions that specify entries and their subordinates to be excluded from the subtree or subtree refinement. The entry is specified by a sequence of RDNs relative to the base entry (i.e., a LocalName). Each exclusion is of either the chopBefore or chopAfter form. If the chopBefore form is used then the specified entry and its subordinates are excluded from the subtree or subtree refinement. If the chopAfter form is used then only the subordinates of the specified entry are excluded from the subtree or subtree refinement.
ChopSpecificationのspecificificxclusionsコンポーネントは、サブツリーまたはサブツリーの改良から除外されるエントリとその部下を指定する除外のリストです。エントリは、ベースエントリ（つまり、ローカル名）に対するRDNのシーケンスによって指定されます。それぞれの除外は、チョップ前またはチョパフターフォームのいずれかです。Chopbefore Formを使用すると、指定されたエントリとその部下は、サブツリーまたはサブツリーの洗練から除外されます。Chopafterフォームを使用する場合、指定されたエントリの部下のみがサブツリーまたはサブツリーの改良から除外されます。
The minimum and maximum components of a ChopSpecification allow the exclusion of entries based on their depth in the DIT.
チョップスケジフィケーションの最小および最大コンポーネントにより、DITの深さに基づいてエントリを除外できます。
Entries that are less than the minimum number of RDN arcs below the base entry are excluded from the subtree or subtree refinement. A minimum value of zero (the default) corresponds to the base entry.
ベースエントリ以下のRDNアークの最小数よりも少ないエントリは、サブツリーまたはサブツリーの改良から除外されます。ゼロ（デフォルト）の最小値は、ベースエントリに対応します。
Entries that are more than the maximum number of RDN arcs below the base entry are excluded from the subtree or subtree refinement. An absent maximum component indicates that there is no upper limit on the number of RDN arcs below the base entry for entries in the subtree or subtree refinement.
ベースエントリ以下のRDNアークの最大数を超えるエントリは、サブツリーまたはサブツリーの改良から除外されます。最大コンポーネントがないことは、サブツリーまたはサブツリーの改良のエントリのベースエントリ以下のRDNアークの数に上限がないことを示しています。
The specificationFilter component is a boolean expression of assertions about the values of the objectClass attribute of the base entry and its subordinates. A Refinement assertion item evaluates to true for an entry if that entry's objectClass attribute contains the OID nominated in the assertion. Entries for which the overall filter evaluates to false are excluded from the subtree refinement. If the specificationFilter is absent then no entries are excluded from the subtree or subtree refinement because of their objectClass attribute values.
SpecificationFilterコンポーネントは、ベースエントリとその部下のObjectClass属性の値に関するアサーションのブール表現です。洗練されたアサーション項目は、そのエントリのObjectClass属性にアサーションにノミネートされたOIDが含まれている場合、エントリに対してTrueを評価します。全体のフィルターがfalseに評価するエントリは、サブツリーの洗練から除外されます。SpecificationFilterが存在しない場合、オブジェクトクラスの属性値のため、サブツリーまたはサブツリーの改良からエントリは除外されません。
The Administrative Model defined in [X.501], clause 10 requires that administrative entries contain an administrativeRole attribute to indicate that the associated administrative area is concerned with one or more administrative roles.
[x.501]で定義されている管理モデル、条項10では、管理エントリが管理因子属性を含むことを要求して、関連する管理領域が1つ以上の管理職に関係していることを示します。
The administrativeRole operational attribute is specified as follows:
Administrativeroleの動作属性は、次のように指定されています。
( 2.5.18.5 NAME 'administrativeRole' EQUALITY objectIdentifierMatch USAGE directoryOperation SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
（2.5.18.5 name 'administrativerole' equality objecidentididifiermatchの使用法directoryoperation構文1.3.6.1.1.1.1.1.1.115.121.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.38）
The possible values of this attribute defined in X.501 are:
x.501で定義されているこの属性の可能な値は次のとおりです。
OID NAME
-------- -------------------------------
2.5.23.1 autonomousArea
2.5.23.2 accessControlSpecificArea
2.5.23.3 accessControlInnerArea
2.5.23.4 subschemaAdminSpecificArea
2.5.23.5 collectiveAttributeSpecificArea
2.5.23.6 collectiveAttributeInnerArea
Other values may be defined in other specifications. Names associated with each administrative role are Object Identifier Descriptors [RFC3383].
他の値は、他の仕様で定義される場合があります。各管理ロールに関連付けられた名前は、オブジェクト識別子記述子[RFC3383]です。
The administrativeRole operational attribute is also used to regulate the subentries permitted to be subordinate to an administrative entry. A subentry not of a class permitted by the administrativeRole attribute cannot be subordinate to the administrative entry.
Administrativeroleの運用属性は、管理エントリに従属することが許可されているサブエントリを規制するためにも使用されます。Administrativerole属性によって許可されているクラスではないサブエントリーは、管理エントリに従属することはできません。
The subtreeSpecification operational attribute is defined as follows:
サブトリースの操作属性は、次のように定義されています。
( 2.5.18.6 NAME 'subtreeSpecification' SINGLE-VALUE USAGE directoryOperation SYNTAX 1.3.6.1.4.1.1466.115.121.1.45 )
（2.5.18.6名前「subtreesepecification」 '単一価値の使用ディレクトリオペレーション構文1.3.6.1.4.1.146.115.121.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.45）
This attribute is present in all subentries. See [X.501], clause 10. Values of the subtreeSpecification attribute nominate collections of entries within the DIT for one or more aspects of administrative authority.
この属性は、すべてのサブエントリに存在します。[X.501]、条項10を参照してください。管理当局の1つ以上の側面について、DIT内のエントリのコレクションを指名するサブトレースフィシフィケーション属性の値。
The subentry object class is a structural object class.
Subentryオブジェクトクラスは、構造オブジェクトクラスです。
( 2.5.17.0 NAME 'subentry' SUP top STRUCTURAL MUST ( cn $ subtreeSpecification ) )
（2.5.17.0 name 'subentry' sup top structural must（cn $ subtreespecification））
The subentries control MAY be sent with a searchRequest to control the visibility of entries and subentries which are within scope. Non-visible entries or subentries are not returned in response to the request.
Subentriesコントロールは、SearchRequestで送信され、範囲内のエントリとサブエントリの可視性を制御できます。依存しないエントリまたはサブエントリは、リクエストに応じて返されません。
The subentries control is an LDAP Control whose controlType is 1.3.6.1.4.1.4203.1.10.1, criticality is TRUE or FALSE (hence absent), and controlValue contains a BER-encoded BOOLEAN indicating visibility. A controlValue containing the value TRUE indicates that subentries are visible and normal entries are not. A controlValue containing the value FALSE indicates that normal entries are visible and subentries are not.
Subentriesコントロールは、ControlTypeが1.3.6.1.4.1.4203.1.10.1であるLDAPコントロールであり、臨界性は真または偽であり（したがって存在しない）、ControlValueには、可視性を示すバーエンコードされたブール値が含まれています。true値を含む制御値は、サブエントリが見えることを示し、通常のエントリはそうではないことを示します。値のfalseを含む制御値は、通常のエントリが表示され、サブエントリが表示されないことを示します。
Note that TRUE visibility has the three octet encoding { 01 01 FF } and FALSE visibility has the three octet encoding { 01 01 00 }.
真の可視性には、3つのオクテットエンコード{01 01 ff}があり、偽の可視性には3つのオクテットエンコード{01 01 00}があることに注意してください。
The controlValue SHALL NOT be absent.
ControlValueは存在しないものとします。
In absence of this control, subentries are not visible to singleLevel and wholeSubtree scope Search requests but are visible to baseObject scope Search requests.
このコントロールがない場合、SubentriesはSinglelevelおよびWholesubtree Scope Searchリクエストには見えませんが、BaseObject Scope Searchリクエストに表示されます。
There is no corresponding response control.
対応する応答制御はありません。
This control is not appropriate for non-Search operations.
この制御は、非検索操作には適していません。
Subentries often hold administrative information or other sensitive information and should be protected from unauthorized access and disclosure as described in [RFC2829][RFC2830].
Subentriesは、多くの場合、管理情報またはその他の機密情報を保持しており、[RFC2829] [RFC2830]に記載されているように、不正アクセスと開示から保護する必要があります。
General LDAP [RFC3377] security considerations also apply.
一般LDAP [RFC3377]セキュリティ上の考慮事項も適用されます。
The IANA has registered the LDAP descriptors detailed in this technical specification. The following registration template is suggested:
IANAは、この技術仕様に詳述されているLDAP記述子を登録しています。次の登録テンプレートをお勧めします。
Subject: Request for LDAP Descriptor Registration Descriptor (short name): see comment Object Identifier: see comment Person & email address to contact for further information: Kurt Zeilenga <kurt@OpenLDAP.org> Usage: see comment Specification: RFC3672 Author/Change Controller: IESG Comments:
件名：LDAP記述子登録記述子のリクエスト（ショート名）：コメントオブジェクト識別子を参照：詳細については、連絡先のコメント担当者とメールアドレスを参照してください：Kurt Zeilenga <kurt@openldap.org>使用法：コメントの仕様：rfc3672著者/変更コントローラーを参照してください：IESGコメント：
NAME Type OID
------------------------ ---- --------
accessControlInnerArea R 2.5.23.3
accessControlSpecificArea R 2.5.23.2
administrativeRole A 2.5.18.5
autonomousArea R 2.5.23.1
collectiveAttributeInnerArea R 2.5.23.6
collectiveAttributeSpecificArea R 2.5.23.5
subentry O 2.5.17.0
subschemaAdminSpecificArea R 2.5.23.4
subtreeSpecification A 2.5.18.6
where Type A is Attribute, Type O is ObjectClass, and Type R is Administrative Role.
タイプAは属性、タイプOはオブジェクトクラス、タイプRは管理ロールです。
This document uses the OID 1.3.6.1.4.1.4203.1.10.1 to identify an LDAP protocol element defined herein. This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its IANA-assigned private enterprise allocation [PRIVATE], for use in this specification.
このドキュメントでは、OID 1.3.6.1.4.1.4.1.4203.1.10.1を使用して、本明細書で定義されているLDAPプロトコル要素を識別します。このOIDは、この仕様で使用するために、IANAが割り当てられた民間企業配分[Private]に基づいて、OpenLdap Foundationによって割り当てられました。
Other OIDs which appear in this document were either assigned by the ISO/IEC Joint Technical Committee 1 - Subcommittee 6 to identify elements of X.500 schema or assigned in RFC 2252 for the use described here.
このドキュメントに登場する他のOIDは、ISO/IEC共同技術委員会1によって割り当てられました-X.500スキーマの要素を特定するか、ここで説明するためにRFC 2252に割り当てられました。
The IANA has registered the LDAP protocol mechanisms [RFC3383] detailed in this specification.
IANAは、この仕様で詳述されているLDAPプロトコルメカニズム[RFC3383]を登録しています。
Subject: Request for LDAP Protocol Mechanism Registration
件名：LDAPプロトコルメカニズム登録のリクエスト
Description: Subentries
説明：Subentries
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Control
使用法：コントロール
Specification: RFC3672
仕様：RFC3672
Author/Change Controller: IESG
著者/変更コントローラー：IESG
Comments: none
コメント：なし
This document is based on engineering done by IETF LDUP and LDAPext Working Groups including "LDAP Subentry Schema" by Ed Reed. This document also borrows from a number of ITU documents including X.501.
このドキュメントは、IETF LDUPによって行われたエンジニアリングと、Ed Reedによる「LDAP Subentry Schema」を含むLDAPextワーキンググループに基づいています。このドキュメントは、X.501を含む多くのITUドキュメントからも借用しています。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、関心のある当事者に、この基準を実践するために必要な技術をカバーする可能性のある著作権、特許、または特許出願、またはその他の独自の権利を注意深く招待するよう招待しています。情報をIETFエグゼクティブディレクターに宛ててください。
A. Subtree Specification ABNF
A.サブツリー仕様ABNF
This appendix is non-normative.
この付録は非規範的です。
The LDAP-specific string encoding for the Subtree Specification syntax is specified by the Generic String Encoding Rules [RFC3641]. The ABNF [RFC2234] in this appendix for this syntax is provided only as a convenience and is equivalent to the encoding specified by the application of [RFC3641]. Since the SubtreeSpecification ASN.1 type may be extended in future editions of [X.501], the provided ABNF should be regarded as a snapshot in time. The LDAP-specific encoding for any extension to the SubtreeSpecification ASN.1 type can be determined from [RFC3641].
サブツリー仕様の構文のためのLDAP固有の文字列エンコードは、一般的な文字列エンコードルール[RFC3641]によって指定されています。この構文のこの付録のABNF [RFC2234]は、利便性としてのみ提供され、[RFC3641]の適用によって指定されたエンコードと同等です。サブトレースフィク化ASN.1タイプは[X.501]の将来のエディションで拡張される可能性があるため、提供されたABNFは時間内にスナップショットと見なされるべきです。サブトレース分割ASN.1タイプへの任意の拡張のためのLDAP固有のエンコードは、[RFC3641]から決定できます。
In the event that there is a discrepancy between this ABNF and the encoding determined by [RFC3641], [RFC3641] is to be taken as definitive.
このABNFと[RFC3641]によって決定されるエンコーディングの間に矛盾がある場合、[RFC3641]は決定的なものと見なされるべきです。
SubtreeSpecification = "{" [ sp ss-base ]
[ sep sp ss-specificExclusions ]
[ sep sp ss-minimum ]
[ sep sp ss-maximum ]
[ sep sp ss-specificationFilter ]
sp "}"
ss-base = id-base msp LocalName
ss-specificExclusions = id-specificExclusions msp
SpecificExclusions
ss-minimum = id-minimum msp BaseDistance
ss-maximum = id-maximum msp BaseDistance
ss-specificationFilter = id-specificationFilter msp Refinement
id-base = %x62.61.73.65 ; "base"
id-specificExclusions = %x73.70.65.63.69.66.69.63.45.78.63.6C.75.73
%x69.6F.6E.73 ; "specificExclusions"
id-minimum = %x6D.69.6E.69.6D.75.6D ; "minimum"
id-maximum = %x6D.61.78.69.6D.75.6D ; "maximum"
id-specificationFilter = %x73.70.65.63.69.66.69.63.61.74.69.6F.6E.46
%x69.6C.74.65.72 ; "specificationFilter"
SpecificExclusions = "{" [ sp SpecificExclusion
*( "," sp SpecificExclusion ) ] sp "}"
SpecificExclusion = chopBefore / chopAfter
chopBefore = id-chopBefore ":" LocalName
chopAfter = id-chopAfter ":" LocalName
id-chopBefore = %x63.68.6F.70.42.65.66.6F.72.65 ; "chopBefore"
id-chopAfter = %x63.68.6F.70.41.66.74.65.72 ; "chopAfter"
Refinement = item / and / or / not
item = id-item ":" OBJECT-IDENTIFIER
and = id-and ":" Refinements
or = id-or ":" Refinements
not = id-not ":" Refinement
Refinements = "{" [ sp Refinement
*( "," sp Refinement ) ] sp "}"
id-item = %x69.74.65.6D ; "item"
id-and = %x61.6E.64 ; "and"
id-or = %x6F.72 ; "or"
id-not = %x6E.6F.74 ; "not"
BaseDistance = INTEGER-0-MAX
The <sp>, <msp>, <sep>, <INTEGER>, <INTEGER-0-MAX>, <OBJECT-IDENTIFIER> and <LocalName> rules are defined in [RFC3642].
<sp>、<msp>、<sep>、<integer>、<integer-0-max>、<Object-Identifier>、<ColtmentName>ルールは[RFC3642]で定義されています。
Normative References
引用文献
[X.501] ITU-T, "The Directory -- Models," X.501, 1993.
[X.501] ITU-T、「ディレクトリ - モデル」、X.501、1993。
[X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", X.680, 1994.
[X.680] ITU -T、「抽象的構文表記1（ASN.1） - 基本表記の仕様」、X.680、1994。
[X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic, Canonical, and Distinguished Encoding Rules", X.690, 1994.
[X.690] ITU-T、「ASN.1エンコーディングルールの仕様：基本、標準、および識別されたエンコードルール」、X.690、1994。
[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月。
[RFC2829] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan, "Authentication Methods for LDAP", RFC 2829, May 2000.
[RFC2829] Wahl、M.、Alvestrand、H.、Hodges、J。and R. Morgan、「LDAPの認証方法」、RFC 2829、2000年5月。
[RFC2830] Hodges, J., Morgan, R. and M. Wahl, "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security", RFC 2830, May 2000.
[RFC2830] Hodges、J.、Morgan、R。、およびM. Wahl、「Lightweight Directory Access Protocol（V3）：輸送層のセキュリティの拡張」、RFC 2830、2000年5月。
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002.
[RFC3377] Hodges、J。およびR. Morgan、「Lightweight Directory Access Protocol（V3）：技術仕様」、RFC 3377、2002年9月。
[RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", RFC 3383, September 2002.
[RFC3383] Zeilenga、K。、「Internet Assigned Numbers Authority（IANA）のLightweight Directory Access Protocol（LDAP）の考慮事項」、RFC 3383、2002年9月。
[RFC3641] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1 Types", RFC 3641, October 2003.
[RFC3641] Legg、S。、「ASN.1タイプの一般的な文字列エンコードルール（GSER）」、RFC 3641、2003年10月。
Informative References
参考引用
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC2234] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 2234、1997年11月。
[RFC3642] Legg, S., "Common Elements of Generic String Encoding Rules (GSER) Encodings", RFC 3642, October 2003.
[RFC3642] Legg、S。、「一般的な文字列エンコーディングルール（GSER）エンコーディングの共通要素」、RFC 3642、2003年10月。
[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", http://www.openldap.org/foundation/oid-delegate.txt
[assional] OpenLdap Foundation、「OpenLdap Oid Delegations」、http://www.openldap.org/foundation/oid-delegate.txt
[PRIVATE] IANA, "Private Enterprise Numbers", http://www.iana.org/assignments/enterprise-numbers
[プライベート] IANA、「プライベートエンタープライズ番号」、http：//www.iana.org/assignments/enterprise-numbers
Authors' Addresses
著者のアドレス
Kurt D. Zeilenga OpenLDAP Foundation
Kurt D. Zeilenga OpenLdap Foundation
EMail: Kurt@OpenLDAP.org
Steven Legg Adacel Technologies Ltd. 250 Bay Street Brighton, Victoria 3186 AUSTRALIA
Steven Legg Adacel Technologies Ltd. 250 Bay Street Brighton、Victoria 3186 Australia
Phone: +61 3 8530 7710
Fax: +61 3 8530 7888
EMail: steven.legg@adacel.com.au
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
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 assignees.
上記の限られた許可は永続的であり、インターネット社会やその後継者または譲受人によって取り消されることはありません。
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エディター機能の資金は現在、インターネット協会によって提供されています。