[要約] RFC 4512は、LDAPのディレクトリ情報モデルに関する規格であり、ディレクトリサービスの構造とデータの表現方法を定義しています。このRFCの目的は、異なるディレクトリサービス間の相互運用性を確保するための共通のデータモデルを提供することです。
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
LightWeight Directory Access Protocol（LDAP）：ディレクトリ情報モデル
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
Lightweight Directory Access Protocol（LDAP）は、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.500ディレクトリ情報モデル[X.501]について説明します。
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）として知られています。人間または他のエンティティである場合があるディレクトリユーザーは、クライアント（またはディレクトリユーザーエージェント（DUA））を介してディレクトリにアクセスします。クライアントは、ディレクトリユーザーに代わって、1つ以上のサーバー（またはディレクトリシステムエージェント（DSA））と対話します。サーバーは、ディブの断片を保持します。
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では、ディレクトリの管理情報と運用情報のモデルについて説明します。
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技術仕様[RFC4510]の不可欠な部分であり、以前に定義されたLDAP技術仕様であるRFC 3377全体を廃止します。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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].
スキーマ定義は、LDAP説明形式（セクション4.1で定義されている）を使用して提供されます。ここで提供される定義は、読みやすさのためにフォーマットされています（ラインラップ）。これらの定義で参照されている一致するルールと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 )
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 " "
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 "}"
; 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)
OCTET = %x00-FF ; Any octet (8-bit data unit)
Object identifiers (OIDs) [X.680] are represented in LDAP using a dot-decimal format conforming to the ABNF:
オブジェクト識別子（OID）[X.680]は、ABNFに準拠したドットデシマル形式を使用してLDAPで表されます。
numericoid = number 1*( DOT number )
numericoiod = number1*（dot番号）
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
Where either an object identifier or a short name may be specified, the following production is used:
オブジェクト識別子または短い名前のいずれかを指定できる場合、次の生産が使用されます。
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>フォームは、使用率が、同様の種類のオブジェクト（例えば、属性タイプの説明、一致するルールの説明、オブジェクトクラスの説明）を識別するオブジェクト識別子を指す短い名前に制限されている場合、一般に好まれますが、<numericoiod>フォームはオブジェクト識別子が複数の種類のオブジェクトを識別できる場合、または明確な短い名前（記述子）が利用できない場合に使用されます。
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.
オブジェクトエントリは特定のオブジェクトを表します。エイリアスエントリは、代替命名を提供します。Subentryは、管理情報および/または運用情報を保持しています。
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.
属性は、1つ以上の関連する値を持つ属性説明（タイプとゼロ以上のオプション）です。属性は、しばしばその属性の説明によって参照されます。たとえば、「与えられた」属性は、属性の説明「与えられた名前」（「与えられた」属性タイプ[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.
たとえば、「与えられた」属性は複数の値を持つことができ、ディレクトリ文字列でなければならず、ケースは鈍感です。「与えられた」属性は、「ジョン」と「ジョン」の両方を保持することはできません。これらは、属性タイプの等式マッチングルールごとに同等の値です。
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.
さらに、それ自体に相当しない値を持つ属性はありません。たとえば、「与えられた」属性は、ディレクトリ文字列がこの属性の平等マッチングルールに従って未定義であることを含む一致するため、置換文字（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]:
以下は、RDNS [RFC4514]の文字列表現の例です。
UID=12345
OU=Engineering
CN=Kurt Zeilenga+L=Redwood Shores
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の連結です。著名な名前は、明確にツリーのエントリを指します。以下は、DNS [RFC4514]の文字列表現の例です。
UID=nobody@example.com,DC=example,DC=com
CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US
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.
オブジェクトクラス（サブクラス）は、さらに一般的なオブジェクトクラスから派生したオブジェクトクラス（その直接スーパークラス）から派生できます。構造オブジェクトクラスの場合、このプロセスは、最も一般的なオブジェクトクラス「TOP」で停止します（セクション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.
オブジェクトクラスは、2つ以上の直接のスーパークラス（同じスーパークラスチェーンの一部ではないスーパークラス）から派生できます。サブクラス化のこの機能は、多重継承と呼ばれます。
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.
各オブジェクトクラスは、抽象、構造、または補助の3種類のオブジェクトクラスのいずれかと定義されています。
Each object class is identified by an object identifier (OID) and, optionally, one or more short names (descriptors).
各オブジェクトクラスは、オブジェクト識別子（OID）およびオプションで1つ以上の短い名前（記述子）によって識別されます。
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 'top' abstractはObjectclassしなければなりません）
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;
- DIT構造ルールは、構造オブジェクトクラスのみを指します。エントリの構造オブジェクトクラスは、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
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.
<tributeType>が属性タイプを識別し、各<オプション>は属性オプションを識別します。<AttributeType>と<option>の両方のプロダクションは、ケースの鈍感です。<option> sが表示される順序は無関係です。つまり、同じ<属性タイプ>と同じ<option> sのセットで構成される2つの<属性description> sは同等です。
Examples of valid attribute descriptions:
有効な属性説明の例：
2.5.4.0 cn;lang-de;lang-en owner
2.5.4.0 cn; lang-de; lang-en所有者
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.
- （タイプの）属性を命名に使用することはできません。 - 属性を追加する（またはすべての値を置き換える）場合、2つの値は同等ではない場合があります（2.2を参照）。 - 多値属性の個々の値は、独立して追加または削除されることはありません。 - そのようなタイプの値を使用した属性値アサーション（検索フィルターでの一致や比較など）は実行できません。
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）およびオプションで1つ以上の短い名前（記述子）によって識別されます。
There are multiple kinds of attribute description options. The LDAP technical specification details one kind: tagging options.
属性説明オプションには複数の種類があります。LDAPの技術仕様の詳細は、1種類のタグ付けオプションです。
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-bar; x-foo」では、「x-foo」と「x-bar」は相互に排他的であり、認識されていないものとして扱われます。
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で定義されている<オプション>生産に準拠した、短いケースに依存しないテキスト文字列として表されます。
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オプションの1つを除くすべてのすべての属性説明の直接（説明）サブタイプです。属性タイプにスーパータイプがある場合、属性の説明は、スーパータイプの属性説明とnタグ付けオプションの属性説明の直接（説明）サブタイプでもあります。つまり、 'cn; lang-de; lang-en'は、「cn; lang-de '、' cn; lang-en '、' name; lang-de; lang-en 'の直接（説明）サブタイプです。（ 'cn'は「name」のサブタイプです。どちらも[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").
エントリの補助的な管理を目的として、エントリにその説明の属性タイプが必要な属性のタイプと同じ属性階層に属する属性説明の値が含まれている場合、属性が必要であるという仕様が必要です。つまり、「名前」の仕様は「名前」または「name; x-tag-option」によって満たされますが、「cn」または「cn; x-tag-option」によっては満たされません（「cn」であっても「名前」のサブタイプです）。同様に、エントリには、その説明の属性タイプが、エントリが属するオブジェクトクラスの定義に明示的に含まれる属性階層に属する属性説明の値を含めることができます。エントリ。つまり、「name」と「name; x-tag-option」は「may name」（または "nist name"）によって許可されますが、「cn」と「cn; x-tag-option」は許可されていません。「May Name」（またはby by "nust name"）。
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.
各エイリアスエントリには、「AlisedObjectName」属性（X.500の「AlideNentryName」属性として知られている）内に、いくつかのオブジェクトの名前が含まれています。したがって、エイリアスエントリの著名な名前は、このオブジェクトの名前でもあります。
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.
注 - 「AliedObjectName」内の名前は、エイリアスによって指摘されていると言われています。エントリの著名な名前である必要はありません。
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.
エイリアス名のオブジェクト名への変換は呼ばれます（エイリアス）控除が行われ、対応する「AirasedObjectName」属性の値によって、言われた名前内で見つかったエイリアス名の体系的な置換を含む。このプロセスでは、複数のエイリアスエントリの調査が必要になる場合があります。
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
Alias entries belong to the 'alias' object class.
エイリアスエントリは、「エイリアス」オブジェクトクラスに属します。
( 2.5.6.1 NAME 'alias' SUP top STRUCTURAL MUST aliasedObjectName )
（2.5.6.1 name 'alias' sup top structuralはaideasedobjectnameしなければなりません）
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.
「aidedObjectName」属性は、エイリアスが指すエントリの名前を保持します。「AlideObjectName」属性は、X.500の「AliedEntryName」属性として知られています。
( 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 'airasedObjectName' equality distinguishednamematch構文1.3.6.1.4.1.146.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」マッチングルールとdistinguishedname（1.3.6.1.4.1.1.146.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ディレクトリ管理および運用情報モデルの選択された側面について説明します[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]で定義されているように、管理および運用目的のために保持するためにディレクトリに使用されます。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').
この仕様の「（sub）エントリ」という用語は、x.500（93）モデルを実装するサーバーが[RFC3672]で説明されているようにx.500（93）に従って、サブエントリーを使用し、他のサーバーはサブエントリー（補助的なサブエントリーの「補助」など）で通常使用される適切な補助クラスに属するオブジェクトエントリを使用して、サブエントリを模倣します。このオブジェクトエントリのRDNは、 'cn'（commonname）属性[RFC4519]の値から形成されます（すべてのサブエントリが「CN」と命名されているため）。
Each entry in the DIT has an 'objectClass' attribute.
DITの各エントリには、「ObjectClass」属性があります。
( 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 'objectclass' equality objectidentidifiermatch構文1.3.6.1.1.1466.115.121.1.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.1.14.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.
「ObjectClass」属性は、エントリのオブジェクトクラスを指定します。これは、（とりわけ）制御スキーマと組み合わせて使用され、エントリの許可された属性を決定します。この属性の値はクライアントによって変更できますが、「オブジェクトクラス」属性を削除することはできません。
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).
エントリを作成したり、エントリに「ObjectClass」値を追加する場合、名前付きクラスのすべてのスーパークラスは、まだ存在していない場合、暗黙的に追加されます。つまり、補助クラス「X-A」がクラス「X-B」のサブクラスである場合、「X-A」を「オブジェクトクラス」に追加すると、「X-B」が暗黙的に追加されます（まだ存在していない場合）。
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.
サーバーは、残りの「オブジェクトクラス」値のスーパークラスが削除されるのを防ぐために、この属性の変更を制限するものとします。つまり、補助クラス「X-A」が補助クラス「X-B」のサブクラスであり、「オブジェクトクラス」属性に「X-A」と「X-B」が含まれている場合、「ObjectClass」から「X-B」のみを削除しようとする試みです。属性はエラーです。
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]に記載されているように、「3つの種類には、ディレクトリオペレーショナル属性、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').
ディレクトリ運用属性は、ディレクトリ情報モデルの運用情報および/または管理情報を表すために使用されます。これには、サーバーによって維持される運用属性（「createTimestamp」など）と、ユーザーが管理する値（「ditcontentrules」など）を保持する運用属性が含まれます。
A DSA-shared operational attribute is used to represent information of the DSA Information Model that is shared between DSAs.
DSA-SHARED運用属性は、DSA間で共有される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間で共有される情報から導き出される場合があります。
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.
- ModiyTimestamp：このエントリが最後に変更された時期。
Servers SHOULD maintain the 'creatorsName', 'createTimestamp', 'modifiersName', and 'modifyTimestamp' attributes for all entries of the DIT.
サーバーは、DITのすべてのエントリに対して「creatorsName」、「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.
この属性は、プロトコルを使用して追加されたエントリに表示されます（たとえば、ADD操作を使用して）。値は、作成者の著名な名前です。
( 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' equality distinguishednamematch構文1.3.6.1.1.1466.115.121.1.12単一値なしユーザー修正使用法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」マッチングルールとdistinguishedname（1.3.6.1.4.1.1.146.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.
この属性は、プロトコルを使用して追加されたエントリに表示されます（たとえば、ADD操作を使用して）。値は、エントリが追加された時間です。
( 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' equality generalizedtimematch generalizedtime-orderingmatch構文の注文1.3.6.1.4.1.1466.115.121.1.24単一値なしユーザー修正使用法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」および「GeneralizedTime -OrderingMatch」マッチングルールと一般化された時間（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名前 'modifiersName' equality distinguishednamematch構文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」マッチングルールとdistinguishedname（1.3.6.1.4.1.1.146.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' equality generalizedtimematch jeraterizedtime-orderingmatch構文の注文1.3.6.1.4.1.146.115.121.1.24シングル価値なしユーザー修正ユーザーユーザーディレクトリオペレーション）
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」および「GeneralizedTime -OrderingMatch」マッチングルールと一般化された時間（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名 'StructuralObjectClass' equality Objectidentididifiermatch構文1.3.6.1.4.1.1466.115.121.1.38単一値なしユーザー修正の使用法ディレクトリオペレーション）
The 'objectIdentifierMatch' matching rule and OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [RFC4517].
ルールとオブジェクト識別子（1.3.6.1.4.1.1.1.14.115.121.1.38）の「ObjectIdentifierMatch」マッチングルール（1.3.6.1.4.1.1.1.1.1.1.1.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名「GoverningStructurerule」equality Integermatch Syntax 1.3.6.1.1.1466.115.121.1.27単一価値なし - ユーザー修正使用法ディレクトリオペレーション）
The 'integerMatch' matching rule and INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in [RFC4517].
「integermatch」マッチングルールと整数（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.
ディレクトリスキーマは、DITの構造、エントリの名前の可能な方法、エントリに保持できる情報、その情報とその組織を検索を促進するために階層に表すために使用される属性、および検索とその組織に関する定義と制約のセットです。情報の取得と、属性の値が属性値と一致するルールアサーションで一致する方法の取得。
NOTE 1 - The schema enables the Directory system to, for example:
注1-スキーマにより、ディレクトリシステムが次のようになります。
- 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;
b) DIT構造ルールの定義は、エントリが持つ可能性のある名前と、エントリが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 = numericoiod [lcurly len rcurly] len = number
oids = oid / ( LPAREN WSP oidlist WSP RPAREN )
oidlist = oid *( WSP DOLLAR WSP oid )
extensions = *( SP xstring SP qdstrings )
xstring = "X" HYPHEN 1*( ALPHA / HYPHEN / USCORE )
qdescrs = qdescr / ( LPAREN WSP qdescrlist WSP 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
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
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.
名前フィールドは、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.
時代遅れのフィールドは、存在する場合、要素がアクティブでないことを示します。
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
kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"
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
usage = "userApplications" / ; user
"directoryOperation" / ; directory operational
"distributedOperation" / ; DSA-shared operational
"dSAOperation" ; DSA-specific operational
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または構文フィールドの少なくとも1つを含める必要があります。構文フィールドが提供されていない場合、属性タイプの説明はスーパータイプからその値を取得します。
If SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING fields, if not specified, take their value from the supertype.
SUPフィールドが提供されている場合、平等、注文、およびサブストリングフィールドは、指定されていない場合、スーパータイプから価値を取得します。
Usage of userApplications, the default, indicates that attributes of this type represent user information. That is, they are user attributes.
デフォルトであるユーザーアプリケーションの使用法は、このタイプの属性がユーザー情報を表していることを示しています。つまり、それらはユーザー属性です。
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の使用法は、このタイプの属性がディレクトリ運用属性であることを示します。分散型の使用法は、このタイプの属性がDSA共有使用型属性であることを示しています。DSAOPERATIONの使用法は、このタイプの属性がDSA固有の操作属性であることを示しています。
COLLECTIVE requires usage userApplications. Use of collective attribute types in LDAP is discussed in [RFC3671].
Collectiveには、使用ユーザーアプリケーションが必要です。LDAPでの集合属性タイプの使用については、[RFC3671]で説明しています。
NO-USER-MODIFICATION requires an operational usage.
ユーザー修正なしでは、運用上の使用が必要です。
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.
このドキュメントでは、<aTTibetyPedScription>の構文フィールドが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.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）およびオプションで1つ以上の短い名前（記述子）によって識別されます。
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
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
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構文は、asn.1 [x.680]の観点から説明され、オプションでは、LDAP固有のエンコードとして知られるオクテット文字列エンコードがあります。一般的に、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.
ここで：<numericoiod>は、この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.
特定のStructuralオブジェクトクラスの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.
エントリは（存在していて、補助にアクティブな場合）エントリの構造オブジェクトクラスに適用されるDITコンテンツルールに準拠しています（セクション2.4.2を参照）。エントリの構造オブジェクトクラスにアクティブルールが存在しない場合、エントリのコンテンツは構造オブジェクトクラス（および場合によってはユーザーおよびシステムスキーマの他の側面）によって支配されます。エントリの構造オブジェクトクラスのスーパークラスの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
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.
この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の構造を管理するルールです。構造ルールは、名前の形式、したがって構造オブジェクトクラスを優れた構造ルールに関連付けます。これにより、構造のエントリが許可されます。指定された優れた構造ルールによって支配されたエントリの部下としてDITに存在する名前フォームによって識別されるオブジェクトクラス[X.501]。
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
ruleids = ruleid / ( LPAREN WSP ruleidlist WSP RPAREN )
ruleidlist = ruleid *( SP ruleid )
ruleid = number
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を指定します。名前フォームは、名前付きオブジェクトクラスと、命名に使用する1つ以上の属性タイプを識別します（つまり、RDNに）。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）およびオプションで1つ以上の短い名前（記述子）によって識別されます。
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
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.
必要な（「必須」）および許可（ "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.500サブスキーマメカニズム（[X.501]のセクション12で詳述されているように）を使用してサブスキーマを実装する必要があるため、これらは通常のオブジェクトエントリではなく、サブエントリです（セクション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名「Subschemasubentry」等自由著名な施設内構文1.3.6.1.4.1.1466.115.121.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」マッチングルールとdistinguishedname（1.3.6.1.4.1.1.146.115.121.1.12）の構文は[RFC4517]で定義されています。
Subschema is held in (sub)entries belonging to the subschema auxiliary object class.
補助的なものは、subschema補助オブジェクトクラスに属する（sub）エントリに保持されます。
( 2.5.20.1 NAME 'subschema' AUXILIARY MAY ( dITStructureRules $ nameForms $ ditContentRules $ objectClasses $ attributeTypes $ matchingRules $ matchingRuleUse ) )
（2.5.20.1 name 'subschema' Auxiliary May（ditStructurerules $ nameforms $ ditcontentrules $ objectclasses $ astributetypes $ 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」と「ModiyTimestamp」を提供する必要があります。
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' equality objectididifierfirstcomponentmatch 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].
「ObjectididifierFirstComponentMatch」マッチングルールと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 'astributeTypes' equality objecidefidefirScomponentMatch Syntax 1.3.6.1.4.1.146.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].
「ObjectididifierFirstComponentMatch」マッチングルールと属性のあるもの（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' equality objectididifierfirstcomponentmatch構文1.3.6.1.4.1.146.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」マッチングルールとMatchingRuleDesscription（1.3.6.1.4.1.1466.115.121.1.1.10）の構文は[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' equality objecidentifierfirstcomponentmatch Syntax 1.3.6.1.4.1.146.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」マッチングルールとMatchingRuleDesscription（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名 'ldapsyntaxes' equality objectidefierfirstcomponentMatch Syntax 1.3.6.1.4.1.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].
「ObjectididifierfirstComponentMatch」マッチングルールと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' equality objecidentididifierfirstcomponentmatch構文1.3.6.1.4.1.146.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」マッチングルールとditContentRuledesscription（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' equality integerfirstcomponentmatch構文1.3.6.1.4.1.146.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」マッチングルールとditStructureruleDesscription（1.3.6.1.4.1.1466.115.121.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' equality objecidentidifierfirstcomponentmatch構文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.1.1.1466.115.121.1.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」補助オブジェクトクラスを使用すると、それに属するエントリがユーザー属性を保持できます。このオブジェクトクラスの許可された属性タイプのセットは、暗黙的にすべての属性タイプのユーザーアプリケーション使用のセットです。
( 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名「ExtensibleObject」SUP TOP AUXILYARY）
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, 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.
特定のエントリを制御するサブセマを保持する補助（サブ）エントリのDNを発見するために、クライアントはそのエントリの「サブスキーマスベントリー」の運用属性を読み取ります。サブセマ（サブ）エントリからスキーマ属性を読み取るには、クライアントはSearch操作[RFC4511]を発行する必要があります[RFC4511]は、subschema（sub）エントリのdnです。スコープはbaseobject、フィルターは「（objectclass = subschema）」[RFC4515]、および属性フィールドは、目的のスキーマ属性の名前をリストします（動作しているため）。注：「（ObjectClass = subschema）」フィルターにより、X.500にゲートウェイするLDAPサーバーがSubentry情報が要求されていることを検出できます。
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サーバーは、それ自体および各サーバーに固有のその他の情報に関する情報を提供するものとします。これは、ルートDSEに位置する属性のグループとして表されます。これは、ゼロRDN（[RFC4514]表現がゼロ長さの文字列として）を持つDNと名付けられています。
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、BaseObjectの範囲、フィルターを使用して検索操作[RFC4511]を実行する場合、取得可能です。
"(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;
- サポートコントロール：認識された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の外部メカニズムをサポートするサーバーは、クライアントのIDがより低いレベルで確立されている場合にのみ「外部」をリストする場合があります。[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には、「schemasubentry」属性も含まれる場合があります。もしそうなら、属性は、ルート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名前「Altserver」構文1.3.6.1.4.1.146.115.121.1.1.26使用法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」属性は、サーバーマスターまたはシャドウ（部分的または全体）のネーミングコンテキストのコンテキストプレフィックスをリストします。サーバーが第1レベルの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.146.115.121.1.12使用法dsaoperation）
The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax is defined in [RFC4517].
distinguedname（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名 'supportedcontrol'構文1.3.6.1.4.1.1466.115.121.1.38使用法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.1.146.115.121.1.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名前「supportedextension」構文1.3.6.1.4.1.1466.115.121.1.38使用法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.1.146.115.121.1.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名 'supportedfeatures' equality objecidentidifiermatch構文1.3.6.1.4.1.146.115.121.1.38使用法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.1.1.38）構文とobjectidentididifiermatch一致ルールは[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名 'supportedldapversion'構文1.3.6.1.4.1.146.115.121.1.27使用法dsaoperation）
The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in [RFC4517].
整数（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」属性は、サーバーが[RFC4513]を認識および/またはサポートするSASLメカニズム[RFC4422]をリストしています。この属性の内容は、現在のセッション状態によって異なります。サーバーが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 'Supportsaslmechanisms' Syntax 1.3.6.1.4.1.146.115.121.1.15使用法）
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.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".
記述子とも呼ばれる短い名前は、オブジェクト識別子のより読みやすいエイリアスとして使用され、さまざまなスキーマ要素を識別するために使用されます。ただし、Humanユーザーインターフェイスを使用したLDAP実装により、これらの短い名前（または参照するオブジェクト識別子）がユーザーに表示されることは予想されません。代わりに、彼らはおそらく翻訳を実行しているでしょう（地元の国語の1つで短い名前を表現するなど）。たとえば、短い名前「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-Fubar」と属性タイプ「X-Fubar」があるかもしれません。
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.
サーバーは、「拡張可能なオブジェクト」オブジェクトクラスをサポートできます。
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]に従ってそうしなければなりません。Subentriesをサポートしていないサーバーは、セクション3.2で詳述されているように、オブジェクトエントリを使用してSubentriesを模倣する必要があります。
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.
値の構文が知られていない場合、クライアントは値を表示またはデコードしようとしてはなりません。クライアントは、LDAP固有の文字列エンコードがUTF-8エンコードされたUnicode文字の文字列またはUnicodeの特定のサブセット（印刷可能なサブセットなど）に制限されていると仮定してはなりません。そのような制限が明示的に述べられていない限り。クライアントは、属性に対して定義された構文に従って有効でない要求に属性値を送信しないでください。
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）は、次のテンプレートに示されているように、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記述子登録更新記述子（ショート名）のリクエスト：コメントオブジェクト識別子を参照：詳細については、連絡先のコメント担当者とメールアドレスを参照してください。コントローラーの変更：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。Wahl、T。Howes、およびS. KilleによってRFC 2251に一部基づいています。RFC 2252 by M. Wahl、A。Coulbeck、T。Howes、S。Kille;RFC 2556 by M. Wahl、IETFアクセスのすべての製品、ディレクトリ（ASID）ワーキンググループの検索、インデックス付け。このドキュメントは、一部は国際電話連合（ITU）の製品である「The Directory：Models」[X.501]にも基づいています。RFC 2253からM. Wahl、T。Howes、およびS. Killeが追加のテキストを借りました。
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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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。、「軽量ディレクトリアクセスプロトコル（LDAP）の集合属性」、RFC 3671、2003年12月。
[RFC3672] Zeilenga, K., "Subentries in the Lightweight Directory Access Protocol (LDAP)", RFC 3672, December 2003.
[RFC3672] Zeilenga、K。、「軽量ディレクトリアクセスプロトコル（LDAP）のサブエントリ」、RFC 3672、2003年12月。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234] Crocker、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] Melnikov、A.、ed。K. Zeilenga編、「Simple Authentication and Security Layer（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。、ed。、「Lightweight Directory Access Protocol（LDAP）：技術仕様ロードマップ」、RFC 4510、2006年6月。
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511] Sermersheim、J.、ed。、「Lightweight Directory Access Protocol（LDAP）：The Protocol」、RFC 4511、2006年6月。
[RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006.
[RFC4513] Harrison、R.、ed。、「Lightweight Directory Access Protocol（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.、ed。、「Lightweight Directory Access Protocol（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. Howes、「Lightweight Directory Access Protocol（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. Howes、「Lightweight Directory Access Protocol（LDAP）：ユニフォームリソースロケーター」、RFC 4516、2006年6月。
[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
[RFC4517] Legg、S.、ed。、「Lightweight Directory Access Protocol（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.、ed。、「Lightweight Directory Access Protocol（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。、「Internet Assigned Numbers Authority（IANA）Lightweight Directory Access Protocol（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コンソーシアム「Unicode Standard、バージョン3.2.0」は、「Unicode Standard、バージョン3.0」（Reading、MA、Addison-Wesley、2000。ISBN0-201- 61633-5）で定義されています。「Unicode Standard Annex＃27：Unicode 3.1」（http://www.unicode.org/reports/tr27/）および「Unicode Standard Annex＃28：Unicode 3.2」（http：//www.unicode.org/Reports/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）（ISO/IEC 9594- 2：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）。
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]、[RFC4517]、[RFC4519]を参照する必要があります。
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の一部から組み込まれています。
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.
RFC 2251のセクション3.2は、LDAPが使用する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は、サブスキーマサブエントリにはオブジェクトクラスと属性属性が含まれていることを義務付けましたが、X.500（93）はこれらの属性をオプションとして扱います。一般に、X.500（93）サブスキーマメカニズムをサポートするすべての実装は、これらの属性の両方を提供しますが、すべてのサーバーが行う相互運用性には絶対に必要ではありません。委任状は、X.500（93）との一貫性のために削除されました。補助的な発見メカニズムは、エントリを制御する補助的なエントリがそのエントリの「サブスキーマスベントリー」属性で言及されている（サブ）エントリを読み取ることによって得られることを示すために明確にされました。
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'.
- 認識されている拡張リクエストのみが「サポートエクステンション」を列挙する必要があることを明確にします。
- Clarify that only recognized request controls need to be enumerated '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内の「schemasubentry」属性の処理に関する一貫性のないテキストを削除します。以前の仕様では、ルートDSEに保持されている「サブスキーマスベントリー」属性は、「このサーバーで知られている補助エントリ（またはサブエントリ）」に言及していると述べました。これは、属性の意図された使用と、単一の価値のある属性[x.501]としての正式な定義と矛盾しています。また、補助的な（サブ）エントリの単純な（おそらく不完全な）リストがそれほど有用ではないことにも注意してください。このドキュメント（セクション5.1）は、ルートDSEの「サブスキーマスベントリー」属性がルートDSEを制御するサブスケマを指すことを指定しています。一般的なサブスキーマ発見メカニズムは引き続き利用可能であることに注意してください（このドキュメントのセクション4.4を参照）。
Portions of Section 4 of RFC 2251 detailing aspects of the information model used by LDAP were incorporated in this document, including:
RFC 2251のセクション4の一部は、LDAPが使用する情報モデルの詳細な側面をこのドキュメントに組み込んでいます。
- 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.5から）、属性（4.1.8から）、一致するルール識別子（4.1.9から）。と
- 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.
- オプションを使用したサブタイピングと帰属式。
The Section 6.1 and the second paragraph of Section 6.2 of RFC 2251 where incorporated into this document.
このドキュメントに組み込まれたRFC 2251のセクション6.1とセクション6.2の2番目の段落。
This document incorporates Sections 4, 5, and 7 from RFC 2252.
このドキュメントには、RFC 2252のセクション4、5、および7が組み込まれています。
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]を使用するように更新されました。Object Identifierの文字列表現は、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>構文は、自然言語の仕様が一貫しているように見えるようにSemicolon（U 003b）文字を許可するように変更されました。関連する変更では、「属性と説明された説明は、属性の属性説明の名前の値として使用できます」という声明が削除されました。RFC 2252は、名前フィールドに表示される属性オプションのセマンティクスの仕様を提供しませんでした。
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>形式を<numericoiod>フォームよりも好むべきであると述べました。ただし、<descr>フォームはあいまいです。この問題に対処するために、命令は一般的に<descr>フォームが推奨されているが、<numericoiod>を使用しないでください。さらに、記述子の問題に関する拡張された議論は、セクション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.
引用された文字列（QDSTRING）のABNFは、RFC 2252のセクション4.3で説明されている脱出メカニズムのサポートを反映するように更新されました。
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」の説明が明確になりました。第1レベルの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.
「サポートコントロール」の説明が明確になりました。サーバーは、認識するリクエストコントロールに関連付けられたオブジェクト識別子のみをリストする必要があります。
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」の属性定義を修正して、単一価値と非ユーザー修正という用語を適切な順序でリストしました。
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では、「補助」および「拡張可能なオブジェクト」オブジェクトクラスの定義を提供します。これらの定義は、それぞれこのドキュメントのセクション4.2とセクション4.3に統合されています。RFC 2252のセクション7には、オブジェクトクラスの実装要件も含まれています。これは、このドキュメントのセクション7に組み込まれました。
The specification of 'extensibleObject' was clarified regarding how it interacts with precluded attributes.
「ExtensibleObject」の仕様は、それが排除された属性とどのように相互作用するかに関して明らかにされました。
This document incorporates Sections 5.1, 5.2, 7.1, and 7.2 of RFC 2256.
このドキュメントには、RFC 2256のセクション5.1、5.2、7.1、および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は、「ObjectClass」属性タイプの定義を提供しました。これは、このドキュメントのセクション2.4.1に統合されました。「値の1つは「トップ」または「エイリアス」のいずれか」のステートメントは、「エイリアス」に属するエントリも「トップ」に属するエントリとして、値の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は、「AlideObjectName」属性タイプの定義を提供しました。これは、このドキュメントのセクション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に統合されました。
This document made no substantive change to the 'supportedFeatures' technical specification provided in RFC 3674.
このドキュメントは、RFC 3674で提供されている「サポートフィーチャー」技術仕様に実質的な変更を加えませんでした。
Editor's Address
編集者のアドレス
Kurt D. Zeilenga OpenLDAP Foundation
Kurt D. Zeilenga OpenLdap Foundation
EMail: Kurt@OpenLDAP.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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）によって提供されます。