Network Working Group K. Zeilenga
Request for Comments: 4512 OpenLDAP Foundation
Obsoletes: 2251, 2252, 2256, 3674 June 2006
Category: Standards Track
Lightweight Directory Access Protocol (LDAP):
Directory Information Models
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 (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
The Lightweight Directory Access Protocol (LDAP) is an Internet protocol for accessing distributed directory services that act in accordance with X.500 data and service models. This document describes the X.500 Directory Information Models, as used in LDAP.
LDAP（Lightweight Directory Access Protocol）はX.500データとサービスモデルに従って行動分散ディレクトリサービスにアクセスするためのインターネットプロトコルです。このドキュメントでは、LDAPで使用されるように、X.500ディレクトリ情報モデルを記述する。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Relationship to Other LDAP Specifications ..................3
1.2. Relationship to X.501 ......................................4
1.3. Conventions ................................................4
1.4. Common ABNF Productions ....................................4
2. Model of Directory User Information .............................6
2.1. The Directory Information Tree .............................7
2.2. Structure of an Entry ......................................7
2.3. Naming of Entries ..........................................8
2.4. Object Classes .............................................9
2.5. Attribute Descriptions ....................................12
2.6. Alias Entries .............................................16
3. Directory Administrative and Operational Information ...........17
3.1. Subtrees ..................................................17
3.2. Subentries ................................................18
3.3. The 'objectClass' attribute ...............................18
3.4. Operational Attributes ....................................19
4. Directory Schema ...............................................22
4.1. Schema Definitions ........................................23
4.2. Subschema Subentries ......................................32
4.3. 'extensibleObject' object class ...........................35
4.4. Subschema Discovery .......................................35
5. DSA (Server) Informational Model ...............................36
5.1. Server-Specific Data Requirements .........................36
6. Other Considerations ...........................................40
6.1. Preservation of User Information ..........................40
6.2. Short Names ...............................................41
6.3. Cache and Shadowing .......................................41
7. Implementation Guidelines ......................................42
7.1. Server Guidelines .........................................42
7.2. Client Guidelines .........................................42
8. Security Considerations ........................................43
9. IANA Considerations ............................................43
10. Acknowledgements ..............................................44
11. Normative References ..........................................45
Appendix A. Changes ...............................................47
A.1. Changes to RFC 2251 .......................................47
A.2. Changes to RFC 2252 .......................................49
A.3. Changes to RFC 2256 .......................................50
A.4. Changes to RFC 3674 .......................................51
This document discusses the X.500 Directory Information Models [X.501], as used by the Lightweight Directory Access Protocol (LDAP) [RFC4510].
この文書では、Lightweight Directory Access Protocol（LDAP）[RFC4510]で使用されるように、[X.501] X.500ディレクトリ情報モデルについて説明します。
The Directory is "a collection of open systems cooperating to provide directory services" [X.500]. The information held in the Directory is collectively known as the Directory Information Base (DIB). A Directory user, which may be a human or other entity, accesses the Directory through a client (or Directory User Agent (DUA)). The client, on behalf of the directory user, interacts with one or more servers (or Directory System Agents (DSA)). A server holds a fragment of the DIB.
ディレクトリは、[X.500]「ディレクトリサービスを提供するために協力し、オープンシステムの集合」です。ディレクトリに保持された情報をまとめてディレクトリ情報ベース（DIB）として知られています。ヒトまたは他のエンティティであってもよいDirectoryユーザーは、クライアント（またはディレクトリユーザーエージェント（DUA））を介してディレクトリにアクセスします。クライアントは、ディレクトリユーザーの代わりに、1つ以上のサーバ（またはディレクトリシステムエージェント（DSA））と対話します。サーバーは、DIBの断片を保持しています。
The DIB contains two classes of information:
DIBは、情報の2つのクラスが含まれています。
1) user information (e.g., information provided and administrated by users). Section 2 describes the Model of User Information.
1）ユーザ情報（例えば、情報のユーザによって提供され、投与）。第2節では、ユーザー情報のモデルを記述しています。
2) administrative and operational information (e.g., information used to administer and/or operate the directory). Section 3 describes the model of Directory Administrative and Operational Information.
2）管理および動作情報ディレクトリを管理および/または操作するために使用される（例えば、情報）。第3節では、Directory管理と運用情報のモデルを記述しています。
These two models, referred to as the generic Directory Information Models, describe how information is represented in the Directory. These generic models provide a framework for other information models. Section 4 discusses the subschema information model and subschema discovery. Section 5 discusses the DSA (Server) Informational Model.
一般的なディレクトリ情報モデルと呼ばれるこれらの2つのモデルが、情報がディレクトリにどのように表現されるかを説明します。これらの一般的なモデルは、他の情報モデルのためのフレームワークを提供します。第4章では、サブスキーマ情報モデルとサブスキーマ発見を説明します。第5節では、DSA（サーバー）の情報モデルについて説明します。
Other X.500 information models (such as access control distribution knowledge and replication knowledge information models) may be adapted for use in LDAP. Specification of how these models apply to LDAP is left to future documents.
（そのようなアクセス制御分布の知識および複製知識情報モデルのような）他のX.500情報モデルは、LDAPで使用するために適合させることができます。これらのモデルは、LDAPにどのように適用されるかの仕様は、将来の文書に残されています。
This document is a integral part of the LDAP technical specification [RFC4510], which obsoletes the previously defined LDAP technical specification, RFC 3377, in its entirety.
この文書は、その全体が、先に定義されたLDAP技術仕様、RFC 3377を時代遅れLDAP技術仕様書[RFC4510]の不可欠な部分です。
This document obsoletes RFC 2251, Sections 3.2 and 3.4, as well as portions of Sections 4 and 6. Appendix A.1 summarizes changes to these sections. The remainder of RFC 2251 is obsoleted by the [RFC4511], [RFC4513], and [RFC4510] documents.
この文書は、RFC 2251、セクション3.2および3.4、ならびにセクション4及び6付録A.1は、これらのセクションへの変更を要約の部分を廃止します。 RFC 2251の残りは[RFC4511]、[RFC4513]及び[RFC4510]文書によって廃止されています。
This document obsoletes RFC 2252, Sections 4, 5, and 7. Appendix A.2 summarizes changes to these sections. The remainder of RFC 2252 is obsoleted by [RFC4517].
この文書は、RFC 2252を廃止セクション4、5、および7付録A.2は、これらのセクションへの変更をまとめたもの。 RFC 2252の残りの部分は、[RFC4517]によって廃止されています。
This document obsoletes RFC 2256, Sections 5.1, 5.2, 7.1, and 7.2. Appendix A.3 summarizes changes to these sections. The remainder of RFC 2256 is obsoleted by [RFC4519] and [RFC4517].
この文書はRFC 2256、セクション5.1、5.2、7.1、および7.2を廃止します。付録A.3は、これらのセクションへの変更をまとめたもの。 RFC 2256の残りは[RFC4519]及び[RFC4517]によって廃止されます。
This document obsoletes RFC 3674 in its entirety. Appendix A.4 summarizes changes since RFC 3674.
この文書は、その全体がRFC 3674を廃止します。付録A.4は、RFC 3674からの変更をまとめたもの。
This document includes material, with and without adaptation, from [X.501] as necessary to describe this protocol. These adaptations (and any other differences herein) apply to this protocol, and only this protocol.
この文書は、このプロトコルを記述するために、必要に応じて[X.501]から、適応ととせずに、材料を含みます。これらの適応（および本明細書の他の相違点）は、このプロトコルのみこのプロトコルに適用されます。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14 [RFC2119]に記載されているように解釈されます。
Schema definitions are provided using LDAP description formats (as defined in Section 4.1). Definitions provided here are formatted (line wrapped) for readability. Matching rules and LDAP syntaxes referenced in these definitions are specified in [RFC4517].
（セクション4.1で定義されるように）スキーマ定義は、LDAPの記述形式を用いて提供されます。ここで提供される定義は、読みやすくするために（ラップラインを）フォーマットされています。これらの定義で参照マッチングルールやLDAP構文は、[RFC4517]で指定されています。
A number of syntaxes in this document are described using Augmented Backus-Naur Form (ABNF) [RFC4234]. These syntaxes (as well as a number of syntaxes defined in other documents) rely on the following common productions:
この文書の構文の数は、拡張バッカス・ナウアフォーム（ABNF）[RFC4234]を使用して記載されています。これらの構文（だけでなく、他のドキュメントで定義された構文の数）は、次の一般的な制作に依存しています：
keystring = leadkeychar *keychar leadkeychar = ALPHA keychar = ALPHA / DIGIT / HYPHEN number = DIGIT / ( LDIGIT 1*DIGIT )
キー文字列= leadkeychar *は、keyChar leadkeychar = ALPHAは、keyChar = ALPHA / DIGIT /ハイフン番号= DIGIT /（* DIGIT LDIGIT 1）
ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z" DIGIT = %x30 / LDIGIT ; "0"-"9" LDIGIT = %x31-39 ; "1"-"9" HEX = DIGIT / %x41-46 / %x61-66 ; "0"-"9" / "A"-"F" / "a"-"f"
ALPHA =％x41-5A /％x61-7A。 "A" - "Z" / "A" - "Z" DIGIT =％X30 / LDIGIT。 "0" - "9" LDIGIT =％x31-39。 "1" - "9" HEX = DIGIT /％x41-46 /％x61-66。 "0" - "9" / "A" - "F" / "A" - "F"
SP = 1*SPACE ; one or more " " WSP = 0*SPACE ; zero or more " "
SP = 1 * SPACE。 1つ以上の「」WSP = 0 *空間。ゼロまたはそれ以上の「」
NULL = %x00 ; null (0) SPACE = %x20 ; space (" ") DQUOTE = %x22 ; quote (""") SHARP = %x23 ; octothorpe (or sharp sign) ("#") DOLLAR = %x24 ; dollar sign ("$") SQUOTE = %x27 ; single quote ("'") LPAREN = %x28 ; left paren ("(") RPAREN = %x29 ; right paren (")") PLUS = %x2B ; plus sign ("+") COMMA = %x2C ; comma (",") HYPHEN = %x2D ; hyphen ("-") DOT = %x2E ; period (".") SEMI = %x3B ; semicolon (";") LANGLE = %x3C ; left angle bracket ("<") EQUALS = %x3D ; equals sign ("=") RANGLE = %x3E ; right angle bracket (">") ESC = %x5C ; backslash ("\") USCORE = %x5F ; underscore ("_") LCURLY = %x7B ; left curly brace "{" RCURLY = %x7D ; right curly brace "}"
NULL =％X00。ヌル（0）SPACE =％のX20。スペース（」「）DQUOTE =％X22。引用符（ "" "）シャープ=％のX23;シャープ（またはシャープ記号）（" ＃ "）DOLLAR =％のX24、ドル記号（" $ "）SQUOTE =％X27;単一引用符（" ' "）LPAREN =％X28 ;左括弧（ "（"）RPAREN =％X29;右の括弧（ "）"）PLUS =％X2B、プラス記号（ "+"）COMMA =％X2C;カンマ（ ""）ハイフン=％x2D;ハイフン（ " "; " - "）DOT =％のx2E期間（）SEMI =％のX3B;セミコロン（"; "）LANGLE =％X3C;左山括弧（"< "）は=％X3D等しく、等号（"=" ）RANGLE =％Spark Proの、直角ブラケット（ ">"）ESC =％x5C;バックスラッシュ（ "\"）USCORE =％x5F;（ "_"）を強調LCURLY =％x7B;左中括弧 "{" RCURLY =％ x7D、右中括弧「}」
; Any UTF-8 [RFC3629] encoded Unicode [Unicode] character UTF8 = UTF1 / UTFMB UTFMB = UTF2 / UTF3 / UTF4 UTF0 = %x80-BF UTF1 = %x00-7F UTF2 = %xC2-DF UTF0 UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) / %xED %x80-9F UTF0 / %xEE-EF 2(UTF0) UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) / %xF4 %x80-8F 2(UTF0)
;任意UTF8 [RFC3629]はエンコードされたUnicode [UNICODE]文字UTF8 = UTF1 / UTFMB UTFMB = UTF2 / UTF3 / UTF4 UTF0 =％X80-BF UTF1 =％x00-7F UTF2 =％XC2-DF UTF0 UTF3 =％xE0％XA0 -BF UTF0 /％XE1-EC 2（UTF0）/％XED％x80-9F UTF0 /％XEE-EF 2（UTF0）UTF4 =％XF0％X90-BF 2（UTF0）/％XF1-F3 3（UTF0） /％XF4％x80-8F 2（UTF0）
OCTET = %x00-FF ; Any octet (8-bit data unit)
OCTET =％X00-FF。任意のオクテット（8ビット・データ・ユニット）
Object identifiers (OIDs) [X.680] are represented in LDAP using a dot-decimal format conforming to the ABNF:
オブジェクト識別子（OID）[X.680] ABNFに準拠したドット付き10進表記を使用して、LDAPで表されます。
numericoid = number 1*( DOT number )
numericoid =番号1 *（ドット数）
Short names, also known as descriptors, are used as more readable aliases for object identifiers. Short names are case insensitive and conform to the ABNF:
また、記述子として知られる短い名前は、オブジェクト識別子のためのより読みやすい別名として使用されています。ショート名は大文字小文字を区別しないで、ABNFに準拠します：
descr = keystring
DESCR =キー文字列
Where either an object identifier or a short name may be specified, the following production is used:
オブジェクト識別子または短い名前のいずれかを指定することができる場合、次の生産が使用されます。
oid = descr / numericoid
OID = DESCR / numericoid
While the <descr> form is generally preferred when the usage is restricted to short names referring to object identifiers that identify like kinds of objects (e.g., attribute type descriptions, matching rule descriptions, object class descriptions), the <numericoid> form should be used when the object identifiers may identify multiple kinds of objects or when an unambiguous short name (descriptor) is not available.
使用量はオブジェクトの種類のような特定の識別子をオブジェクトを参照する短い名前に制限されている場合、<DESCR>フォームは、一般的に好ましいが（例えば、属性タイプの説明は、ルールの説明、オブジェクト・クラスの説明と一致する）、<numericoid>フォームがなければなりませんオブジェクト識別子は、オブジェクトの複数の種類を識別することができるとき、または明確な短い名前（記述子）が利用できないときに使用されます。
Implementations SHOULD treat short names (descriptors) used in an ambiguous manner (as discussed above) as unrecognized.
実装では、認識されないように（上述のように）あいまいな方法で使用される短い名前（記述子）を治療すべきです。
Short Names (descriptors) are discussed further in Section 6.2.
短縮名（記述子）は6.2節で詳しく説明されています。
As [X.501] states:
[X.501]状態として：
The purpose of the Directory is to hold, and provide access to, information about objects of interest (objects) in some 'world'. An object can be anything which is identifiable (can be named).
ディレクトリの目的は、保持し、いくつかの「世界の関心のオブジェクト（オブジェクト）について、情報へのアクセスを提供することです。オブジェクトは（名前を付けることができます）に識別され何もすることができます。
An object class is an identified family of objects, or conceivable objects, which share certain characteristics. Every object belongs to at least one class. An object class may be a subclass of other object classes, in which case the members of the former class, the subclass, are also considered to be members of the latter classes, the superclasses. There may be subclasses of subclasses, etc., to an arbitrary depth.
オブジェクトクラスは、特定の特性を共有するオブジェクト、または考えられるオブジェクトの識別されたファミリーです。すべてのオブジェクトは、少なくとも1つのクラスに属します。オブジェクトクラスは、前者のクラス、サブクラスのメンバーは、また、後者のクラスのメンバーであると考えられ、その場合に、他のオブジェクトクラス、スーパークラスのサブクラスであってもよいです。任意の深さまでなどのサブクラスのサブクラス、があるかもしれません。
A directory entry, a named collection of information, is the basic unit of information held in the Directory. There are multiple kinds of directory entries.
ディレクトリエントリ、情報の名前のコレクションは、ディレクトリに保持されている情報の基本単位です。ディレクトリエントリの複数の種類があります。
An object entry represents a particular object. An alias entry provides alternative naming. A subentry holds administrative and/or operational information.
オブジェクトエントリは、特定のオブジェクトを表します。別名エントリは、代替ネーミングを提供します。サブエントリは、管理および/または動作情報を保持しています。
The set of entries representing the DIB are organized hierarchically in a tree structure known as the Directory Information Tree (DIT).
DIBを表すエントリのセットは、ディレクトリ情報ツリー（DIT）として知られているツリー構造で階層的に編成されています。
Section 2.1 describes the Directory Information Tree. Section 2.2 discusses the structure of entries. Section 2.3 discusses naming of entries.
2.1節は、ディレクトリ情報ツリーを示します。 2.2節ではエントリの構造について説明します。 2.3節ではエントリの命名について説明します。
Section 2.4 discusses object classes. Section 2.5 discusses attribute descriptions. Section 2.6 discusses alias entries.
2.4節を議論は、クラスオブジェクト。 2.5節を議論の属性の説明。 2.6節は、別名エントリについて説明します。
As noted above, the DIB is composed of a set of entries organized hierarchically in a tree structure known as the Directory Information Tree (DIT); specifically, a tree where vertices are the entries.
上述したように、DIBは、ディレクトリ情報ツリー（DIT）として知られる木構造に階層的に編成エントリのセットで構成されています。具体的には、頂点がエントリーされている木。
The arcs between vertices define relations between entries. If an arc exists from X to Y, then the entry at X is the immediate superior of Y, and Y is the immediate subordinate of X. An entry's superiors are the entry's immediate superior and its superiors. An entry's subordinates are all of its immediate subordinates and their subordinates.
頂点間のアークはエントリ間の関係を定義します。アークはXからYに存在する場合、Xのエントリは、Yの即時優れており、YはXの即時従属するエントリの上司は、エントリの即時優れとその上司です。エントリーの部下は、その直接の部下と部下のすべてです。
Similarly, the superior/subordinate relationship between object entries can be used to derive a relation between the objects they represent. DIT structure rules can be used to govern relationships between objects.
同様に、オブジェクトエントリ間の上位/下位の関係は、それらが表すオブジェクトの間の関係を導出するために使用することができます。 DIT構造規則は、オブジェクト間の関係を管理するために使用することができます。
Note: An entry's immediate superior is also known as the entry's parent, and an entry's immediate subordinate is also known as the entry's child. Entries that have the same parent are known as siblings.
注意：エントリのも、エントリの親として知られて即時に優れた、およびエントリの直接の部下も、エントリの子として知られています。同じ親を持つエントリは兄弟として知られています。
An entry consists of a set of attributes that hold information about the object that the entry represents. Some attributes represent user information and are called user attributes. Other attributes represent operational and/or administrative information and are called operational attributes.
エントリは、エントリが表すオブジェクトに関する情報を保持する属性のセットから成ります。一部の属性は、ユーザ情報を表し、ユーザー属性と呼ばれています。他の属性は、動作および/または管理情報を表し、操作属性と呼ばれています。
An attribute is an attribute description (a type and zero or more options) with one or more associated values. An attribute is often referred to by its attribute description. For example, the 'givenName' attribute is the attribute that consists of the attribute description 'givenName' (the 'givenName' attribute type [RFC4519] and zero options) and one or more associated values.
属性は、一つ以上の関連する値を有する属性記述（タイプおよびゼロ以上のオプション）です。属性は、多くの場合、その属性記述によって参照されます。たとえば、「givenName属性」属性は、属性記述「givenName属性」（「givenName属性」属性タイプ[RFC4519]及びゼロオプション）と、1つの以上の関連する値で構成属性です。
The attribute type governs whether the attribute can have multiple values, the syntax and matching rules used to construct and compare values of that attribute, and other functions. Options indicate subtypes and other functions.
属性タイプは、属性が複数の値、その属性の値を構築し、比較するために使用される構文とマッチングルール、および他の機能を有することができるかどうかを支配します。オプションは、サブタイプおよびその他の機能を示しています。
Attribute values conform to the defined syntax of the attribute type.
属性値は、属性の型の定義された構文に準拠しています。
No two values of an attribute may be equivalent. Two values are considered equivalent if and only if they would match according to the equality matching rule of the attribute type. Or, if the attribute type is defined with no equality matching rule, two values are equivalent if and only if they are identical. (See 2.5.1 for other restrictions.)
属性のどの2つの値が同等でないかもしれません。 2つの値があれば等価であると考えられると、彼らは属性タイプのルールに一致平等によると一致した場合にのみ。属性タイプが無い平等マッチングルールで定義されている場合や、2つの値があれば同等であり、これらは同一である場合にのみ。 （他の制限については2.5.1を参照してください。）
For example, a 'givenName' attribute can have more than one value, they must be Directory Strings, and they are case insensitive. A 'givenName' attribute cannot hold both "John" and "JOHN", as these are equivalent values per the equality matching rule of the attribute type.
たとえば、「givenName属性」属性が複数の値を持つことができ、彼らはディレクトリ文字列でなければならない、と彼らは大文字と小文字を区別しません。これらは属性タイプのルールに一致平等あたり同等の値であるとして「givenName属性」属性は、「ジョン」と「JOHN」の両方を保持することはできません。
Additionally, no attribute is to have a value that is not equivalent to itself. For example, the 'givenName' attribute cannot have as a value a directory string that includes the REPLACEMENT CHARACTER (U+FFFD) code point, as matching involving that directory string is Undefined per this attribute's equality matching rule.
また、何の属性は、それ自体に等価ではない値を持つことはありません。たとえば、「givenName属性」属性は、値として、そのディレクトリの文字列を含むマッチングがこの属性の平等マッチングルールごとに定義されていないとして、置換文字（U + FFFD）コードポイントを含んでいるディレクトリ文字列を持つことはできません。
When an attribute is used for naming of the entry, one and only one value of the attribute is used in forming the Relative Distinguished Name. This value is known as a distinguished value.
属性は、エントリの命名に使用されている場合は、1と属性の一つの値だけが相対識別名を形成するのに使用されています。この値は、識別値として知られています。
Each entry is named relative to its immediate superior. This relative name, known as its Relative Distinguished Name (RDN) [X.501], is composed of an unordered set of one or more attribute value assertions (AVA) consisting of an attribute description with zero options and an attribute value. These AVAs are chosen to match attribute values (each a distinguished value) of the entry.
各エントリは、その直接の優れたに対する命名されます。その相対識別名（RDN）として知られるこの相対名、[X.501]は、ゼロオプションと属性記述及び属性値からなる1つ以上の属性値表明（AVA）の非順序集合で構成されています。これらのAVAは、エントリの属性値（各識別値）と一致するように選択されます。
An entry's relative distinguished name must be unique among all immediate subordinates of the entry's immediate superior (i.e., all siblings).
エントリの相対識別名はエントリの即時優れた（すなわち、すべての兄弟）のすべての即時部下の中で一意でなければなりません。
The following are examples of string representations of RDNs [RFC4514]:
RDN [RFC4514]の文字列表現の例です。
UID=12345 OU=Engineering CN=Kurt Zeilenga+L=Redwood Shores
UID = 12345 OU =エンジニアリングCNはクルトZeilenga + L =レッドウッドショアーズを=
The last is an example of a multi-valued RDN; that is, an RDN composed of multiple AVAs.
最後は、多値RDNの例です。それは、複数のAVAで構成されるRDNです。
An entry's fully qualified name, known as its Distinguished Name (DN) [X.501], is the concatenation of its RDN and its immediate superior's DN. A Distinguished Name unambiguously refers to an entry in the tree. The following are examples of string representations of DNs [RFC4514]:
その識別名（DN）として知られているエントリの完全修飾名、[X.501]は、そのRDNとその直接の上司のDNを連結したものです。識別名は、明確ツリー内のエントリを参照します。 DNは[RFC4514]の文字列表現の例です。
UID=nobody@example.com,DC=example,DC=com CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US
UID =誰も@ example.com、DC =例では、DC = comのCN = John Smithが、OU =販売、O = ACMEリミテッドは、Lは=モアブは、ST =ユタ州では、Cは、米国を=しません
An alias, or alias name, is "an name for an object, provided by the use of alias entries" [X.501]. Alias entries are described in Section 2.6.
別名、またはエイリアス名は、[X.501]「エイリアスエントリの使用によって提供されるオブジェクトの名前」です。別名エントリは、セクション2.6で説明されています。
An object class is "an identified family of objects (or conceivable objects) that share certain characteristics" [X.501].
オブジェクトクラスは、[X.501]「特定の特性を共有するオブジェクト（またはオブジェクト考えられる）の同定ファミリー」です。
As defined in [X.501]:
[X.501]で定義されます。
Object classes are used in the Directory for a number of purposes:
オブジェクトクラスは、いくつかの目的のためのディレクトリで使用されています。
- describing and categorizing objects and the entries that correspond to these objects;
- 記述とオブジェクトとこれらのオブジェクトに対応するエントリを分類します。
- where appropriate, controlling the operation of the Directory;
- 適切な場合、ディレクトリの動作を制御します。
- regulating, in conjunction with DIT structure rule specifications, the position of entries in the DIT;
- 規制、DIT構造ルール仕様、DIT内のエントリの位置に連動して、
- regulating, in conjunction with DIT content rule specifications, the attributes that are contained in entries;
- 規制、DITコンテンツルール仕様、エントリに含まれる属性と併せて、
- identifying classes of entry that are to be associated with a particular policy by the appropriate administrative authority.
- 適切な行政機関によって特定のポリシーに関連付けされるエントリのクラスを識別する。
An object class (a subclass) may be derived from an object class (its direct superclass) which is itself derived from an even more generic object class. For structural object classes, this process stops at the most generic object class, 'top' (defined in Section 2.4.1). An ordered set of superclasses up to the most superior object class of an object class is its superclass chain.
オブジェクトクラス（サブクラス）にもより一般的なオブジェクトクラスから派生自体であるオブジェクト・クラス（その直接スーパークラス）に由来してもよいです。構造的なオブジェクトクラスの場合、このプロセスは、最も一般的なオブジェクトのクラス（2.4.1項で定義される）、「上部」で停止します。オブジェクトクラスの中で最も優れたオブジェクトクラスまでのスーパークラスの順序集合は、そのスーパーチェーンです。
An object class may be derived from two or more direct superclasses (superclasses not part of the same superclass chain). This feature of subclassing is termed multiple inheritance.
オブジェクト・クラスは、二つ以上の直接的スーパークラス（スーパー同じスーパーチェーンの一部ではない）に由来してもよいです。サブクラスのこの機能は、複数の継承と呼ばれています。
Each object class identifies the set of attributes required to be present in entries belonging to the class and the set of attributes allowed to be present in entries belonging to the class. As an entry of a class must meet the requirements of each class it belongs to, it can be said that an object class inherits the sets of allowed and required attributes from its superclasses. A subclass can identify an attribute allowed by its superclass as being required. If an attribute is a member of both sets, it is required to be present.
各オブジェクトクラスは、クラスとクラスに属するエントリに存在することが許可された属性のセットに属するエントリに存在することが必要な属性のセットを識別する。クラスのエントリとして、それが属する各クラスの要件を満たす必要があり、オブジェクトクラスがそのスーパークラスから許可され、必要な属性のセットを継承するということができます。サブクラスは必要にしていると、そのスーパークラスで許可された属性を識別することができます。属性は、両方のセットのメンバである場合、存在することが必要です。
Each object class is defined to be one of three kinds of object classes: Abstract, Structural, or Auxiliary.
抽象的、構造的、または補助：各オブジェクトクラスは、オブジェクトクラスの三種類のいずれかであると定義されます。
Each object class is identified by an object identifier (OID) and, optionally, one or more short names (descriptors).
各オブジェクトクラスは、オブジェクト識別子（OID）と、必要に応じて、一つ以上の短い名前（記述子）によって識別されます。
An abstract object class, as the name implies, provides a base of characteristics from which other object classes can be defined to inherit from. An entry cannot belong to an abstract object class unless it belongs to a structural or auxiliary class that inherits from that abstract class.
名前が示すように、抽象オブジェクト・クラスは、他のオブジェクト・クラスが継承するように定義することが可能な特性の基礎を提供します。それは抽象クラスを継承する構造または補助クラスに属していない限り、エントリーは、抽象オブジェクトクラスに属することはできません。
Abstract object classes cannot derive from structural or auxiliary object classes.
抽象オブジェクトクラスは、構造的または補助オブジェクトクラスから派生することはできません。
All structural object classes derive (directly or indirectly) from the 'top' abstract object class. Auxiliary object classes do not necessarily derive from 'top'.
すべての構造型オブジェクト・クラスは、「上部」、抽象オブジェクトクラスから（直接または間接的に）引き出します。補助オブジェクトクラスは、必ずしも「上」から派生しません。
The following is the object class definition (see Section 4.1.1) for the 'top' object class:
以下は、「上」オブジェクトクラスのオブジェクトクラス定義（4.1.1項を参照）です。
( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
（2.5.6.0 NAME '上部' ABSTRACT MUSTオブジェクトクラス）
All entries belong to the 'top' abstract object class.
すべてのエントリは、「上」、抽象オブジェクトクラスに属します。
As stated in [X.501]:
[X.501]で述べたように：
An object class defined for use in the structural specification of the DIT is termed a structural object class. Structural object classes are used in the definition of the structure of the names of the objects for compliant entries.
DITの構造仕様で使用するために定義されたオブジェクト・クラスは、構造化オブジェクト・クラスと呼ばれます。構造的なオブジェクトのクラスは、対応のエントリのオブジェクトの名前の構造体の定義に使用されています。
An object or alias entry is characterized by precisely one structural object class superclass chain which has a single structural object class as the most subordinate object class. This structural object class is referred to as the structural object class of the entry.
オブジェクトまたはエイリアスエントリは、最も下位のオブジェクト・クラスのような単一の構造化オブジェクト・クラスを有する正確に1つの構造化オブジェクト・クラススーパー鎖によって特徴付けられます。この構造化オブジェクト・クラスは、エントリの構造化オブジェクト・クラスと呼ばれています。
Structural object classes are related to associated entries:
構造的なオブジェクトのクラスは、関連するエントリに関連しています。
- an entry conforming to a structural object class shall represent the real-world object constrained by the object class;
- 構造化オブジェクトクラスに準拠したエントリは、オブジェクトクラスによって制約実世界のオブジェクトを表すものとします。
- DIT structure rules only refer to structural object classes;
the structural object class of an entry is used to specify the
position of the entry in the DIT;
- the structural object class of an entry is used, along with an associated DIT content rule, to control the content of an entry.
- エントリの構造化オブジェクト・クラスは、エントリの内容を制御するために、関連するDITコンテンツルールと一緒に、使用されます。
The structural object class of an entry shall not be changed.
エントリの構造的なオブジェクトクラスを変更してはなりません。
Each structural object class is a (direct or indirect) subclass of the 'top' abstract object class.
各構造化オブジェクトクラスは、「上部」、抽象オブジェクトクラスの（直接または間接的な）サブクラスです。
Structural object classes cannot subclass auxiliary object classes.
構造オブジェクトクラスは、補助オブジェクトクラスをサブクラス化することはできません。
Each entry is said to belong to its structural object class as well as all classes in its structural object class's superclass chain.
各エントリは、その構造的なオブジェクトクラスだけでなく、その構造オブジェクトクラスのスーパーチェーン内のすべてのクラスに属していると言われています。
Auxiliary object classes are used to augment the characteristics of entries. They are commonly used to augment the sets of attributes required and allowed to be present in an entry. They can be used to describe entries or classes of entries.
補助オブジェクトクラスは、エントリの特性を強化するために使用されています。これらは一般的に必要とエントリに存在することが許可された属性のセットを強化するために使用されています。彼らは、エントリのエントリまたはクラスを記述するために使用することができます。
Auxiliary object classes cannot subclass structural object classes.
補助オブジェクトクラスは、構造オブジェクトクラスをサブクラス化することはできません。
An entry can belong to any subset of the set of auxiliary object classes allowed by the DIT content rule associated with the structural object class of the entry. If no DIT content rule is associated with the structural object class of the entry, the entry cannot belong to any auxiliary object class.
エントリは、エントリの構造化オブジェクト・クラスに関連付けられたDITコンテンツルールによって許可される補助オブジェクトクラスの組の任意のサブセットに属することができます。何DITコンテンツルールはエントリの構造化オブジェクト・クラスに関連付けられていない場合、エントリは、任意の補助オブジェクト・クラスに属することはできません。
The set of auxiliary object classes that an entry belongs to can change over time.
エントリは時間の経過とともに変化することができ属する補助オブジェクトクラスのセット。
An attribute description is composed of an attribute type (see Section 2.5.1) and a set of zero or more attribute options (see Section 2.5.2).
属性記述は、属性タイプ（セクション2.5.1参照）、ゼロ以上の属性オプションのセットから構成されている（セクション2.5.2を参照）。
An attribute description is represented by the ABNF:
属性記述は、ABNFで表されます。
attributedescription = attributetype options attributetype = oid options = *( SEMI option ) option = 1*keychar
AttributeDescription =とattributeTypeオプションは= OIDオプション= *（SEMIオプション）オプション= 1 *は、keyCharをAttributeTypeで
where <attributetype> identifies the attribute type and each <option> identifies an attribute option. Both <attributetype> and <option> productions are case insensitive. The order in which <option>s appear is irrelevant. That is, any two <attributedescription>s that consist of the same <attributetype> and same set of <option>s are equivalent.
ここで、<とattributeType>は、属性タイプを識別し、それぞれの<option>は、属性オプションを識別します。どちらの<とattributeType>と<オプション>プロダクションは大文字小文字を区別しません。 <オプション> sが表示される順番は関係ありません。すなわち、<オプション> Sの同じ<とattributeType>と同じセットから成る任意の2つの<のAttributeDescription> sは等価です。
Examples of valid attribute descriptions:
有効な属性記述の例：
2.5.4.0 cn;lang-de;lang-en owner
2.5.4.0 CN;ラングド;および長期オーナー
An attribute description with an unrecognized attribute type is to be treated as unrecognized. Servers SHALL treat an attribute description with an unrecognized attribute option as unrecognized. Clients MAY treat an unrecognized attribute option as a tagging option (see Section 2.5.2.1).
認識されていない属性タイプの属性の記述は認識されないものとして扱われるべきです。サーバーは認識されていないとして認識されていない属性オプションで属性記述を扱うものとします。クライアントは、タギングオプション（セクション2.5.2.1を参照）として認識されていない属性オプションを扱うかもしれ。
All attributes of an entry must have distinct attribute descriptions.
エントリのすべての属性が明確な属性の説明を持っている必要があります。
An attribute type governs whether the attribute can have multiple values, the syntax and matching rules used to construct and compare values of that attribute, and other functions.
属性タイプは、属性が複数の値、構文およびその属性の値を構築し、比較するために使用されるマッチングルール、および他の機能を有することができるかどうかを支配します。
If no equality matching is specified for the attribute type:
何の平等マッチングは、属性タイプに指定されていない場合：
- the attribute (of the type) cannot be used for naming;
- when adding the attribute (or replacing all values), no two
values may be equivalent (see 2.2);
- individual values of a multi-valued attribute are not to be
independently added or deleted;
- attribute value assertions (such as matching in search filters
and comparisons) using values of such a type cannot be
performed.
Otherwise, the specified equality matching rule is to be used to evaluate attribute value assertions concerning the attribute type. The specified equality rule is to be transitive and commutative.
それ以外の場合は、指定された平等マッチングルールは属性の種類に関する属性値のアサーションを評価するために使用されます。指定された平等ルールは推移と可換になることです。
The attribute type indicates whether the attribute is a user attribute or an operational attribute. If operational, the attribute type indicates the operational usage and whether or not the attribute is modifiable by users. Operational attributes are discussed in Section 3.4.
属性タイプは、属性は、ユーザーの属性やオペレーショナル属性であるかどうかを示します。運用した場合、属性タイプは、動作の使用状況を示し、属性がユーザーによって変更可能であるか否かを判断します。操作属性は、3.4節で議論されています。
An attribute type (a subtype) may derive from a more generic attribute type (a direct supertype). The following restrictions apply to subtyping:
属性型（サブタイプ）は、より一般的な属性タイプ（直接のスーパータイプ）に由来し得ます。以下の制限がサブタイプに適用されます。
- a subtype must have the same usage as its direct supertype, - a subtype's syntax must be the same, or a refinement of, its supertype's syntax, and - a subtype must be collective [RFC3671] if its supertype is collective.
- サブタイプの構文は同じでなければならない、またはそのスーパータイプの構文の改善、および - - サブタイプは、その直接のスーパータイプと同じ用法を持っている必要がありますサブタイプは、集合[RFC3671]にする必要があり、そのスーパータイプが集団である場合。
An attribute description consisting of a subtype and no options is said to be the direct description subtype of the attribute description consisting of the subtype's direct supertype and no options.
サブタイプおよびオプションなしからなる属性記述は、サブタイプの直接のスーパータイプとオプションなしからなる属性記述の直接の説明サブタイプであると言われています。
Each attribute type is identified by an object identifier (OID) and, optionally, one or more short names (descriptors).
各属性タイプは、オブジェクト識別子（OID）と、必要に応じて、一つ以上の短い名前（記述子）によって識別されます。
There are multiple kinds of attribute description options. The LDAP technical specification details one kind: tagging options.
属性記述オプションの複数の種類があります。 LDAP技術仕様の詳細一種：オプションをタグ付け。
Not all options can be associated with attributes held in the directory. Tagging options can be.
すべてのオプションは、ディレクトリで開催された属性に関連付けることができません。タグ付けのオプションがすることができます。
Not all options can be used in conjunction with all attribute types. In such cases, the attribute description is to be treated as unrecognized.
いないすべてのオプションは、すべての属性タイプと組み合わせて使用することができます。このような場合には、属性記述は認識されないものとして扱われるべきです。
An attribute description that contains mutually exclusive options shall be treated as unrecognized. That is, "cn;x-bar;x-foo", where "x-foo" and "x-bar" are mutually exclusive, is to be treated as unrecognized.
相互に排他的なオプションが含まれている属性記述は認識されていないものとして扱われなければなりません。すなわち、 "CN; Xバー; X-FOO" であり、 "X-foo" と "Xバー" は相互に排他的である場合、認識されていないものとして扱われるべきです。
Other kinds of options may be specified in future documents. These documents must detail how new kinds of options they define relate to tagging options. In particular, these documents must detail whether or not new kinds of options can be associated with attributes held in the directory, how new kinds of options affect transfer of attribute values, and how new kinds of options are treated in attribute description hierarchies.
オプションの他の種類は、将来の文書で指定することができます。これらの文書は、彼らが定義するオプションの新しい種類のタグ付けオプションに詳細を関連付ける必要がありますか。具体的には、これらの文書は、オプションの詳細かどうかの新しい種類は、オプションの新しい種類の属性値の転送、およびどのように新しいオプションの種類の属性記述階層に扱われるにどのような影響を与えるか、ディレクトリで開催された属性に関連付けることができなければなりません。
Options are represented as short, case-insensitive textual strings conforming to the <option> production defined in Section 2.5 of this document.
オプションは、このドキュメントのセクション2.5で定義された<option>の生産に準拠した、短い、大文字と小文字を区別しないテキスト文字列として表現されています。
Procedures for registering options are detailed in BCP 64, RFC 4520 [RFC4520].
オプションを登録するための手順は、BCP 64、RFC 4520 [RFC4520]に詳述されています。
Attributes held in the directory can have attribute descriptions with any number of tagging options. Tagging options are never mutually exclusive.
ディレクトリで開催された属性は、タグ付けオプションの任意の数の属性の説明を持つことができます。タグ付けのオプションは相互に排他的なことはありません。
An attribute description with N tagging options is a direct (description) subtype of all attribute descriptions of the same attribute type and all but one of the N options. If the attribute type has a supertype, then the attribute description is also a direct (description) subtype of the attribute description of the supertype and the N tagging options. That is, 'cn;lang-de;lang-en' is a direct (description) subtype of 'cn;lang-de', 'cn;lang-en', and 'name;lang-de;lang-en' ('cn' is a subtype of 'name'; both are defined in [RFC4519]).
Nタギングオプションと属性記述は、同じ属性の型とNの中の選択肢の一つが、すべてのすべての属性の説明の直接（説明）のサブタイプです。属性タイプがスーパータイプを持っている場合、属性の記述は、スーパータイプの属性の記述およびNタグ付けオプションの直接（説明）のサブタイプです。すなわち、「;ラングド; CN langはエン」での直接（説明）のサブタイプである「CN、ラングド」、「CN; langのエン」、および「名前、ラングド; langのアン」 （「CN」は「名前」のサブタイプである;両方とも[RFC4519]で定義されています）。
An attribute description can be the direct subtype of zero or more other attribute descriptions as indicated by attribute type subtyping (as described in Section 2.5.1) or attribute tagging option subtyping (as described in Section 2.5.2.1). These subtyping relationships are used to form hierarchies of attribute descriptions and attributes.
属性タイプのサブタイプ（セクション2.5.1に記載のように）または属性タグ付けオプションのサブタイプ（セクション2.5.2.1に記載されるように）によって示されるように属性記述は、ゼロまたはそれ以上の他の属性の説明の直接のサブタイプであることができます。これらのサブタイプの関係は、属性の説明と属性の階層を形成するために使用されています。
As adapted from [X.501]:
[X.501]から適合されるように
Attribute hierarchies allow access to the DIB with varying degrees of granularity. This is achieved by allowing the value components of attributes to be accessed by using either their specific attribute description (a direct reference to the attribute) or a more generic attribute description (an indirect reference).
属性階層は、粒度の様々な程度でDIBへのアクセスを許可します。これは、属性の値の構成要素が、それらの特定の属性の記述（属性を直接参照）、またはより一般的な属性記述（間接参照）のいずれかを使用してアクセスできるようにすることによって達成されます。
Semantically related attributes may be placed in a hierarchical relationship, the more specialized being placed subordinate to the more generalized. Searching for or retrieving attributes and their values is made easier by quoting the more generalized attribute description; a filter item so specified is evaluated for the more specialized descriptions as well as for the quoted description.
意味的に関連する属性は、より特殊化がより一般的に従属配置され、階層的な関係に置かれてもよいです。検索や属性を取得し、その値は、より一般的な属性記述を引用することによって容易に行われます。その指定されたフィルタ項目は、より専門的な説明については、同様に引用された説明のために評価されます。
Where subordinate specialized descriptions are selected to be returned as part of a search result these descriptions shall be returned if available. Where the more general descriptions are selected to be returned as part of a search result both the general and the specialized descriptions shall be returned, if available. An attribute value shall always be returned as a value of its own attribute description.
どこ下位専門的な説明が可能な場合には、これらの記述が返されなければならない検索結果の一部として返されるように選択されます。どこより一般的な記述は、一般的な、利用可能な場合は専門的な説明は、返却されなければならない両方の検索結果の一部として返されるように選択されます。属性値は、常に独自の属性記述の値として返されなければなりません。
All of the attribute descriptions in an attribute hierarchy are treated as distinct and unrelated descriptions for user modification of entry content.
属性階層における属性記述のすべては、エントリのコンテンツのユーザー変更のための明確なと無関係な記述として扱われます。
An attribute value stored in an object or alias entry is of precisely one attribute description. The description is indicated when the value is originally added to the entry.
オブジェクトまたはエイリアスエントリに格納された属性値は、正確に1つの属性の記述です。値が最初のエントリに追加されたときに説明が示されています。
For the purpose of subschema administration of the entry, a specification that an attribute is required is fulfilled if the entry contains a value of an attribute description belonging to an attribute hierarchy where the attribute type of that description is the same as the required attribute's type. That is, a "MUST name" specification is fulfilled by 'name' or 'name;x-tag-option', but is not fulfilled by 'CN' or 'CN;x-tag-option' (even though 'CN' is a subtype of 'name'). Likewise, an entry may contain a value of an attribute description belonging to an attribute hierarchy where the attribute type of that description is either explicitly included in the definition of an object class to which the entry belongs or allowed by the DIT content rule applicable to that entry. That is, 'name' and 'name;x-tag-option' are allowed by "MAY name" (or by "MUST name"), but 'CN' and 'CN;x-tag-option' are not allowed by "MAY name" (or by "MUST name").
エントリはその記述の属性タイプは、必要な属性の型と同じである属性階層に属する属性記述の値が含まれている場合は、エントリのサブスキーマ投与の目的のために、属性が必要とされる仕様が満たされています。でも、「CN」けれども（;が、「CN」かによって満たされていない「X-タグオプションCN」;それは、「名前を付けなければなりません。」の仕様を「名前」や「X-タグオプション名」で満たされています「名前」）のサブタイプがあります。同様に、エントリは、その記述の属性タイプを明示的エントリが属するオブジェクトクラスの定義に含まれるか、またはそれに適用可能なDITコンテンツルールによって許可された属性の階層に属する属性記述の値を含んでいてもよいですエントリ。つまり、「名前」と「名前; X-タグオプションは」「という名前MAY」によって（または「名前を付けなければなりません。」によって）許可されているが、「CN」と「CN; X-タグオプションは」で許可されていません「名前を付けてもよい（MAY）」（または「名前を付けなければなりません。」によります）。
For the purposes of other policy administration, unless stated otherwise in the specification of the particular administrative model, all of the attribute descriptions in an attribute hierarchy are treated as distinct and unrelated descriptions.
特定の管理モデルの明細書に別段の記載がない限り他のポリシー管理の目的のために、属性階層の属性の説明の全てがはっきりと無関係説明として扱われます。
As adapted from [X.501]:
[X.501]から適合されるように
An alias, or an alias name, for an object is an alternative name for an object or object entry which is provided by the use of alias entries.
オブジェクトのエイリアス、またはエイリアス名は、エイリアスエントリの使用によって提供されるオブジェクトまたはオブジェクトのエントリの別名です。
Each alias entry contains, within the 'aliasedObjectName' attribute (known as the 'aliasedEntryName' attribute in X.500), a name of some object. The distinguished name of the alias entry is thus also a name for this object.
各別名エントリは、（X.500の「aliasedEntryName」属性として知られている）「aliasedObjectName」属性の中に、いくつかのオブジェクトの名前が含まれています。別名エントリの識別名は、このようにも、このオブジェクトの名前です。
NOTE - The name within the 'aliasedObjectName' is said to be
pointed to by the alias. It does not have to be the
distinguished name of any entry.
The conversion of an alias name to an object name is termed (alias) dereferencing and comprises the systematic replacement of alias names, where found within a purported name, by the value of the corresponding 'aliasedObjectName' attribute. The process may require the examination of more than one alias entry.
オブジェクト名にエイリアス名の変換は、間接参照（エイリアス）と呼ばれ、対応する「aliasedObjectName」属性の値によって、主張名内で見出さ別名、の系統的置換を含みます。このプロセスは、複数の別名エントリの検査が必要な場合があります。
Any particular entry in the DIT may have zero or more alias names. It therefore follows that several alias entries may point to the same entry. An alias entry may point to an entry that is not a leaf entry and may point to another alias entry.
DIT内の任意の特定のエントリは、ゼロ以上の別名を持つことができます。したがって、いくつかの別名項目が同じエントリを指す場合もあるということで。別名エントリは、リーフ・エントリではなく、別の別名エントリを指すことがエントリを指してもよいです。
An alias entry shall have no subordinates, so that an alias entry is always a leaf entry.
別名エントリは、常にリーフエントリであるように、別名エントリは、何の部下を負わないものとします。
Every alias entry shall belong to the 'alias' object class.
すべての別名エントリは、「別名」オブジェクトのクラスに属するものとします。
An entry with the 'alias' object class must also belong to an object class (or classes), or be governed by a DIT content rule, which allows suitable naming attributes to be present.
「エイリアス」オブジェクトクラスを持つエントリは、オブジェクトクラス（またはクラス）に属していなければならない、または適切な命名が存在することができます属性DITコンテンツ規則によって支配さ。
Example:
例：
dn: cn=bar,dc=example,dc=com objectClass: top objectClass: alias objectClass: extensibleObject cn: bar aliasedObjectName: cn=foo,dc=example,dc=com
DN：CN =バー、dc = example、dc = comのオブジェクトクラス：トップオブジェクトクラス：別名オブジェクトクラス：extensibleObjectというCN：バーaliasedObjectName：CNは= FOO、dc = example、dc = comの
Alias entries belong to the 'alias' object class.
別名エントリは、「別名」オブジェクトのクラスに属しています。
( 2.5.6.1 NAME 'alias' SUP top STRUCTURAL MUST aliasedObjectName )
（2.5.6.1 NAME '別名' SUPトップSTRUCTURAL MUST aliasedObjectName）
The 'aliasedObjectName' attribute holds the name of the entry an alias points to. The 'aliasedObjectName' attribute is known as the 'aliasedEntryName' attribute in X.500.
「aliasedObjectName」属性は、別名ポイントへのエントリの名前を保持します。 「aliasedObjectName」属性は、X.500の「aliasedEntryName」属性として知られています。
( 2.5.4.1 NAME 'aliasedObjectName' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )
（2.5.4.1 NAME 'aliasedObjectName' 平等distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12単一値）
The 'distinguishedNameMatch' matching rule and the DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
「distinguishedNameMatch」マッチング規則及び識別名（1.3.6.1.4.1.1466.115.121.1.12）構文は[RFC4517]で定義されています。
This section discusses select aspects of the X.500 Directory Administrative and Operational Information model [X.501]. LDAP implementations MAY support other aspects of this model.
このセクションでは、X.500 Directory管理と運用情報モデル[X.501]の選択の側面を説明します。 LDAPの実装では、このモデルの他の側面をサポートするかもしれません。
As defined in [X.501]:
[X.501]で定義されます。
A subtree is a collection of object and alias entries situated at the vertices of a tree. Subtrees do not contain subentries. The prefix sub, in subtree, emphasizes that the base (or root) vertex of this tree is usually subordinate to the root of the DIT.
サブツリーはツリーの頂点に位置するオブジェクトと別名エントリのコレクションです。サブツリーは、サブエントリが含まれていません。プレフィックスサブ、サブツリーに、このツリーのベース（またはルート）頂点がDITのルートに通常配下であることを強調しています。
A subtree begins at some vertex and extends to some identifiable lower boundary, possibly extending to leaves. A subtree is always defined within a context which implicitly bounds the subtree. For example, the vertex and lower boundaries of a subtree defining a replicated area are bounded by a naming context.
サブツリーは、いくつかの頂点で始まり、おそらく葉に延びる、いくつかの識別可能な下限まで延びています。サブツリーは、常に暗黙的にサブツリーを境界コンテキスト内で定義されています。例えば、レプリケート領域を画定するサブツリーの頂点及び下部境界はネーミング・コンテキストによって囲まれています。
A subentry is a "special sort of entry, known by the Directory, used to hold information associated with a subtree or subtree refinement" [X.501]. Subentries are used in Directory to hold for administrative and operational purposes as defined in [X.501]. Their use in LDAP is detailed in [RFC3672].
サブエントリは[X.501]「サブツリーまたはサブツリー改善に関連する情報を保持するために使用されるディレクトリで知られているエントリの特殊なソート、」です。サブエントリは[X.501]で定義されている管理および動作の目的のために保持するためにDirectoryで使用されています。 LDAPでの使用は[RFC3672]に詳述されています。
The term "(sub)entry" in this specification indicates that servers implementing X.500(93) models are, in accordance with X.500(93) as described in [RFC3672], to use a subentry and that other servers are to use an object entry belonging to the appropriate auxiliary class normally used with the subentry (e.g., 'subschema' for subschema subentries) to mimic the subentry. This object entry's RDN SHALL be formed from a value of the 'cn' (commonName) attribute [RFC4519] (as all subentries are named with 'cn').
用語本明細書において「（サブ）エントリは、」[RFC3672]に記載されているようにX.500（93）を実装するサーバモデルがサブエントリを使用するように、X.500（93）に応じて、であり、他のサーバがにあることを示し通常サブエントリとともに使用さ適切な補助クラスに属するオブジェクトのエントリを使用する（例えば、サブスキーマサブエントリ用の「サブスキーマ」）はサブエントリを模倣します。このオブジェクトエントリのRDNは、（すべてのサブエントリが「CN」と命名されたように）「CN」（commonNameの）属性[RFC4519]の値から形成されるものとします。
Each entry in the DIT has an 'objectClass' attribute.
DITの各エントリには、「オブジェクトクラス」属性を持っています。
( 2.5.4.0 NAME 'objectClass' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
（2.5.4.0 NAME 'オブジェクトクラス' 平等objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38）
The 'objectIdentifierMatch' matching rule and the OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax are defined in [RFC4517].
「objectIdentifierMatch」マッチングルールとオブジェクト識別子（1.3.6.1.4.1.1466.115.121.1.38）構文は[RFC4517]で定義されています。
The 'objectClass' attribute specifies the object classes of an entry, which (among other things) are used in conjunction with the controlling schema to determine the permitted attributes of an entry. Values of this attribute can be modified by clients, but the 'objectClass' attribute cannot be removed.
「オブジェクトクラス」属性は、エントリの許可属性を決定するために、制御スキーマと共に使用される（とりわけ）エントリのオブジェクトクラスを指定します。この属性の値は、クライアントによって変更することができますが、「オブジェクトクラス」属性を削除することはできません。
Servers that follow X.500(93) models SHALL restrict modifications of this attribute to prevent the basic structural class of the entry from being changed. That is, one cannot change a 'person' into a 'country'.
X.500に従うサーバ（93）モデルが変更されたエントリの基本的な構造クラスを防ぐために、この属性の変更を制限しなければなりません。つまり、一つは「国への「人」を変更することはできません。
When creating an entry or adding an 'objectClass' value to an entry, all superclasses of the named classes SHALL be implicitly added as well if not already present. That is, if the auxiliary class 'x-a' is a subclass of the class 'x-b', adding 'x-a' to 'objectClass' causes 'x-b' to be implicitly added (if is not already present).
エントリを作成したり、エントリに「オブジェクトクラス」の値を追加する場合は、名前のクラスのすべてのスーパークラスは暗黙のうちにも存在していない場合は追加されないものとします。補助クラスが「とx-」場合には、（既に存在しない場合）暗黙的に追加される「オブジェクトクラス」原因「X-B」に「X-A」を追加して、「-BをX」クラスのサブクラスです。
Servers SHALL restrict modifications of this attribute to prevent superclasses of remaining 'objectClass' values from being deleted. That is, if the auxiliary class 'x-a' is a subclass of the auxiliary class 'x-b' and the 'objectClass' attribute contains 'x-a' and 'x-b', an attempt to delete only 'x-b' from the 'objectClass' attribute is an error.
サーバーが削除され、残りの「オブジェクトクラス」の値のスーパーを防ぐために、この属性の変更を制限しなければなりません。補助クラス「XA」は補助クラスのXB "のサブクラスであると「のobjectClass」属性は、「XA」と「XB」「オブジェクトクラス」からのみ「XB」を削除しようとする試みが含まれている場合、つまり、属性は誤りです。
Some attributes, termed operational attributes, are used or maintained by servers for administrative and operational purposes. As stated in [X.501]: "There are three varieties of operational attributes: Directory operational attributes, DSA-shared operational attributes, and DSA-specific operational attributes".
一部の属性は、と呼ばれる操作属性は、使用または管理や運用の目的のために、サーバによって維持されています。 [X.501]で述べたように：「：ディレクトリ操作属性、DSA-共有操作属性、およびDSA固有の操作属性操作属性の3種類があります」。
A directory operational attribute is used to represent operational and/or administrative information in the Directory Information Model. This includes operational attributes maintained by the server (e.g., 'createTimestamp') as well as operational attributes that hold values administrated by the user (e.g., 'ditContentRules').
ディレクトリ操作属性は、ディレクトリ情報モデルでの運用および/または管理情報を表すために使用されます。これは、ユーザ（例えば、「ditContentRules」）で投与した値を保持するサーバ（例えば、「createTimestamp」）によって維持操作属性と同様の操作属性を含みます。
A DSA-shared operational attribute is used to represent information of the DSA Information Model that is shared between DSAs.
DSA-共有操作属性はDSAsの間で共有されるDSA情報モデルの情報を表すために使用されます。
A DSA-specific operational attribute is used to represent information of the DSA Information Model that is specific to the DSA (though, in some cases, may be derived from information shared between DSAs; e.g., 'namingContexts').
DSA固有のオペレーショナル属性はDSAに特異的であるDSA情報モデルの情報を表すために使用されている（ただし、いくつかのケースでは、のDSA間で共有される情報から導出することができるが、例えば、「のnamingContexts」）。
The DSA Information Model operational attributes are detailed in [X.501].
DSA情報モデル操作属性は、[X.501]に詳述されています。
Operational attributes are not normally visible. They are not returned in search results unless explicitly requested by name.
操作属性は、通常は表示されません。明示的に名前によって要求されない限り、彼らは検索結果に返されません。
Not all operational attributes are user modifiable.
いないすべての操作属性は、ユーザー変更可能です。
Entries may contain, among others, the following operational attributes:
エントリは、とりわけ、以下の操作属性が含まれる場合があります。
- creatorsName: the Distinguished Name of the user who added this entry to the directory,
- creatorsName：ディレクトリにこのエントリを追加したユーザの識別名、
- createTimestamp: the time this entry was added to the directory,
- createTimestamp：このエントリがディレクトリに追加された時、
- modifiersName: the Distinguished Name of the user who last modified this entry, and
- にmodifiersName：最後にこのエントリを変更したユーザーの識別名、および
- modifyTimestamp: the time this entry was last modified.
- modifyTimestampの：このエントリが最後に変更された時刻。
Servers SHOULD maintain the 'creatorsName', 'createTimestamp', 'modifiersName', and 'modifyTimestamp' attributes for all entries of the DIT.
サーバは「creatorsName」DITのすべてのエントリについて、「createTimestamp」、「にmodifiersName」、および「modifyTimestampの」属性を維持する必要があります。
This attribute appears in entries that were added using the protocol (e.g., using the Add operation). The value is the distinguished name of the creator.
この属性は、（例えば、追加操作を使用して）プロトコルを使用して追加されたエントリに表示されます。値は、作成者の識別名です。
( 2.5.18.3 NAME 'creatorsName' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
（2.5.18.3 NAME 'creatorsName' 平等distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation）
The 'distinguishedNameMatch' matching rule and the DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
「distinguishedNameMatch」マッチング規則及び識別名（1.3.6.1.4.1.1466.115.121.1.12）構文は[RFC4517]で定義されています。
This attribute appears in entries that were added using the protocol (e.g., using the Add operation). The value is the time the entry was added.
この属性は、（例えば、追加操作を使用して）プロトコルを使用して追加されたエントリに表示されます。値は、エントリが追加された時間です。
( 2.5.18.1 NAME 'createTimestamp' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
（2.5.18.1 NAME 'createTimestamp' 平等generalizedTimeMatchはgeneralizedTimeOrderingMatch SYNTAXオーダー1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation）
The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax are defined in [RFC4517].
「generalizedTimeMatch」と「generalizedTimeOrderingMatch」マッチングルールとGeneralizedTimeの（1.3.6.1.4.1.1466.115.121.1.24）構文は[RFC4517]で定義されています。
This attribute appears in entries that have been modified using the protocol (e.g., using the Modify operation). The value is the distinguished name of the last modifier.
この属性は、（例えば、変更操作を使用して）プロトコルを使用して修正されたエントリに表示されます。値は、最後の修飾の識別名です。
( 2.5.18.4 NAME 'modifiersName' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
（2.5.18.4 NAME 'にmodifiersName' 平等distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation）
The 'distinguishedNameMatch' matching rule and the DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
「distinguishedNameMatch」マッチング規則及び識別名（1.3.6.1.4.1.1466.115.121.1.12）構文は[RFC4517]で定義されています。
This attribute appears in entries that have been modified using the protocol (e.g., using the Modify operation). The value is the time the entry was last modified.
この属性は、（例えば、変更操作を使用して）プロトコルを使用して修正されたエントリに表示されます。値は、エントリが最後に変更された時刻です。
( 2.5.18.2 NAME 'modifyTimestamp' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
（2.5.18.2 NAME 'modifyTimestampの' 平等generalizedTimeMatchはgeneralizedTimeOrderingMatch SYNTAXオーダー1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation）
The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax are defined in [RFC4517].
「generalizedTimeMatch」と「generalizedTimeOrderingMatch」マッチングルールとGeneralizedTimeの（1.3.6.1.4.1.1466.115.121.1.24）構文は[RFC4517]で定義されています。
This attribute indicates the structural object class of the entry.
この属性は、エントリの構造的なオブジェクトクラスを示します。
( 2.5.21.9 NAME 'structuralObjectClass' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
（2.5.21.9 NAME 'structuralObjectClass' 平等objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation）
The 'objectIdentifierMatch' matching rule and OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [RFC4517].
「objectIdentifierMatch」マッチングルールとオブジェクト識別子（1.3.6.1.4.1.1466.115.121.1.38）構文は[RFC4517]で定義されています。
This attribute indicates the structure rule governing the entry.
この属性は、エントリを支配する構造ルールを示しています。
( 2.5.21.10 NAME 'governingStructureRule' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
（2.5.21.10 NAME 'governingStructureRule' 平等integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation）
The 'integerMatch' matching rule and INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in [RFC4517].
'integerMatch' マッチングルールとINTEGER（1.3.6.1.4.1.1466.115.121.1.27）構文は[RFC4517]で定義されています。
As defined in [X.501]:
[X.501]で定義されます。
The Directory Schema is a set of definitions and constraints concerning the structure of the DIT, the possible ways entries are named, the information that can be held in an entry, the attributes used to represent that information and their organization into hierarchies to facilitate search and retrieval of the information and the ways in which values of attributes may be matched in attribute value and matching rule assertions.
Directoryスキーマは、DITの構造に関する定義と制約のセット、エントリが命名されている可能性のある方法、エントリに保持することが可能な情報検索を容易にするために、階層にその情報や自分の組織を表すために使用される属性で、情報の検索及び属性値を属性値と一致ルールアサーションに一致することができる、方法。
NOTE 1 - The schema enables the Directory system to, for example:
注1 - スキーマは、たとえば、にDirectoryシステムを可能にします：
- prevent the creation of subordinate entries of the wrong object-class (e.g., a country as a subordinate of a person);
- 間違ったオブジェクト・クラスの下位のエントリが作成されない（例えば、人の部下として、国）;
- prevent the addition of attribute-types to an entry inappropriate to the object-class (e.g., a serial number to a person's entry);
- オブジェクトクラス（例えば、人のエントリにシリアル番号）に不適切なエントリへの属性タイプの追加を防ぎます。
- prevent the addition of an attribute value of a syntax not matching that defined for the attribute-type (e.g., a printable string to a bit string).
- 属性型（例えば、ビット列に印刷可能文字列）に対して定義されていることを一致しない構文の属性値の追加を防ぎます。
Formally, the Directory Schema comprises a set of:
正式には、ディレクトリスキーマは、のセットを含みます。
a) Name Form definitions that define primitive naming relations for structural object classes;
a）の構造化オブジェクトクラスのプリミティブ命名関係を定義する名前のフォームの定義;
b) DIT Structure Rule definitions that define the names that entries may have and the ways in which the entries may be related to one another in the DIT;
エントリが有していてもよい名称とエントリがDITに互いに関連することが可能な方法を定義b）はDIT構造ルール定義。
c) DIT Content Rule definitions that extend the specification of allowable attributes for entries beyond those indicated by the structural object classes of the entries;
エントリの構造型オブジェクト・クラスによって示された値を越えるエントリーの許容属性の仕様を拡張C）DITコンテンツルールの定義。
d) Object Class definitions that define the basic set of mandatory and optional attributes that shall be present, and may be present, respectively, in an entry of a given class, and which indicate the kind of object class that is being defined;
D）が存在しなければならない必須および任意の属性の基本セットを定義し、存在してもよく、それぞれ、所定のクラスのエントリに、及びオブジェクトクラス定義が定義されているオブジェクトクラスの種類を示します。
e) Attribute Type definitions that identify the object identifier by which an attribute is known, its syntax, associated matching rules, whether it is an operational attribute and if so its type, whether it is a collective attribute, whether it is permitted to have multiple values and whether or not it is derived from another attribute type;
E）属性は、複数を有することが許可されているか否か、集合的な属性であるかどうかを、その構文を知らそうであれば、その種類がオペレーショナル属性であるかどうかを、マッチングルールに関連され、それによってオブジェクト識別子を識別するタイプ属性定義値とそれは別の属性の型から派生されているかどうか。
f) Matching Rule definitions that define matching rules.
F）に一致するルールを定義するルール定義をマッチング。
And in LDAP:
そして、LDAPで：
g) LDAP Syntax definitions that define encodings used in LDAP.
g）をLDAPで使用するエンコーディングを定義するLDAPシンタックス定義。
Schema definitions in this section are described using ABNF and rely on the common productions specified in Section 1.2 as well as these:
このセクションのスキーマ定義はABNFを用いて説明し、1.2節と同様に、これらの中で指定された共通の制作に頼っています。
noidlen = numericoid [ LCURLY len RCURLY ] len = number
noidlen = numericoid [RCURLYとしてLCURLY] LEN =数
oids = oid / ( LPAREN WSP oidlist WSP RPAREN ) oidlist = oid *( WSP DOLLAR WSP oid )
OIDS = OID /（LPAREN oidlist WSP WSP RPAREN）oidlist OID = *（WSP WSPドルOID）
extensions = *( SP xstring SP qdstrings ) xstring = "X" HYPHEN 1*( ALPHA / HYPHEN / USCORE )
拡張子= *（SP XSTRING SP qdstrings）XSTRING = "X" ハイフン1 *（ALPHA / HYPHEN / USCORE）
qdescrs = qdescr / ( LPAREN WSP qdescrlist WSP RPAREN ) qdescrlist = [ qdescr *( SP qdescr ) ] qdescr = SQUOTE descr SQUOTE
qdescrs = qdescr /（LPAREN WSP WSP qdescrlist RPAREN）qdescrlist = [qdescr×（SPのqdescr）] = qdescr SQUOTE DESCR SQUOTE
qdstrings = qdstring / ( LPAREN WSP qdstringlist WSP RPAREN ) qdstringlist = [ qdstring *( SP qdstring ) ] qdstring = SQUOTE dstring SQUOTE dstring = 1*( QS / QQ / QUTF8 ) ; escaped UTF-8 string
qdstrings = qdstring /（LPAREN WSP WSP qdstringlist RPAREN）qdstringlist = [qdstring×（SPのqdstring）] = qdstring SQUOTE DSTRING SQUOTE DSTRING = 1 *（QS / QQ / QUTF8）。 UTF-8文字列をエスケープ
QQ = ESC %x32 %x37 ; "\27" QS = ESC %x35 ( %x43 / %x63 ) ; "\5C" / "\5c"
QQ = ESC％X32％X37。 "\ 27" QS = ESCの％のX35（X43％/％のX63）。 "\ 5C" / "\ 5cと"
; Any UTF-8 encoded Unicode character ; except %x27 ("\'") and %x5C ("\") QUTF8 = QUTF1 / UTFMB
;任意のUTF-8は、Unicode文字をエンコードされました。 ％のX27（ "\ ' "）と％x5C（" \"）を除くQUTF8 = QUTF1 / UTFMB
; Any ASCII character except %x27 ("\'") and %x5C ("\") QUTF1 = %x00-26 / %x28-5B / %x5D-7F
; ％のX27（ "\ ' "）と％x5C（" \"）を除く任意のASCII文字QUTF1 =％x00-26 /％x28-5B /％x5D-7F
Schema definitions in this section also share a number of common terms.
このセクションのスキーマ定義も共通項の数を共有しています。
The NAME field provides a set of short names (descriptors) that are to be used as aliases for the OID.
NAMEフィールドは、OIDの別名として使用される短い名前（記述子）のセットを提供します。
The DESC field optionally allows a descriptive string to be provided by the directory administrator and/or implementor. While specifications may suggest a descriptive string, there is no requirement that the suggested (or any) descriptive string be used.
DESCフィールドは、必要に応じて、ディレクトリ管理者及び/又は実装によって提供される説明的な文字列を可能にします。仕様は説明文字列を示唆するかもしれないが、提案（または任意の）説明文字列を使用することを必要はありません。
The OBSOLETE field, if present, indicates the element is not active.
OBSOLETEフィールドは、存在する場合、要素がアクティブでない示します。
Implementors should note that future versions of this document may expand these definitions to include additional terms. Terms whose identifier begins with "X-" are reserved for private experiments and are followed by <SP> and <qdstrings> tokens.
実装者は、このドキュメントの将来のバージョンが追加の項が含まれるように、これらの定義を拡大する可能性があることに注意すべきです。識別子が始まる「X-」との用語は、私的な実験のために予約されており、<SP>と<qdstrings>トークンが続いています。
Object Class definitions are written according to the ABNF:
オブジェクトクラス定義はABNFに従って書かれています。
ObjectClassDescription = LPAREN WSP numericoid ; object identifier [ SP "NAME" SP qdescrs ] ; short names (descriptors) [ SP "DESC" SP qdstring ] ; description [ SP "OBSOLETE" ] ; not active [ SP "SUP" SP oids ] ; superior object classes [ SP kind ] ; kind of class [ SP "MUST" SP oids ] ; attribute types [ SP "MAY" SP oids ] ; attribute types extensions WSP RPAREN
ObjectClassDescription = LPAREN WSP numericoid。オブジェクト識別子[SP "NAME" SP qdescrs]。短い名前（記述子）[SP "DESC" SPのqdstring]。説明[SP「時代遅れ」]。アクティブではない[SP "SUP" のSPのOID]。上位オブジェクト・クラス[SPの種類]。クラスの種類[SP "MUST" のSPのOID];種類[SP "MAY" SPのOIDを]属性。属性タイプの拡張WSP RPAREN
kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"
種類= "ABSTRACT" / "構造" / "補助"
where:
<numericoid> is object identifier assigned to this object class;
NAME <qdescrs> are short names (descriptors) identifying this
object class;
DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this object class is not active;
SUP <oids> specifies the direct superclasses of this object class;
the kind of object class is indicated by one of ABSTRACT,
STRUCTURAL, or AUXILIARY (the default is STRUCTURAL);
MUST and MAY specify the sets of required and allowed attribute
types, respectively; and
<extensions> describe extensions.
Attribute Type definitions are written according to the ABNF:
属性タイプ定義はABNFに従って書かれています。
AttributeTypeDescription = LPAREN WSP numericoid ; object identifier [ SP "NAME" SP qdescrs ] ; short names (descriptors) [ SP "DESC" SP qdstring ] ; description [ SP "OBSOLETE" ] ; not active [ SP "SUP" SP oid ] ; supertype [ SP "EQUALITY" SP oid ] ; equality matching rule [ SP "ORDERING" SP oid ] ; ordering matching rule [ SP "SUBSTR" SP oid ] ; substrings matching rule [ SP "SYNTAX" SP noidlen ] ; value syntax [ SP "SINGLE-VALUE" ] ; single-value [ SP "COLLECTIVE" ] ; collective [ SP "NO-USER-MODIFICATION" ] ; not user modifiable [ SP "USAGE" SP usage ] ; usage extensions WSP RPAREN ; extensions
AttributeTypeDescription = LPAREN WSP numericoid。オブジェクト識別子[SP "NAME" SP qdescrs]。短い名前（記述子）[SP "DESC" SPのqdstring]。説明[SP「時代遅れ」]。アクティブではない[SP "SUP" SPのOID]。スーパータイプ[SP "平等" SPのOID];平等マッチングルール[SP "オーダー" SPのOID];注文マッチングルール[SP "SUBSTR" SPのOID];ルールに一致するサブストリング[SP "SYNTAX" SP noidlen]。値構文[SP "SINGLE-VALUE"]。単一値[SP「集団」]。集合[SP "NO-USER-MODIFICATION"]。ないユーザ変更[SP「USAGE」SPの使用法。使用拡張WSP RPAREN。拡張
usage = "userApplications" / ; user "directoryOperation" / ; directory operational "distributedOperation" / ; DSA-shared operational "dSAOperation" ; DSA-specific operational
用法= "userApplications" /;ユーザー "directoryOperation" /;ディレクトリの操作 "distributedOperation" /; DSA-共有操作「dSAOperation」。 DSA固有の運用
where:
<numericoid> is object identifier assigned to this attribute type;
NAME <qdescrs> are short names (descriptors) identifying this
attribute type;
DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this attribute type is not active;
SUP oid specifies the direct supertype of this type;
EQUALITY, ORDERING, and SUBSTR provide the oid of the equality,
ordering, and substrings matching rules, respectively;
SYNTAX identifies value syntax by object identifier and may suggest
a minimum upper bound;
SINGLE-VALUE indicates attributes of this type are restricted to a
single value;
COLLECTIVE indicates this attribute type is collective
[X.501][RFC3671];
NO-USER-MODIFICATION indicates this attribute type is not user
modifiable;
USAGE indicates the application of this attribute type; and
<extensions> describe extensions.
Each attribute type description must contain at least one of the SUP or SYNTAX fields. If no SYNTAX field is provided, the attribute type description takes its value from the supertype.
各属性タイプの説明は、SUPやSYNTAXフィールドの少なくとも一つが含まれている必要があります。何のSYNTAXフィールドが用意されていない場合は、属性タイプの説明はスーパータイプからその値をとります。
If SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING fields, if not specified, take their value from the supertype.
SUPフィールドが用意されている場合は、平等、オーダー、およびSUBSTRINGフィールドは、指定されていない場合は、スーパータイプからの値をとります。
Usage of userApplications, the default, indicates that attributes of this type represent user information. That is, they are user attributes.
userApplicationsの使用は、デフォルトでは、このタイプの属性は、ユーザ情報を表すことを示しています。つまり、彼らは、ユーザーの属性です。
A usage of directoryOperation, distributedOperation, or dSAOperation indicates that attributes of this type represent operational and/or administrative information. That is, they are operational attributes.
directoryOperation、distributedOperation、又はdSAOperationの使用は、この種の属性は、動作および/または管理情報を表すことを示しています。つまり、彼らは操作属性です。
directoryOperation usage indicates that the attribute of this type is a directory operational attribute. distributedOperation usage indicates that the attribute of this type is a DSA-shared usage operational attribute. dSAOperation usage indicates that the attribute of this type is a DSA-specific operational attribute.
directoryOperationの使用量は、このタイプの属性は、ディレクトリ操作属性であることを示しています。 distributedOperationの使用量は、このタイプの属性はDSA-共有使い方操作属性であることを示しています。 dSAOperationの使用量は、このタイプの属性はDSA固有の操作属性であることを示しています。
COLLECTIVE requires usage userApplications. Use of collective attribute types in LDAP is discussed in [RFC3671].
COLLECTIVEは、使用userApplicationsが必要です。 LDAPでの集団的属性タイプの使用は[RFC3671]で議論されています。
NO-USER-MODIFICATION requires an operational usage.
-USER NO-変更は、業務使用を必要とします。
Note that the <AttributeTypeDescription> does not list the matching rules that can be used with that attribute type in an extensibleMatch search filter [RFC4511]. This is done using the 'matchingRuleUse' attribute described in Section 4.1.4.
なお、<AttributeTypeDescription> extensibleMatch検索フィルタ[RFC4511]でその属性タイプと一緒に使用することができるマッチングルールが表示されません。これは、4.1.4項で説明した「れるmatchingRuleUse」属性を使用して行われます。
This document refines the schema description of X.501 by requiring that the SYNTAX field in an <AttributeTypeDescription> be a string representation of an object identifier for the LDAP string syntax definition, with an optional indication of the suggested minimum bound of a value of this attribute.
この文書では、この値の下限示唆最小の任意指示と、<AttributeTypeDescription> LDAP文字列構文定義のオブジェクト識別子の文字列表現であるの構文フィールドを要求することによって、X.501のスキーマの記述を洗練します属性。
A suggested minimum upper bound on the number of characters in a value with a string-based syntax, or the number of bytes in a value for all other syntaxes, may be indicated by appending this bound count inside of curly braces following the syntax's OBJECT IDENTIFIER in an Attribute Type Description. This bound is not part of the syntax name itself. For instance, "1.3.6.4.1.1466.0{64}" suggests that server implementations should allow a string to be 64 characters long, although they may allow longer strings. Note that a single character of the Directory String syntax may be encoded in more than one octet since UTF-8 [RFC3629] is a variable-length encoding.
提案最小アッパーは、文字列ベースの構文と値の文字数にバインドされ、または他のすべての構文の値のバイト数は、構文のオブジェクト識別子以下の中括弧の内側に、このバインド数を追加することによって示すことができます属性タイプ説明インチこの境界は、構文名自体の一部ではありません。例えば、「1.3.6.4.1.1466.0 {64}」サーバーの実装は、それらがより長い文字列を可能にすることができるが、文字列は、64文字の長さを可能にするべきであることを示唆しています。 UTF-8 [RFC3629]は可変長符号であるので、ディレクトリ文字列構文の単一文字は、複数のオクテットで符号化されてもよいことに留意されたいです。
Matching rules are used in performance of attribute value assertions, such as in performance of a Compare operation. They are also used in evaluating search filters, determining which individual values are to be added or deleted during performance of a Modify operation, and in comparing distinguished names.
マッチングルールは、このような比較演算のパフォーマンスのように属性値アサーションのパフォーマンスで使用されています。彼らはまた、検索フィルタを評価する個々の値が変更操作の実行中に追加または削除するかを決定するにして識別名を比較する際に使用されています。
Each matching rule is identified by an object identifier (OID) and, optionally, one or more short names (descriptors).
各マッチングルールは、オブジェクト識別子（OID）と、必要に応じて、一つ以上の短い名前（記述子）によって識別されます。
Matching rule definitions are written according to the ABNF:
マッチングルールの定義はABNFに従って書かれています。
MatchingRuleDescription = LPAREN WSP numericoid ; object identifier [ SP "NAME" SP qdescrs ] ; short names (descriptors) [ SP "DESC" SP qdstring ] ; description [ SP "OBSOLETE" ] ; not active SP "SYNTAX" SP numericoid ; assertion syntax extensions WSP RPAREN ; extensions
MatchingRuleDescription = LPAREN WSP numericoid。オブジェクト識別子[SP "NAME" SP qdescrs]。短い名前（記述子）[SP "DESC" SPのqdstring]。説明[SP「時代遅れ」]。アクティブでないSP "SYNTAX" SPのnumericoid。アサーション構文拡張WSP RPAREN。拡張
where:
<numericoid> is object identifier assigned to this matching rule;
NAME <qdescrs> are short names (descriptors) identifying this
matching rule;
DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this matching rule is not active;
SYNTAX identifies the assertion syntax (the syntax of the assertion
value) by object identifier; and
<extensions> describe extensions.
A matching rule use lists the attribute types that are suitable for use with an extensibleMatch search filter.
マッチング規則の使用は、extensibleMatch検索フィルタでの使用に適している属性タイプを示しています。
Matching rule use descriptions are written according to the following ABNF:
マッチングルールの使用説明は以下のABNFに従って書かれています。
MatchingRuleUseDescription = LPAREN WSP numericoid ; object identifier [ SP "NAME" SP qdescrs ] ; short names (descriptors) [ SP "DESC" SP qdstring ] ; description [ SP "OBSOLETE" ] ; not active SP "APPLIES" SP oids ; attribute types extensions WSP RPAREN ; extensions
MatchingRuleUseDescription = LPAREN WSP numericoid。オブジェクト識別子[SP "NAME" SP qdescrs]。短い名前（記述子）[SP "DESC" SPのqdstring]。説明[SP「時代遅れ」]。ないアクティブSPはSPのOIDを「供給者」。種類の拡張子WSP RPAREN属性。拡張
where:
<numericoid> is the object identifier of the matching rule
associated with this matching rule use description;
NAME <qdescrs> are short names (descriptors) identifying this
matching rule use;
DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this matching rule use is not active;
APPLIES provides a list of attribute types the matching rule
applies to; and
<extensions> describe extensions.
LDAP Syntaxes of (attribute and assertion) values are described in terms of ASN.1 [X.680] and, optionally, have an octet string encoding known as the LDAP-specific encoding. Commonly, the LDAP-specific encoding is constrained to a string of Unicode [Unicode] characters in UTF-8 [RFC3629] form.
（属性アサーション）のLDAP構文は、値が[X.680]と、必要に応じて、LDAP固有の符号化として知られるオクテットストリングエンコーディングを有するASN.1の観点から説明されています。一般に、LDAP固有のエンコーディングはUTF-8 [RFC3629]形式のUnicode [UNICODE]文字列に制限されています。
Each LDAP syntax is identified by an object identifier (OID).
各LDAP構文は、オブジェクト識別子（OID）によって識別されます。
LDAP syntax definitions are written according to the ABNF:
LDAP構文定義はABNFに従って書かれています。
SyntaxDescription = LPAREN WSP numericoid ; object identifier [ SP "DESC" SP qdstring ] ; description extensions WSP RPAREN ; extensions
SyntaxDescription = LPAREN WSP numericoid。オブジェクト識別子[SP "DESC" SPのqdstring]。説明拡張WSP RPAREN。拡張
where: <numericoid> is the object identifier assigned to this LDAP syntax; DESC <qdstring> is a short descriptive string; and <extensions> describe extensions.
ここで、<numericoid>このLDAP構文に割り当てられたオブジェクト識別子です。 DESC <qdstring>は、短い説明文字列です。そして、<拡張子>の拡張機能について説明します。
A DIT content rule is a "rule governing the content of entries of a particular structural object class" [X.501].
DITコンテンツルールは、[X.501]「は、特定の構造化オブジェクト・クラスのエントリの内容を支配するルール」です。
For DIT entries of a particular structural object class, a DIT content rule specifies which auxiliary object classes the entries are allowed to belong to and which additional attributes (by type) are required, allowed, or not allowed to appear in the entries.
特定の構造化オブジェクト・クラスのDITエントリに対して、DITコンテンツルールは、エントリがエントリに表示させ、その追加（タイプによる）属性必要とされ、許可され、またはないに属するが許可されている補助オブジェクト・クラスを指定します。
The list of precluded attributes cannot include any attribute listed as mandatory in the rule, the structural object class, or any of the allowed auxiliary object classes.
排除属性のリストは、ルールに必須と記載されている任意の属性、構造的なオブジェクトクラス、または許可された補助オブジェクトクラスのいずれかを含むことができません。
Each content rule is identified by the object identifier, as well as any short names (descriptors), of the structural object class it applies to.
各コンテンツルールは、それが適用される構造化オブジェクト・クラスのオブジェクト識別子、ならびに任意の短縮名（記述子）によって識別されます。
An entry may only belong to auxiliary object classes listed in the governing content rule.
エントリーは唯一支配コンテンツルールに記載されている補助オブジェクトクラスに属してもよいです。
An entry must contain all attributes required by the object classes the entry belongs to as well as all attributes required by the governing content rule.
エントリは、エントリが属するオブジェクトクラスと同様に管理するコンテンツルールで必要とされるすべての属性によって必要なすべての属性が含まれている必要があります。
An entry may contain any non-precluded attributes allowed by the object classes the entry belongs to as well as all attributes allowed by the governing content rule.
エントリは、エントリが属するオブジェクトクラスと同様に管理するコンテンツルールで許可されたすべての属性によって許可されたすべての非除外属性が含まれていてもよいです。
An entry cannot include any attribute precluded by the governing content rule.
エントリが管理するコンテンツルールによって妨げ任意の属性を含めることはできません。
An entry is governed by (if present and active in the subschema) the DIT content rule that applies to the structural object class of the entry (see Section 2.4.2). If no active rule is present for the entry's structural object class, the entry's content is governed by the structural object class (and possibly other aspects of user and system schema). DIT content rules for superclasses of the structural object class of an entry are not applicable to that entry.
エントリは（セクション2.4.2を参照）のエントリの構造化オブジェクト・クラスに適用されるDITコンテンツルール（サブスキーマに存在し、アクティブな場合）によって支配されます。アクティブなルールは、エントリの構造化オブジェクト・クラスのために存在しない場合、エントリの内容は、構造化オブジェクト・クラス（及びユーザとシステムスキーマの可能性の他の側面）によって支配されます。エントリの構造的なオブジェクトクラスのスーパークラスのためのDITコンテンツ規則は、そのエントリには適用されません。
DIT content rule descriptions are written according to the ABNF:
DITのコンテンツルールの説明はABNFに従って書かれています。
DITContentRuleDescription = LPAREN WSP numericoid ; object identifier [ SP "NAME" SP qdescrs ] ; short names (descriptors) [ SP "DESC" SP qdstring ] ; description [ SP "OBSOLETE" ] ; not active [ SP "AUX" SP oids ] ; auxiliary object classes [ SP "MUST" SP oids ] ; attribute types [ SP "MAY" SP oids ] ; attribute types [ SP "NOT" SP oids ] ; attribute types extensions WSP RPAREN ; extensions
DITContentRuleDescription = LPAREN WSP numericoid。オブジェクト識別子[SP "NAME" SP qdescrs]。短い名前（記述子）[SP "DESC" SPのqdstring]。説明[SP「時代遅れ」]。アクティブではない[SP "AUX" のSPのOID]。補助オブジェクトクラス[SP「MUST」のSPのOID]。種類[SP "MAY" SPのOIDを]属性。種類[SP "NOT" SPのOIDを]属性。種類の拡張子WSP RPAREN属性。拡張
where:
<numericoid> is the object identifier of the structural object
class associated with this DIT content rule;
NAME <qdescrs> are short names (descriptors) identifying this DIT
content rule;
DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this DIT content rule use is not active;
AUX specifies a list of auxiliary object classes that entries
subject to this DIT content rule may belong to;
MUST, MAY, and NOT specify lists of attribute types that are required, allowed, or precluded, respectively, from appearing in entries subject to this DIT content rule; and <extensions> describe extensions.
、MAYは、このDITコンテンツルールの対象エントリに表示され、それぞれ、必要な許可、または除外される属性タイプのリストを指定してはなりません。そして、<拡張子>の拡張機能について説明します。
It is sometimes desirable to regulate where object and alias entries can be placed in the DIT and how they can be named based upon their structural object class.
オブジェクトと別名エントリがDITに入れて、どのように彼らは、構造オブジェクトクラスに基づいて名前を付けることができますすることができますどこ規制することが望ましい場合があります。
A DIT structure rule is a "rule governing the structure of the DIT by specifying a permitted superior to subordinate entry relationship. A structure rule relates a name form, and therefore a structural object class, to superior structure rules. This permits entries of the structural object class identified by the name form to exist in the DIT as subordinates to entries governed by the indicated superior structure rules" [X.501].
DIT構造規則は、下位エントリ関係に許容優れを指定することにより、DITの構造を支配する「ルールである。構造ルールは、優れた構造の規則に、名前の形式、したがって構造化オブジェクト・クラスに関する。これは、構造のエントリを可能にします名前形式で識別されるオブジェクト・クラスが示され、優れた構造規則」[X.501]によって支配エントリに部下としてDITに存在します。
DIT structure rule descriptions are written according to the ABNF:
DIT構造規則の説明はABNFに従って書かれています。
DITStructureRuleDescription = LPAREN WSP ruleid ; rule identifier [ SP "NAME" SP qdescrs ] ; short names (descriptors) [ SP "DESC" SP qdstring ] ; description [ SP "OBSOLETE" ] ; not active SP "FORM" SP oid ; NameForm [ SP "SUP" ruleids ] ; superior rules extensions WSP RPAREN ; extensions
DITStructureRuleDescription = LPAREN WSP ruleid。ルール識別子[SP "NAME" SP qdescrs]。短い名前（記述子）[SP "DESC" SPのqdstring]。説明[SP「時代遅れ」]。アクティブでないSP "FORM" SPのOID。 NameForm [SP "SUP" ruleids];優れたルール拡張WSP RPAREN。拡張
ruleids = ruleid / ( LPAREN WSP ruleidlist WSP RPAREN ) ruleidlist = ruleid *( SP ruleid ) ruleid = number
ruleids = ruleid /（LPAREN WSP WSP ruleidlist RPAREN）ruleidlist ruleid * =（SPのruleid）=番号ruleid
where:
<ruleid> is the rule identifier of this DIT structure rule;
NAME <qdescrs> are short names (descriptors) identifying this DIT
structure rule;
DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this DIT structure rule use is not active;
FORM is specifies the name form associated with this DIT structure
rule;
SUP identifies superior rules (by rule id); and
<extensions> describe extensions.
If no superior rules are identified, the DIT structure rule applies to an autonomous administrative point (e.g., the root vertex of the subtree controlled by the subschema) [X.501].
全く優れルールが特定されない場合、DIT構造規則自律管理ポイントに適用される（例えば、サブスキーマによって制御されるサブツリーのルート頂点）[X.501]。
A name form "specifies a permissible RDN for entries of a particular structural object class. A name form identifies a named object class and one or more attribute types to be used for naming (i.e., for the RDN). Name forms are primitive pieces of specification used in the definition of DIT structure rules" [X.501].
名前の形式は、「特定の構造的オブジェクトクラスのエントリの許容RDNを指定します。名前の形式は、（RDNのために、すなわち）の命名に使用するというオブジェクトクラスと1つのまたは複数の属性タイプを識別します。名前のフォームをの原始的な作品ですDIT構造規則」の定義に使用される仕様[X.501]。
Each name form indicates the structural object class to be named, a set of required attribute types, and a set of allowed attribute types. A particular attribute type cannot be in both sets.
それぞれの名前の形式は、指定される構造的なオブジェクトクラス、必要な属性タイプのセット、および許可された属性タイプのセットを示します。特定の属性タイプは、両方のセットにすることはできません。
Entries governed by the form must be named using a value from each required attribute type and zero or more values from the allowed attribute types.
フォームに支配エントリが必要な各属性の型と許可属性タイプからゼロ以上の値からの値を使用して名前を付ける必要があります。
Each name form is identified by an object identifier (OID) and, optionally, one or more short names (descriptors).
各ネームフォームは、オブジェクト識別子（OID）と、必要に応じて、一つ以上の短い名前（記述子）によって識別されます。
Name form descriptions are written according to the ABNF:
名前フォーム記述はABNFに従って書かれています。
NameFormDescription = LPAREN WSP numericoid ; object identifier [ SP "NAME" SP qdescrs ] ; short names (descriptors) [ SP "DESC" SP qdstring ] ; description [ SP "OBSOLETE" ] ; not active SP "OC" SP oid ; structural object class SP "MUST" SP oids ; attribute types [ SP "MAY" SP oids ] ; attribute types extensions WSP RPAREN ; extensions
NameFormDescription = LPAREN WSP numericoid。オブジェクト識別子[SP "NAME" SP qdescrs]。短い名前（記述子）[SP "DESC" SPのqdstring]。説明[SP「時代遅れ」]。アクティブでないSP "OC" SPのOID。構造化オブジェクトクラスSPはSPのOIDは「MUST」。種類[SP "MAY" SPのOIDを]属性。種類の拡張子WSP RPAREN属性。拡張
where:
<numericoid> is object identifier that identifies this name form;
NAME <qdescrs> are short names (descriptors) identifying this name
form;
DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this name form is not active;
OC identifies the structural object class this rule applies to,
MUST and MAY specify the sets of required and allowed,
respectively, naming attributes for this name form; and
<extensions> describe extensions.
All attribute types in the required ("MUST") and allowed ("MAY") lists shall be different.
必要な（「MUST」）と許可のすべての属性タイプは、（「MAY」）リストは異なるものでなければなりません。
Subschema (sub)entries are used for administering information about the directory schema. A single subschema (sub)entry contains all schema definitions (see Section 4.1) used by entries in a particular part of the directory tree.
サブスキーマ（サブ）のエントリは、ディレクトリスキーマに関する情報を管理するために使用されています。単一サブスキーマ（サブ）エントリは、ディレクトリツリーの特定の部分のエントリで使用されるすべてのスキーマ定義（セクション4.1を参照）を含みます。
Servers that follow X.500(93) models SHOULD implement subschema using the X.500 subschema mechanisms (as detailed in Section 12 of [X.501]), so these are not ordinary object entries but subentries (see Section 3.2). LDAP clients SHOULD NOT assume that servers implement any of the other aspects of X.500 subschema.
X.500に従うサーバは、（93）のモデルは、（[X.501]のセクション12で詳述されるように）X.500サブスキーマメカニズムを使用してサブスキーマを実装する必要があり、従って、これらは、通常のオブジェクトのエントリが、サブエントリ（セクション3.2を参照）ではありません。 LDAPクライアントは、サーバがX.500サブスキーマの他の態様のいずれかを実装することを仮定するべきではありません。
Servers MAY allow subschema modification. Procedures for subschema modification are discussed in Section 14.5 of [X.501].
サーバーは、サブスキーマの変更を可能にすることができます。サブスキーマ変更のための手順は、[X.501]のセクション14.5に記載されています。
A server that masters entries and permits clients to modify these entries SHALL implement and provide access to these subschema (sub)entries including providing a 'subschemaSubentry' attribute in each modifiable entry. This is so clients may discover the attributes and object classes that are permitted to be present. It is strongly RECOMMENDED that all other servers implement this as well.
マスターエントリとは、これらのエントリを変更するために、クライアントを許可するサーバが実装し、各修正項目に「subschemaSubentry」属性を提供することを含むこれらのサブスキーマ（サブ）エントリへのアクセスを提供しなければなりません。クライアントが存在することが許可されている属性とオブジェクトクラスを発見することがありようにするためです。強く他のすべてのサーバが同様にこれを実装することをお勧めします。
The value of the 'subschemaSubentry' attribute is the name of the subschema (sub)entry holding the subschema controlling the entry.
「subschemaSubentry」属性の値は、エントリを制御するサブスキーマを保持するサブスキーマ（サブ）エントリの名前です。
( 2.5.18.10 NAME 'subschemaSubentry' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
（2.5.18.10 NAME 'subschemaSubentry' 平等distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation）
The 'distinguishedNameMatch' matching rule and the DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
「distinguishedNameMatch」マッチング規則及び識別名（1.3.6.1.4.1.1466.115.121.1.12）構文は[RFC4517]で定義されています。
Subschema is held in (sub)entries belonging to the subschema auxiliary object class.
サブスキーマは、サブスキーマ補助オブジェクト・クラスに属する（サブ）のエントリに保持されています。
( 2.5.20.1 NAME 'subschema' AUXILIARY MAY ( dITStructureRules $ nameForms $ ditContentRules $ objectClasses $ attributeTypes $ matchingRules $ matchingRuleUse ) )
（2.5.20.1 NAME 'サブスキーマ' 補助MAY（dITStructureRules $ nameForms $ ditContentRules $のobjectClasses $ attributeTypes属性$ matchingRules $れるmatchingRuleUse））
The 'ldapSyntaxes' operational attribute may also be present in subschema entries.
「ldapSyntaxes」操作属性もサブスキーマエントリ中に存在することができます。
Servers MAY provide additional attributes (described in other documents) in subschema (sub)entries.
サーバーは、サブスキーマで（他の文書に記載されている）追加属性（サブ）のエントリを提供することができます。
Servers SHOULD provide the attributes 'createTimestamp' and 'modifyTimestamp' in subschema (sub)entries, in order to allow clients to maintain their caches of schema information.
サーバーは、クライアントがスキーマ情報のそれらのキャッシュを維持することを可能にするために、サブスキーマ（サブ）エントリの属性「createTimestamp」と「modifyTimestampの」を提供する必要があります。
The following subsections provide attribute type definitions for each of schema definition attribute types.
以下のサブセクションでは、スキーマ定義属性タイプごとに属性タイプの定義を提供します。
This attribute holds definitions of object classes.
この属性は、オブジェクトクラスの定義を保持しています。
( 2.5.21.6 NAME 'objectClasses' EQUALITY objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.37 USAGE directoryOperation )
（2.5.21.6 NAME 'のobjectClasses' 平等objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.37 USAGE directoryOperation）
The 'objectIdentifierFirstComponentMatch' matching rule and the ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) syntax are defined in [RFC4517].
「objectIdentifierFirstComponentMatch」マッチング規則及びObjectClassDescription（1.3.6.1.4.1.1466.115.121.1.37）構文は[RFC4517]で定義されています。
This attribute holds definitions of attribute types.
この属性は、属性タイプの定義を保持しています。
( 2.5.21.5 NAME 'attributeTypes' EQUALITY objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.3 USAGE directoryOperation )
（2.5.21.5 NAME 'attributeTypes属性' 平等objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.3 USAGE directoryOperation）
The 'objectIdentifierFirstComponentMatch' matching rule and the AttributeTypeDescription (1.3.6.1.4.1.1466.115.121.1.3) syntax are defined in [RFC4517].
「objectIdentifierFirstComponentMatch」マッチング規則及びAttributeTypeDescription（1.3.6.1.4.1.1466.115.121.1.3）構文は[RFC4517]で定義されています。
This attribute holds definitions of matching rules.
この属性は、マッチングルールの定義を保持しています。
( 2.5.21.4 NAME 'matchingRules' EQUALITY objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.30 USAGE directoryOperation )
（2.5.21.4 NAME 'matchingRules' 平等objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.30 USAGE directoryOperation）
The 'objectIdentifierFirstComponentMatch' matching rule and the MatchingRuleDescription (1.3.6.1.4.1.1466.115.121.1.30) syntax are defined in [RFC4517].
「objectIdentifierFirstComponentMatch」マッチング規則及びMatchingRuleDescription（1.3.6.1.4.1.1466.115.121.1.30）構文は[RFC4517]で定義されています。
This attribute holds definitions of matching rule uses.
この属性は、ルールの用途に合致するの定義を保持しています。
( 2.5.21.8 NAME 'matchingRuleUse' EQUALITY objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.31 USAGE directoryOperation )
（2.5.21.8 NAME 'れるmatchingRuleUse' 平等objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.31 USAGE directoryOperation）
The 'objectIdentifierFirstComponentMatch' matching rule and the MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) syntax are defined in [RFC4517].
「objectIdentifierFirstComponentMatch」マッチング規則及びMatchingRuleUseDescription（1.3.6.1.4.1.1466.115.121.1.31）構文は[RFC4517]で定義されています。
This attribute holds definitions of LDAP syntaxes.
この属性は、LDAP構文の定義を保持しています。
( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes' EQUALITY objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.54 USAGE directoryOperation )
（1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes' 平等objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.54 USAGE directoryOperation）
The 'objectIdentifierFirstComponentMatch' matching rule and the SyntaxDescription (1.3.6.1.4.1.1466.115.121.1.54) syntax are defined in [RFC4517].
「objectIdentifierFirstComponentMatch」マッチング規則及びSyntaxDescription（1.3.6.1.4.1.1466.115.121.1.54）構文は[RFC4517]で定義されています。
This attribute lists DIT Content Rules that are present in the subschema.
この属性はサブスキーマに存在しているDITコンテンツルールを示しています。
( 2.5.21.2 NAME 'dITContentRules' EQUALITY objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.16 USAGE directoryOperation )
（2.5.21.2 NAME 'dITContentRules' 平等objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.16 USAGE directoryOperation）
The 'objectIdentifierFirstComponentMatch' matching rule and the DITContentRuleDescription (1.3.6.1.4.1.1466.115.121.1.16) syntax are defined in [RFC4517].
「objectIdentifierFirstComponentMatch」マッチング規則及びDITContentRuleDescription（1.3.6.1.4.1.1466.115.121.1.16）構文は[RFC4517]で定義されています。
This attribute lists DIT Structure Rules that are present in the subschema.
この属性はサブスキーマに存在しているDIT構造規則を示しています。
( 2.5.21.1 NAME 'dITStructureRules' EQUALITY integerFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.17 USAGE directoryOperation )
（2.5.21.1 NAME 'dITStructureRules' 平等integerFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.17 USAGE directoryOperation）
The 'integerFirstComponentMatch' matching rule and the DITStructureRuleDescription (1.3.6.1.4.1.1466.115.121.1.17) syntax are defined in [RFC4517].
「integerFirstComponentMatch」マッチング規則及びDITStructureRuleDescription（1.3.6.1.4.1.1466.115.121.1.17）構文は[RFC4517]で定義されています。
This attribute lists Name Forms that are in force.
この属性は、施行されている名前のフォームが一覧表示されます。
( 2.5.21.7 NAME 'nameForms' EQUALITY objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.35 USAGE directoryOperation )
（2.5.21.7 NAME 'nameForms' 平等objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.35 USAGE directoryOperation）
The 'objectIdentifierFirstComponentMatch' matching rule and the NameFormDescription (1.3.6.1.4.1.1466.115.121.1.35) syntax are defined in [RFC4517].
「objectIdentifierFirstComponentMatch」マッチング規則及びNameFormDescription（1.3.6.1.4.1.1466.115.121.1.35）構文は[RFC4517]で定義されています。
The 'extensibleObject' auxiliary object class allows entries that belong to it to hold any user attribute. The set of allowed attribute types of this object class is implicitly the set of all attribute types of userApplications usage.
「extensibleObjectという」補助オブジェクトクラスがそれに属しているエントリは任意のユーザー属性を保持することができます。このオブジェクトクラスの許可属性タイプのセットは、暗黙的にuserApplications利用のすべての属性タイプのセットです。
( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject' SUP top AUXILIARY )
（1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObjectという' SUPトップAUXILIARY）
The mandatory attributes of the other object classes of this entry are still required to be present, and any precluded attributes are still not allowed to be present.
このエントリの他のオブジェクトクラスの必須属性がまだ存在することが必要であり、任意の除外属性がまだ存在することが許可されていません。
To discover the DN of the subschema (sub)entry holding the subschema controlling a particular entry, a client reads that entry's 'subschemaSubentry' operational attribute. To read schema attributes from the subschema (sub)entry, clients MUST issue a Search operation [RFC4511] where baseObject is the DN of the subschema (sub)entry,
特定のエントリを制御するサブスキーマを保持しているサブスキーマ（サブ）エントリのDNを発見するには、クライアントはそのエントリの「subschemaSubentry」操作属性を読み込みます。サブスキーマ（サブ）エントリからスキーマ属性を読み取るために、クライアントは、baseObjectはサブスキーマ（サブ）エントリのDNで検索動作[RFC4511]を発行しなければなりません
scope is baseObject, filter is "(objectClass=subschema)" [RFC4515], and the attributes field lists the names of the desired schema attributes (as they are operational). Note: the "(objectClass=subschema)" filter allows LDAP servers that gateway to X.500 to detect that subentry information is being requested.
範囲はbaseObjectであり、フィルタは「（のobjectClass =サブスキーマ）」[RFC4515]であり、そして（それらが動作しているように）属性フィールドは、所望のスキーマの属性の名前を一覧表示します。注：「（オブジェクトクラス=サブスキーマ）」フィルタは、X.500へのゲートウェイLDAPサーバがサブエントリ情報が要求されていることを検出することができます。
Clients SHOULD NOT assume that a published subschema is complete, that the server supports all of the schema elements it publishes, or that the server does not support an unpublished element.
クライアントは、サーバが発行したスキーマのすべての要素をサポートし、またはサーバーが公開されていない要素をサポートしていないということを、公表サブスキーマが完了したことを仮定するべきではありません。
The LDAP protocol assumes there are one or more servers that jointly provide access to a Directory Information Tree (DIT). The server holding the original information is called the "master" (for that information). Servers that hold copies of the original information are referred to as "shadowing" or "caching" servers.
LDAPプロトコルは、共同でディレクトリ情報ツリー（DIT）へのアクセスを提供する1つ以上のサーバーがある前提としています。元の情報を保持しているサーバは、（その情報について）「マスター」と呼ばれています。元の情報のコピーを保持するサーバーは、「シャドーイング」または「キャッシュ」サーバと呼ばれています。
As defined in [X.501]:
[X.501]で定義されます。
context prefix: The sequence of RDNs leading from the Root of the DIT to the initial vertex of a naming context; corresponds to the distinguished name of that vertex.
コンテキストプレフィックス：ネーミングコンテキストの初期頂点にDITのルートから先頭のRDNの配列;その頂点の識別名に対応しています。
naming context: A subtree of entries held in a single master DSA.
ネーミング・コンテキスト：単一のマスタDSAで開催されたエントリのサブツリー。
That is, a naming context is the largest collection of entries, starting at an entry that is mastered by a particular server, and including all its subordinates and their subordinates, down to the entries that are mastered by different servers. The context prefix is the name of the initial entry.
これは、ネーミングコンテキストがダウンして異なるサーバーによって習得されているエントリーに、特定のサーバによって習得されるエントリで始まる、およびそのすべての部下と部下を含め、エントリの最大のコレクションである、です。コンテキストの接頭辞は、最初のエントリの名前です。
The root of the DIT is a DSA-specific Entry (DSE) and not part of any naming context (or any subtree); each server has different attribute values in the root DSE.
DITのルートはDSA固有のエントリ（DSE）としない任意の名前付けコンテキスト（またはサブツリー）の一部です。各サーバーは、ルートDSEの異なる属性値を持っています。
An LDAP server SHALL provide information about itself and other information that is specific to each server. This is represented as a group of attributes located in the root DSE, which is named with the DN with zero RDNs (whose [RFC4514] representation is as the zero-length string).
LDAPサーバは、それ自体と、各サーバーに固有のその他の情報についての情報を提供しなければなりません。これは、（その[RFC4514]表現長さゼロの文字列の通りである）ゼロのRDNとDNと命名されているルートDSEに位置する属性のグループとして表されています。
These attributes are retrievable, subject to access control and other restrictions, if a client performs a Search operation [RFC4511] with an empty baseObject, scope of baseObject, the filter
クライアントは、検索操作を行った場合、これらの属性は、制御および他の制限にアクセスするには、回収対象となる空baseObjectと[RFC4511]、baseObjectの範囲、フィルタ
"(objectClass=*)" [RFC4515], and the attributes field listing the names of the desired attributes. It is noted that root DSE attributes are operational and, like other operational attributes, are not returned in search requests unless requested by name.
「（のobjectClass = *）」[RFC4515]、および所望の属性の名前をリスト属性フィールド。名前によって要求されない限り、ルートDSE属性は他の操作属性と同様に、検索要求で返されていない、運用としていることに留意されたいです。
The root DSE SHALL NOT be included if the client performs a subtree search starting from the root.
クライアントはルートから始まるサブツリー検索を実行する場合、ルートDSEは含まれないもの。
Servers may allow clients to modify attributes of the root DSE, where appropriate.
サーバーは、クライアントが適切なルートDSEの属性を変更することを可能にします。
The following attributes of the root DSE are defined below. Additional attributes may be defined in other documents.
ルートDSEの次の属性を以下のように定義されています。追加の属性は、他のドキュメントで定義されてもよいです。
- altServer: alternative servers;
- altServer：代替サーバ。
- namingContexts: naming contexts;
- のnamingContexts：名前付けコンテキスト。
- supportedControl: recognized LDAP controls;
- のsupportedControl：認識LDAPコントロール。
- supportedExtension: recognized LDAP extended operations;
- supportedExtension：認識LDAP拡張操作。
- supportedFeatures: recognized LDAP features;
- supportedFeatures：認識LDAP機能。
- supportedLDAPVersion: LDAP versions supported; and
- supportedLDAPVersion：LDAPバージョンはサポート。そして
- supportedSASLMechanisms: recognized Simple Authentication and Security Layers (SASL) [RFC4422] mechanisms.
- でsupportedSASLMechanismsは：簡易認証およびセキュリティ層（SASL）[RFC4422]メカニズムを認識しました。
The values provided for these attributes may depend on session-specific and other factors. For example, a server supporting the SASL EXTERNAL mechanism might only list "EXTERNAL" when the client's identity has been established by a lower level. See [RFC4513].
これらの属性のために提供された値は、セッション固有の及び他の要因に依存し得ます。たとえば、SASL EXTERNALメカニズムをサポートするサーバは、クライアントのIDは下位レベルでのみリスト「EXTERNAL」確立された可能性がある場合。 [RFC4513]を参照してください。
The root DSE may also include a 'subschemaSubentry' attribute. If it does, the attribute refers to the subschema (sub)entry holding the schema controlling the root DSE. Clients SHOULD NOT assume that this subschema (sub)entry controls other entries held by the server. General subschema discovery procedures are provided in Section 4.4.
ルートDSEも「subschemaSubentry」属性を含むことができます。それがない場合、属性は、ルートDSEを制御スキーマを保持するサブスキーマ（サブ）エントリを指します。クライアントは、このサブスキーマ（サブ）エントリは、サーバーが保持している他のエントリを制御することを仮定するべきではありません。一般的なサブスキーマ発見手順は、セクション4.4で提供されています。
The 'altServer' attribute lists URIs referring to alternative servers that may be contacted when this server becomes unavailable. URIs for servers implementing the LDAP are written according to [RFC4516]. Other kinds of URIs may be provided. If the server does not know of any other servers that could be used, this attribute will be absent. Clients may cache this information in case their preferred server later becomes unavailable.
「altServer」属性は、URIは、このサーバが使用不能になったときに接触させることができる代替サーバを参照一覧表示されます。 LDAPを実装したサーバのURIは、[RFC4516]に従って記述されています。 URIの他の種類を提供することができます。サーバーを使用することができる任意の他のサーバーを知っていない場合は、この属性は存在しません。クライアントは、彼らの優先サーバーが後に使用できなくなった場合には、この情報をキャッシュすることがあります。
( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 USAGE dSAOperation )
（1.3.6.1.4.1.1466.101.120.6 NAME 'altServer' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 USAGE dSAOperation）
The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax is defined in [RFC4517].
IA5String（1.3.6.1.4.1.1466.115.121.1.26）構文は[RFC4517]で定義されています。
The 'namingContexts' attribute lists the context prefixes of the naming contexts the server masters or shadows (in part or in whole). If the server is a first-level DSA [X.501], it should list (in addition) an empty string (indicating the root of the DIT). If the server does not master or shadow any information (e.g., it is an LDAP gateway to a public X.500 directory) this attribute will be absent. If the server believes it masters or shadows the entire directory, the attribute will have a single value, and that value will be the empty string (indicating the root of the DIT).
「のnamingContexts」属性は、サーバーのマスターか影（一部または全体）の名前付けコンテキストのコンテキストプレフィックスを示しています。サーバは、第一レベルのDSA [X.501]である場合、それは（DITのルートを示す）（加えて）空の文字列をリストするべきです。サーバーがマスターまたはいずれかの情報をシャドウしていない場合、この属性が存在しないことになる（例えば、それは公共のX.500ディレクトリへのLDAPゲートウェイです）。サーバがマスターか影ディレクトリ全体と考えている場合は、属性が単一の値を持つことになり、その値は（DITのルートを示す）、空の文字列になります。
This attribute may be used, for example, to select a suitable entry name for subsequent operations with this server.
この属性は、このサーバとのその後の操作に適したエントリ名を選択するために、例えば、使用することができます。
( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 USAGE dSAOperation )
（1.3.6.1.4.1.1466.101.120.5 NAME 'のnamingContexts' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 USAGE dSAOperation）
The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax is defined in [RFC4517].
識別名（1.3.6.1.4.1.1466.115.121.1.12）構文は[RFC4517]で定義されています。
The 'supportedControl' attribute lists object identifiers identifying the request controls [RFC4511] the server supports. If the server does not support any request controls, this attribute will be absent. Object identifiers identifying response controls need not be listed.
「のsupportedControl」属性リストは、サーバーがサポートする要求コントロール[RFC4511]を特定するオブジェクト識別子。サーバが要求コントロールをサポートしていない場合、この属性は存在しません。応答コントロールを識別するオブジェクト識別子が記載されている必要はありません。
Procedures for registering object identifiers used to discovery of protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].
プロトコルメカニズムの発見に使用されるオブジェクト識別子を登録するための手順は、BCP 64、RFC 4520 [RFC4520]に詳述されています。
( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl' SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation )
（1.3.6.1.4.1.1466.101.120.13 NAME 'のsupportedControl' SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation）
The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [RFC4517].
オブジェクト識別子（1.3.6.1.4.1.1466.115.121.1.38）構文は[RFC4517]で定義されています。
The 'supportedExtension' attribute lists object identifiers identifying the extended operations [RFC4511] that the server supports. If the server does not support any extended operations, this attribute will be absent.
「supportedExtension」属性リストは、サーバーがサポートする拡張操作[RFC4511]を特定するオブジェクト識別子。サーバが拡張操作をサポートしていない場合は、この属性は存在しません。
An extended operation generally consists of an extended request and an extended response but may also include other protocol data units (such as intermediate responses). The object identifier assigned to the extended request is used to identify the extended operation. Other object identifiers used in the extended operation need not be listed as values of this attribute.
拡張操作は、一般的に、拡張要求と拡張応答から構成も（例えば、中間応答のような）他のプロトコル・データ・ユニットを含むことができます。拡張要求に割り当てられたオブジェクト識別子は、拡張操作を識別するために使用されます。拡張された操作に使用される他のオブジェクト識別子は、この属性の値として記載されている必要はありません。
Procedures for registering object identifiers used to discovery of protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].
プロトコルメカニズムの発見に使用されるオブジェクト識別子を登録するための手順は、BCP 64、RFC 4520 [RFC4520]に詳述されています。
( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension' SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation )
（1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension' SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation）
The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [RFC4517].
オブジェクト識別子（1.3.6.1.4.1.1466.115.121.1.38）構文は[RFC4517]で定義されています。
The 'supportedFeatures' attribute lists object identifiers identifying elective features that the server supports. If the server does not support any discoverable elective features, this attribute will be absent.
「supportedFeatures」属性リストは、サーバーがサポートしている科目の特徴を識別するオブジェクト識別子。サーバが見つけ選挙の機能をサポートしていない場合、この属性は存在しません。
( 1.3.6.1.4.1.4203.1.3.5 NAME 'supportedFeatures' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation )
（1.3.6.1.4.1.4203.1.3.5 NAME 'supportedFeatures' 平等objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation）
Procedures for registering object identifiers used to discovery of protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].
プロトコルメカニズムの発見に使用されるオブジェクト識別子を登録するための手順は、BCP 64、RFC 4520 [RFC4520]に詳述されています。
The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax and objectIdentifierMatch matching rule are defined in [RFC4517].
オブジェクト識別子（1.3.6.1.4.1.1466.115.121.1.38）構文とobjectIdentifierMatchマッチング規則は[RFC4517]で定義されています。
The 'supportedLDAPVersion' attribute lists the versions of LDAP that the server supports.
「supportedLDAPVersion」属性は、サーバーがサポートするLDAPのバージョンを示します。
( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 USAGE dSAOperation )
（1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 USAGE dSAOperation）
The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in [RFC4517].
INTEGER（1.3.6.1.4.1.1466.115.121.1.27）構文は[RFC4517]で定義されています。
The 'supportedSASLMechanisms' attribute lists the SASL mechanisms [RFC4422] that the server recognizes and/or supports [RFC4513]. The contents of this attribute may depend on the current session state. If the server does not support any SASL mechanisms, this attribute will not be present.
「でsupportedSASLMechanisms」属性はSASLメカニズム[RFC4422]サーバーが認識および/またはサポートされていること[RFC4513]を示しています。この属性の内容は、現在のセッションの状態に依存してもよいです。サーバはどのSASLメカニズムをサポートしていない場合、この属性は存在しません。
( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE dSAOperation )
（1.3.6.1.4.1.1466.101.120.14 NAME 'でsupportedSASLMechanisms' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE dSAOperation）
The Directory String (1.3.6.1.4.1.1466.115.121.1.15) syntax is defined in [RFC4517].
ディレクトリ文字列（1.3.6.1.4.1.1466.115.121.1.15）構文は、[RFC4517]で定義されています。
Syntaxes may be defined that have specific value and/or value form (representation) preservation requirements. For example, a syntax containing digitally signed data can mandate that the server preserve both the value and form of value presented to ensure that the signature is not invalidated.
構文は、特定の値および/または値の形（表現）の保存要件を有するように定義されてもよいです。例えば、デジタル署名されたデータを含む構文は、サーバは、署名が無効にされていないことを確実にするために提示された値と値の形態の両方を保存することを強制することができます。
Where such requirements have not been explicitly stated, servers SHOULD preserve the value of user information but MAY return the value in a different form. And where a server is unable (or unwilling) to preserve the value of user information, the server SHALL ensure that an equivalent value (per Section 2.3) is returned.
このような要件が明示的に述べられていない場合は、サーバは、ユーザ情報の価値を維持すべきであるが、異なる形式で値を返すことがあります。サーバは、ユーザ情報の値を保持することができない（または望まない）であると、サーバは、（セクション2.3あたり）相当値が返されることを保証しなければなりません。
Short names, also known as descriptors, are used as more readable aliases for object identifiers and are used to identify various schema elements. However, it is not expected that LDAP implementations with human user interface would display these short names (or the object identifiers they refer to) to the user. Instead, they would most likely be performing translations (such as expressing the short name in one of the local national languages). For example, the short name "st" (stateOrProvinceName) might be displayed to a German-speaking user as "Land".
また、記述子として知られる短い名前は、オブジェクト識別子のためのより可読別名として使用され、様々なスキーマ要素を識別するために使用されます。しかし、人間のユーザ・インタフェースを持つLDAPの実装では、これらの短い名前（またはそれらが参照するオブジェクト識別子）がユーザに表示することが期待されていません。その代わり、彼らが最も可能性が高い（ローカル国語のいずれかに短い名前を表現するなど）の翻訳を実行することになります。例えば、短い名前「ST」（stateOrProvinceName）は、「土地」としてドイツ語圏のユーザーに表示される場合があります。
The same short name might have different meaning in different subschemas, and, within a particular subschema, the same short name might refer to different object identifiers each identifying a different kind of schema element.
同じ短い名前は異なるサブスキーマに異なる意味を持っているかもしれない、そして、特定のサブスキーマ内で、同じ短い名前は、各スキーマ要素の異なる種類を識別する異なるオブジェクト識別子を参照するかもしれません。
Implementations MUST be prepared that the same short name might be used in a subschema to refer to the different kinds of schema elements. That is, there might be an object class 'x-fubar' and an attribute type 'x-fubar' in a subschema.
実装は同じ短い名前は、スキーマ要素の異なる種類を参照するためにサブスキーマに使用されるかもしれないことを調製しなければなりません。つまり、オブジェクトのクラスx「は、めちゃくちゃ」と属性タイプがあるかもしれないサブスキーマに「-めちゃくちゃをX」。
Implementations MUST be prepared that the same short name might be used in the different subschemas to refer to the different schema elements. That is, there might be two matching rules 'x-fubar', each in different subschemas.
実装は同じ短い名前が異なるスキーマ要素を参照するために異なるサブスキーマで使用されるかもしれないことを準備しなければなりません。すなわち、2つのマッチングルール「X-FUBAR」、異なるサブスキーマ内の各があるかもしれない、です。
Procedures for registering short names (descriptors) are detailed in BCP 64, RFC 4520 [RFC4520].
短い名前（記述子）を登録するための手順は、BCP 64、RFC 4520 [RFC4520]に詳述されています。
Some servers may hold cache or shadow copies of entries, which can be used to answer search and comparison queries, but will return referrals or contact other servers if modification operations are requested. Servers that perform shadowing or caching MUST ensure that they do not violate any access control constraints placed on the data by the originating server.
いくつかのサーバは、検索と比較クエリに応答するために使用できるエントリのキャッシュまたはシャドウコピーを保持することができるが、紹介を返したり、修正操作が要求された場合は、他のサーバーに接続します。シャドウイングやキャッシングを実行サーバーは、彼らが元のサーバーでデータ上に置かれ、アクセス制御の制約に違反しないことを保証しなければなりません。
Servers MUST recognize all names of attribute types and object classes defined in this document but, unless stated otherwise, need not support the associated functionality. Servers SHOULD recognize all the names of attribute types and object classes defined in Section 3 and 4, respectively, of [RFC4519].
サーバーは、この文書で定義された属性タイプとオブジェクトクラスのすべての名前を認識したが、特に断りのない限り、関連する機能をサポートする必要はありませんしなければなりません。サーバは[RFC4519]の、それぞれ、第3および4で定義された属性タイプとオブジェクトクラスのすべての名前を認識すべきです。
Servers MUST ensure that entries conform to user and system schema rules or other data model constraints.
サーバは、エントリは、ユーザとシステムスキーマルールやその他のデータモデルの制約に準拠していることを保証しなければなりません。
Servers MAY support DIT Content Rules. Servers MAY support DIT Structure Rules and Name Forms.
サーバはDITのコンテンツルールをサポートするかもしれません。サーバはDIT構造規則と名前形式をサポートするかもしれません。
Servers MAY support alias entries.
サーバーは別名エントリをサポートするかもしれません。
Servers MAY support the 'extensibleObject' object class.
サーバは「extensibleObjectという」オブジェクトクラスをサポートするかもしれません。
Servers MAY support subentries. If so, they MUST do so in accordance with [RFC3672]. Servers that do not support subentries SHOULD use object entries to mimic subentries as detailed in Section 3.2.
サーバーは、サブエントリをサポートするかもしれません。もしそうなら、彼らは[RFC3672]に従って行う必要があります。サブエントリをサポートしていないサーバーは、3.2節で説明するようにサブエントリを模倣するオブジェクトのエントリを使用すべきです。
Servers MAY implement additional schema elements. Servers SHOULD provide definitions of all schema elements they support in subschema (sub)entries.
サーバーは、追加のスキーマ要素を実装してもよいです。サーバーは、サブスキーマ（サブ）のエントリでサポートしているすべてのスキーマ要素の定義を提供する必要があります。
In the absence of prior agreements with servers, clients SHOULD NOT assume that servers support any particular schema elements beyond those referenced in Section 7.1. The client can retrieve subschema information as described in Section 4.4.
サーバとの事前の合意がない場合には、クライアントは、サーバは7.1節で参照もの以外の任意の特定のスキーマ要素をサポートしていることを仮定するべきではありません。 4.4節で説明したように、クライアントはサブスキーマ情報を取得することができます。
Clients MUST NOT display or attempt to decode a value as ASN.1 if the value's syntax is not known. Clients MUST NOT assume the LDAP-specific string encoding is restricted to a UTF-8 encoded string of Unicode characters or any particular subset of Unicode (such as a printable subset) unless such restriction is explicitly stated. Clients SHOULD NOT send attribute values in a request that are not valid according to the syntax defined for the attributes.
クライアントが表示または値の構文が知られていない場合はASN.1として値をデコードすることを試みてはいけません。クライアントは、このような制限が明示的に述べられない限り、LDAP固有の文字列の符号化（例えば、印刷可能なサブセットとして）Unicode文字またはUnicodeのいずれかの特定のサブセットのUTF-8でエンコードされた文字列に制限されていると仮定してはいけません。クライアントは、属性に対して定義された構文に応じて有効ではありませんリクエストで属性値を送るべきではありません。
Attributes of directory entries are used to provide descriptive information about the real-world objects they represent, which can be people, organizations, or devices. Most countries have privacy laws regarding the publication of information about people.
ディレクトリエントリの属性は、人、組織、またはデバイスとすることができ、それらが表す実世界のオブジェクトに関する記述情報を提供するために使用されています。ほとんどの国は、人に関する情報の公開に関するプライバシー法を持っています。
General security considerations for accessing directory information with LDAP are discussed in [RFC4511] and [RFC4513].
LDAPでのディレクトリ情報にアクセスするための一般的なセキュリティ上の考慮事項は、[RFC4511]と[RFC4513]で議論されています。
The Internet Assigned Numbers Authority (IANA) has updated the LDAP descriptors registry as indicated in the following template:
次のテンプレートに示すように、IANA（Internet Assigned Numbers Authority）はLDAP記述子レジストリを更新しました：
Subject: Request for LDAP Descriptor Registration Update 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: RFC 4512 Author/Change Controller: IESG Comments:
件名：LDAP記述子登録更新記述子（短い名前）のための要求：コメントのオブジェクト識別子を参照してください。詳細のために連絡する人とEメールアドレスをコメント参照：クルトZeilenga <kurt@OpenLDAP.org>使用法：/ RFC 4512著者：コメントの仕様を参照してくださいコントローラを変更：IESGコメント：
The following descriptors (short names) has been added to the registry.
次の記述子（短い名前）は、レジストリに追加されました。
NAME Type OID
------------------------ ---- -----------------
governingStructureRule A 2.5.21.10
structuralObjectClass A 2.5.21.9
The following descriptors (short names) have been updated to refer to this RFC.
次の記述子（短い名前）は、このRFCを参照するように更新されました。
NAME Type OID
------------------------ ---- -----------------
alias O 2.5.6.1
aliasedObjectName A 2.5.4.1
altServer A 1.3.6.1.4.1.1466.101.120.6
attributeTypes A 2.5.21.5
createTimestamp A 2.5.18.1
creatorsName A 2.5.18.3
dITContentRules A 2.5.21.2
dITStructureRules A 2.5.21.1
extensibleObject O 1.3.6.1.4.1.1466.101.120.111
ldapSyntaxes A 1.3.6.1.4.1.1466.101.120.16 matchingRuleUse A 2.5.21.8
matchingRules A 2.5.21.4
modifiersName A 2.5.18.4
modifyTimestamp A 2.5.18.2
nameForms A 2.5.21.7
namingContexts A 1.3.6.1.4.1.1466.101.120.5
objectClass A 2.5.4.0
objectClasses A 2.5.21.6
subschema O 2.5.20.1
subschemaSubentry A 2.5.18.10
supportedControl A 1.3.6.1.4.1.1466.101.120.13
supportedExtension A 1.3.6.1.4.1.1466.101.120.7
supportedFeatures A 1.3.6.1.4.1.4203.1.3.5
supportedLDAPVersion A 1.3.6.1.4.1.1466.101.120.15
supportedSASLMechanisms A 1.3.6.1.4.1.1466.101.120.14
top O 2.5.6.0
This document is based in part on RFC 2251 by M. Wahl, T. Howes, and S. Kille; RFC 2252 by M. Wahl, A. Coulbeck, T. Howes, S. Kille; and RFC 2556 by M. Wahl, all products of the IETF Access, Searching and Indexing of Directories (ASID) Working Group. This document is also based in part on "The Directory: Models" [X.501], a product of the International Telephone Union (ITU). Additional text was borrowed from RFC 2253 by M. Wahl, T. Howes, and S. Kille.
この文書はM.ワール、T.ハウズ、およびS. KilleによってRFC 2251に部分的に基づいています。 M.ワール、A. Coulbeck、T.ハウズ、S. KilleによるRFC 2252。そして、M.ワール、IETFアクセスのすべての製品でRFC 2556、ワーキンググループの検索とディレクトリのインデックス（ASID）。 [X.501]、国際電話連合（ITU）の積：この文書はまた、「モデルディレクトリ」に基づいています。追加テキストはM.ワール、T.ハウズ、およびS. KilleによってRFC 2253から借用しました。
This document is a product of the IETF LDAP Revision (LDAPBIS) Working Group.
この文書は、IETF LDAP改訂（LDAPBIS）ワーキンググループの製品です。
[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月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[RFC3671] Zeilenga, K., "Collective Attributes in the Lightweight Directory Access Protocol (LDAP)", RFC 3671, December 2003.
[RFC3671] Zeilenga、K.、RFC 3671、2003年12月 "のLDAP（Lightweight Directory Access Protocol）におけるコレクティブ属性"。
[RFC3672] Zeilenga, K., "Subentries in the Lightweight Directory Access Protocol (LDAP)", RFC 3672, December 2003.
[RFC3672] Zeilenga、K.、RFC 3672 "のLDAP（Lightweight Directory Access Protocol）でサブエントリ"、2003年12月。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422]メルニコフ、A.編。そして、K. Zeilenga、エド。、 "簡易認証セキュリティー層（SASL）"、RFC 4422、2006年6月。
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
[RFC4510] Zeilenga、K.、エド、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：技術仕様ロードマップ"。、RFC 4510、2006年6月。
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511] Sermersheim、J.、エド、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：プロトコル"、RFC 4511、2006年6月。
[RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006.
[RFC4513]ハリソン、R.、エド、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：認証方法とセキュリティメカニズム"。、RFC 4513、2006年6月。
[RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006.
[RFC4514] Zeilenga、K.、エド、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：識別名の文字列表現"。、RFC 4514、2006年6月。
[RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters", RFC 4515, June 2006.
[RFC4515]スミス、M.、エド。そして、T.ハウズ、「ライトウェイトディレクトリアクセスプロトコル（LDAP）：検索フィルタの文字列表現」、RFC 4515、2006年6月。
[RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator", RFC 4516, June 2006.
[RFC4516]スミス、M.、エド。そして、T.ハウズ、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：ユニフォームリソースロケータ"、RFC 4516、2006年6月。
[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
[RFC4517]レッグ、S.、エド、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：構文と一致規則"、RFC 4517、2006年6月。
[RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, June 2006.
[RFC4519] Sciberras、A.、エド、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：ユーザー・アプリケーションのためのスキーマ"。、RFC 4519、2006年6月。
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
[RFC4520] Zeilenga、K.、 "IANA（Internet Assigned Numbers Authority）のライトウェイトディレクトリアクセスプロトコル（LDAP）に関する考慮事項"、BCP 64、RFC 4520、2006年6月。
[Unicode] The Unicode Consortium, "The Unicode Standard, Version 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201- 61633-5), as amended by the "Unicode Standard Annex #27: Unicode 3.1" (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/).
[UNICODE]ユニコードコンソーシアムは、 "Unicode標準、バージョン3.2.0" は、 "Unicode規格、バージョン3.0"（読書、MA、アディソン・ウェズリー、61633から5 2000. ISBN 0-201-）などによって定義されます改正 "Unicode標準の附属書＃27：ユニコード3.1"（http://www.unicode.org/reports/tr27/）とで "Unicode標準の附属書＃28：Unicodeの3.2"（のhttp：//www.unicode .ORG /レポート/ TR28 /）。
[X.500] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory -- Overview of concepts, models and services," X.500(1993) (also ISO/IEC 9594-1:1994).
[X.500]国際電気通信連合 - 電気通信標準化部門、 "ディレクトリ - 概念、モデルとサービスの概要、" X.500（1993）（また、ISO / IEC 9594から1：1994）。
[X.501] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory -- Models," X.501(1993) (also ISO/IEC 9594- 2:1994).
[X.501]国際電気通信連合 - 電気通信標準化部門、 "ディレクトリ - モデル、" X.501（1993）（2もISO / IEC 9594-：1994）。
[X.680] International Telecommunication Union - Telecommunication Standardization Sector, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
[X.680]国際電気通信連合 - 電気通信標準化部門、 "抽象構文記法1（ASN.1） - 基本的な記法の仕様"、X.680（2002）（また、ISO / IEC 8824から1：2002）。
Appendix A. Changes
付録A.変更
This appendix is non-normative.
この付録は非規範的です。
This document amounts to nearly a complete rewrite of portions of RFC 2251, RFC 2252, and RFC 2256. This rewrite was undertaken to improve overall clarity of technical specification. This appendix provides a summary of substantive changes made to the portions of these documents incorporated into this document. Readers should consult [RFC4510], [RFC4511], [RFC4517], and [RFC4519] for summaries of remaining portions of these documents.
この文書では、この書き換えは、技術仕様の全体的な明瞭度を改善するために行われたRFC 2251、RFC 2252、およびRFC 2256の部分のほぼ完全な書き直しになります。この付録では、この文書に組み込まれたこれらの文書の部分に作られた実質的な変更の概要を示します。読者は、これらの文書の残りの部分の要約については[RFC4510]、[RFC4511]、[RFC4517]及び[RFC4519]を相談してください。
A.1. Changes to
A.1。への変更
This document incorporates from RFC 2251, Sections 3.2 and 3.4, and portions of Sections 4 and 6 as summarized below.
以下に要約されるように、この文書はRFC 2251、セクション3.2および3.4、及びセクション4及び6の部分から組み込まれています。
A.1.1.
A.1.1。
Section 3.2 of RFC 2251 provided a brief introduction to the X.500 data model, as used by LDAP. The previous specification relied on [X.501] but lacked clarity in how X.500 models are adapted for use by LDAP. This document describes the X.500 data models, as used by LDAP, in greater detail, especially in areas where adaptation is needed.
LDAPで使用されるようにRFC 2251のセクション3.2は、X.500データモデルを簡単に紹介を提供します。以前の仕様では、[X.501]に依存していましたが、X.500モデルはLDAPでの使用に適合しているかに明確さを欠いていました。この文書では、特に適応が必要とされている地域では、詳細に、LDAPで使用されるように、X.500データモデルについて簡単に説明します。
Section 3.2.1 of RFC 2251 described an attribute as "a type with one or more associated values". In LDAP, an attribute is better described as an attribute description, a type with zero or more options, and one or more associated values.
RFC 2251のセクション3.2.1は、「1つ以上の関連値を持つタイプ」などの属性を記述しました。 LDAPでは、属性は、より良好な属性記述、ゼロ以上のオプション、および1つまたは複数の関連する値を持つタイプとして記載されています。
Section 3.2.2 of RFC 2251 mandated that subschema subentries contain objectClasses and attributeTypes attributes, yet X.500(93) treats these attributes as optional. While generally all implementations that support X.500(93) subschema mechanisms will provide both of these attributes, it is not absolutely required for interoperability that all servers do. The mandate was removed for consistency with X.500(93). The subschema discovery mechanism was also clarified to indicate that subschema controlling an entry is obtained by reading the (sub)entry referred to by that entry's 'subschemaSubentry' attribute.
RFC 2251のセクション3.2.2には、そのサブスキーマサブエントリはのobjectClassesとattributeTypes属性は属性が含ま義務付け、まだX.500（93）は、オプションとして、これらの属性を扱います。一般的にX.500をサポートするすべての実装は、（93）サブスキーマメカニズムは、これらの属性の両方を提供しますが、それは絶対にすべてのサーバが行う相互運用性のために必要とされていません。任務は、X.500（93）との整合性のために取り出しました。サブスキーマ発見メカニズムは、そのエントリの「subschemaSubentry」属性によって参照される（サブ）エントリを読み取ることにより得られたエントリを制御そのサブスキーマを示すために明らかになりました。
A.1.2.
A.1.2。
Section 3.4 of RFC 2251 provided "Server-specific Data Requirements". This material, with changes, was incorporated in Section 5.1 of this document.
RFC 2251のセクション3.4には、「サーバ固有のデータ要件」を提供します。この材料は、変化に、このドキュメントのセクション5.1に組み込まれました。
Changes:
変更点：
- Clarify that attributes of the root DSE are subject to "other restrictions" in addition to access controls.
- ルートDSEの属性がコントロールにアクセスするために加えて、「その他の制限」の対象となっていることを明確にします。
- Clarify that only recognized extended requests need to be enumerated 'supportedExtension'.
- のみ認識拡張の要求が「supportedExtension」を列挙する必要があることを明確にします。
- Clarify that only recognized request controls need to be enumerated 'supportedControl'.
- のみ認識要求コントロールを列挙する必要があることを明確化「のsupportedControl」。
- Clarify that root DSE attributes are operational and, like other operational attributes, will not be returned in search requests unless requested by name.
- そのルートDSEの属性を明確に名前によって要求されない限り、他の操作属性と同様に、検索要求に返されることはありません、運用していると。
- Clarify that not all root DSE attributes are user modifiable.
- いないすべてのルートDSE属性は、ユーザ変更可能であることを明確にします。
- Remove inconsistent text regarding handling of the 'subschemaSubentry' attribute within the root DSE. The previous specification stated that the 'subschemaSubentry' attribute held in the root DSE referred to "subschema entries (or subentries) known by this server". This is inconsistent with the attribute's intended use as well as its formal definition as a single valued attribute [X.501]. It is also noted that a simple (possibly incomplete) list of subschema (sub)entries is not terribly useful. This document (in Section 5.1) specifies that the 'subschemaSubentry' attribute of the root DSE refers to the subschema controlling the root DSE. It is noted that the general subschema discovery mechanism remains available (see Section 4.4 of this document).
- ルートDSE内の「subschemaSubentry」属性の取り扱いに関する矛盾したテキストを削除します。以前の仕様では、ルートDSEで開催された「subschemaSubentry」属性は「このサーバが知られているサブスキーマエントリ（あるいはサブエントリ）」と呼ぶことを述べました。これは、単一値の属性[X.501]のように、属性の意図した用途だけでなく、その正式な定義と矛盾しています。また、サブスキーマ（サブ）エントリの簡単な（おそらく不完全な）リストがひどく有用ではないことに留意されたいです。 （セクション5.1で）この文書では、ルートDSEの「subschemaSubentry」属性はルートDSEを制御するサブスキーマを参照することを指定します。一般的なサブスキーマ検出メカニズムは、（このドキュメントのセクション4.4を参照）を利用できる残っていることが注目されます。
A.1.3.
A.1.3。
Portions of Section 4 of RFC 2251 detailing aspects of the information model used by LDAP were incorporated in this document, including:
LDAPによって使用される情報モデルの態様を詳細RFC 2251のセクション4の部分を含む、本文書に組み込まれました。
- Restriction of distinguished values to attributes whose descriptions have no options (from Section 4.1.3);
- 説明（セクション4.1.3から）何のオプションが用意されていない属性に区別値の制限。
- Data model aspects of Attribute Types (from Section 4.1.4), Attribute Descriptions (from 4.1.5), Attribute (from 4.1.8), Matching Rule Identifier (from 4.1.9); and
- （セクション4.1.4からの）属性タイプのデータモデルの態様は、（4.1.9から）ルール識別子マッチング、（4.1.5）からの説明、（4.1.8から）項目属性;そして
- User schema requirements (from Sections 4.1.6, 4.5.1, and 4.7).
- ユーザー・スキーマの要件（セクション4.1.6、4.5.1、および4.7）。
Clarifications to these portions include:
これらの部分の明確化は、次のとおりです。
- Subtyping and AttributeDescriptions with options.
- オプションとサブタイピングとAttributeDescriptions。
A.1.4.
A.1.4。
The Section 6.1 and the second paragraph of Section 6.2 of RFC 2251 where incorporated into this document.
6.1節および本文書に組み込まれたRFC 2251のセクション6.2の第二段落。
A.2. Changes to
A.2。への変更
This document incorporates Sections 4, 5, and 7 from RFC 2252.
この文書は、RFC 2252からセクション4、5、および7を搭載しています。
A.2.1.
A.2.1。
The specification was updated to use Augmented BNF [RFC4234]. The string representation of an OBJECT IDENTIFIER was tightened to disallow leading zeros as described in RFC 2252.
仕様は増補BNF [RFC4234]を使用するように更新されました。オブジェクト識別子の文字列表現は、RFC 2252に記載されているように先行ゼロを許可しないように締め付けました。
The <descr> syntax was changed to disallow semicolon (U+003B) characters in order to appear to be consistent its natural language specification "descr is the syntactic representation of an object descriptor, which consists of letters and digits, starting with a letter". In a related change, the statement "an AttributeDescription can be used as the value in a NAME part of an AttributeTypeDescription" was deleted. RFC 2252 provided no specification of the semantics of attribute options appearing in NAME fields.
<DESCR>構文がその自然言語仕様一致するように見えるためにはセミコロン（U + 003B）の文字を許可しないように変更されました「DESCRは文字で始まる、文字と数字から成るオブジェクト記述子の構文表現です」 。関連する変化を、ステートメント「のAttributeDescriptionはAttributeTypeDescriptionのNAME部分で値として使用することができ、」削除されました。 RFC 2252は、NAMEフィールドに出現する属性オプションの意味のない仕様を提供しません。
RFC 2252 stated that the <descr> form of <oid> SHOULD be preferred over the <numericoid> form. However, <descr> form can be ambiguous. To address this issue, the imperative was replaced with a statement (in Section 1.4) that while the <descr> form is generally preferred, <numericoid> should be used where an unambiguous <descr> is not available. Additionally, an expanded discussion of descriptor issues is in Section 6.2 ("Short Names").
RFC 2252は、<OID>の<DESCR>フォームは<numericoid>形態よりも好まれるべきであることを述べました。しかし、<DESCR>フォームが曖昧にすることができます。この問題に対処するために、不可欠の<DESCR>フォームが一般的に好ましいがあること（1.4項）声明で置換した明確な<DESCR>が利用できない場合、<numericoid>を使用する必要があります。また、記述問題の拡大の議論は、6.2項（「ショートネーム」）です。
The ABNF for a quoted string (qdstring) was updated to reflect support for the escaping mechanism described in Section 4.3 of RFC 2252.
引用符で囲まれた文字列のためのABNF（qdstring）は、RFC 2252のセクション4.3で説明したエスケープ機構のサポートを反映するように更新されました。
A.2.2.
A.2.2。
Definitions of operational attributes provided in Section 5 of RFC 2252 where incorporated into this document.
RFC 2252のセクション5に設けられた操作属性の定義は、この文書に組み込まれています。
The 'namingContexts' description was clarified. A first-level DSA should publish, in addition to other values, "" indicating the root of the DIT.
「のnamingContexts」説明が明らかになりました。第一レベルのDSAはDITのルートを示す「」、他の値に加えて、公開すべきです。
The 'altServer' description was clarified. It may hold any URI.
「altServer」説明が明らかになりました。これは、任意のURIを保持することができます。
The 'supportedExtension' description was clarified. A server need only list the OBJECT IDENTIFIERs associated with the extended requests of the extended operations it recognizes.
「supportedExtension」説明が明らかになりました。サーバーは、それが認識する拡張操作の延長の要求に関連付けられているオブジェクト識別子をリストアップする必要が。
The 'supportedControl' description was clarified. A server need only list the OBJECT IDENTIFIERs associated with the request controls it recognizes.
「のsupportedControl」説明が明らかになりました。サーバーは、それが認識する要求コントロールに関連付けられているオブジェクト識別子をリストアップする必要が。
Descriptions for the 'structuralObjectClass' and 'governingStructureRule' operational attribute types were added.
「structuralObjectClass」と「governingStructureRule」操作属性の種類の説明が追加されました。
The attribute definition of 'subschemaSubentry' was corrected to list the terms SINGLE-VALUE and NO-USER-MODIFICATION in proper order.
「subschemaSubentry」の属性定義は、適切な順序で条件にSINGLE-VALUEとNO-USER-修正を一覧表示するには修正されました。
A.2.3.
A.2.3。
Section 7 of RFC 2252 provides definitions of the 'subschema' and 'extensibleObject' object classes. These definitions where integrated into Section 4.2 and Section 4.3 of this document, respectively. Section 7 of RFC 2252 also contained the object class implementation requirement. This was incorporated into Section 7 of this document.
RFC 2252のセクション7「サブスキーマ」と「extensibleObjectという」オブジェクトクラスの定義を提供します。これらの定義はどこそれぞれ、4.2節とこのドキュメントのセクション4.3に統合されています。 RFC 2252のセクション7は、オブジェクトクラスの実装要件を含んでいました。これは、このドキュメントのセクション7に組み込まれました。
The specification of 'extensibleObject' was clarified regarding how it interacts with precluded attributes.
「extensibleObjectという」の仕様は、それがに排除する属性とどのように相互作用するかについては明らかにしました。
A.3. Changes to
A.3。への変更
This document incorporates Sections 5.1, 5.2, 7.1, and 7.2 of RFC 2256.
この文書は、セクション5.1、5.2、7.1、およびRFC 2256の7.2が組み込まれています。
Section 5.1 of RFC 2256 provided the definition of the 'objectClass' attribute type. This was integrated into Section 2.4.1 of this document. The statement "One of the values is either 'top' or 'alias'" was replaced with statement that one of the values is 'top' as entries belonging to 'alias' also belong to 'top'.
RFC 2256のセクション5.1には、「オブジェクトクラス」属性タイプの定義を提供します。これは、このドキュメントのセクション2.4.1に統合されました。声明「のいずれかの値であるいずれかの 『トップ』や 『エイリアスは』」の値のいずれかが「エイリアス」に属するエントリとして「上」であることを声明でも「上」に属している置き換えられました。
Section 5.2 of RFC 2256 provided the definition of the 'aliasedObjectName' attribute type. This was integrated into Section 2.6.2 of this document.
RFC 2256のセクション5.2には、「aliasedObjectName」属性タイプの定義を提供します。これは、このドキュメントのセクション2.6.2に統合されました。
Section 7.1 of RFC 2256 provided the definition of the 'top' object class. This was integrated into Section 2.4.1 of this document.
RFC 2256のセクション7.1には、「上」のオブジェクトクラスの定義を提供します。これは、このドキュメントのセクション2.4.1に統合されました。
Section 7.2 of RFC 2256 provided the definition of the 'alias' object class. This was integrated into Section 2.6.1 of this document.
RFC 2256のセクション7.2には、「別名」オブジェクトクラスの定義を提供します。これは、このドキュメントのセクション2.6.1に統合されました。
A.4. Changes to
A.4。への変更
This document made no substantive change to the 'supportedFeatures' technical specification provided in RFC 3674.
この文書は、RFC 3674で提供「supportedFeatures」技術仕様への実質的な変更を加えていません。
Editor's Address
編集者の住所
Kurt D. Zeilenga OpenLDAP Foundation
クルトD. ZeilengaのOpenLDAP財団
EMail: Kurt@OpenLDAP.org
メールアドレス：Kurt@OpenLDAP.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。