RFC 4512 - LDAP: ディレクトリ情報モデル
ネットワーク作業部会 K. Zeilenga コメント募集: 4512 OpenLDAP Foundation 廃止対象: 2251, 2252, 2256, 3674 2006 年 6 月 区分: 標準化過程
Lightweight Directory Access Protocol (LDAP):
ディレクトリ情報モデル
本文書の位置付け
本文書は、インターネットコミュニティのための標準化過程にあるプロトコルを 規定し、その改善に向けた議論と提案を求めるものである。本プロトコルの 標準化段階および状態については、最新版の「Internet Official Protocol Standards」(STD 1) を参照されたい。本文書の配布に制限はない。
著作権表示
Copyright (C) The Internet Society (2006).
要旨
Lightweight Directory Access Protocol (LDAP) は、X.500 のデータモデル およびサービスモデルに従って動作する分散ディレクトリサービスにアクセス するためのインターネットプロトコルである。本文書では、LDAP で使用される X.500 ディレクトリ情報モデルについて説明する。
目次
-
はじめに .......................................................3 1.1. 他の LDAP 仕様との関係 .....................................3 1.2. X.501 との関係 .............................................4 1.3. 表記規則 ...................................................4 1.4. 共通の ABNF 生成規則 .......................................4
-
ディレクトリ利用者情報のモデル .................................6 2.1. ディレクトリ情報ツリー .....................................7 2.2. エントリの構造 .............................................7 2.3. エントリの命名 .............................................8 2.4. オブジェクトクラス .........................................9 2.5. 属性記述 ..................................................12 2.6. エイリアスエントリ ........................................16
-
ディレクトリの管理情報および運用情報 ..........................17 3.1. サブツリー ................................................17 3.2. サブエントリ ..............................................18 3.3. 'objectClass' 属性 .........................................18 3.4. 運用属性 ..................................................19
-
ディレクトリスキーマ ..........................................22 4.1. スキーマ定義 ..............................................23 4.2. サブスキーマサブエントリ ................................32 4.3. 'extensibleObject' オブジェクトクラス ......................35 4.4. サブスキーマの発見 ........................................35
-
DSA (サーバー) 情報モデル .......................................36 5.1. サーバー固有のデータ要件 ....................................36
-
その他の考慮事項 ..............................................40 6.1. 利用者情報の保存 ..........................................40 6.2. 短い名前 ....................................................41 6.3. キャッシュおよびシャドウイング ............................41
-
実装指針 ......................................................42 7.1. サーバー向け指針 ............................................42 7.2. クライアント向け指針 ......................................42
-
セキュリティに関する考慮事項 ..................................43
-
IANA に関する考慮事項 .........................................43
-
謝辞 .........................................................44
-
規範的参考文献 ...............................................45 付録 A. 変更点 ...................................................47 A.1. RFC 2251 からの変更点 .....................................47 A.2. RFC 2252 からの変更点 .....................................49 A.3. RFC 2256 からの変更点 .....................................50 A.4. RFC 3674 からの変更点 .....................................51
-
はじめに
本文書では、Lightweight Directory Access Protocol (LDAP) [RFC4510] で使用される X.500 ディレクトリ情報モデル [X.501] について論じる。
ディレクトリとは、「ディレクトリサービスを提供するために協調する オープンシステムの集合」である [X.500]。ディレクトリに保持される情報は、 総称してディレクトリ情報ベース (Directory Information Base、DIB) と 呼ばれる。人間またはその他の実体であり得るディレクトリ利用者は、 クライアント (またはディレクトリ利用者エージェント (Directory User Agent、DUA)) を介してディレクトリにアクセスする。クライアントは ディレクトリ利用者に代わり、1 台以上のサーバー (またはディレクトリ システムエージェント (Directory System Agent、DSA)) と対話する。 サーバーは DIB の一部分を保持する。
DIB には、次の 2 種類の情報が含まれる。
1) 利用者情報 (たとえば、利用者によって提供および管理される情報)。
第 2 節では、利用者情報のモデルについて説明する。
2) 管理情報および運用情報 (たとえば、ディレクトリの管理および／または
運用に使用される情報)。第 3 節では、ディレクトリの管理情報および
運用情報のモデルについて説明する。
汎用ディレクトリ情報モデルと総称されるこれら 2 つのモデルは、情報が ディレクトリ内でどのように表現されるかを記述する。これらの汎用モデルは、 他の情報モデルの枠組みとなる。第 4 節ではサブスキーマ情報モデルと サブスキーマの発見について、第 5 節では DSA (サーバー) 情報モデルに ついて論じる。
その他の X.500 情報モデル (アクセス制御、分散知識、レプリケーション 知識の各情報モデルなど) も、LDAP で使用できるように適合させることが できる。これらのモデルを LDAP に適用する方法の規定は、今後の文書に 委ねる。
1.1. 他の LDAP 仕様との関係
本文書は LDAP 技術仕様 [RFC4510] の不可欠な一部であり、この技術仕様は、 以前に定義された LDAP 技術仕様 RFC 3377 を全面的に廃止する。
本文書は、RFC 2251 の 3.2 節および 3.4 節、ならびに 4 節および 6 節の 一部を廃止する。付録 A.1 に、これらの節に対する変更点を要約する。 RFC 2251 の残りの部分は、[RFC4511]、[RFC4513]、および [RFC4510] に よって廃止される。
本文書は、RFC 2252 の 4、5、および 7 節を廃止する。付録 A.2 に、 これらの節に対する変更点を要約する。RFC 2252 の残りの部分は [RFC4517] によって廃止される。
本文書は、RFC 2256 の 5.1、5.2、7.1、および 7.2 節を廃止する。 付録 A.3 に、これらの節に対する変更点を要約する。RFC 2256 の残りの 部分は、[RFC4519] および [RFC4517] によって廃止される。
本文書は RFC 3674 を全面的に廃止する。付録 A.4 に、RFC 3674 以降の 変更点を要約する。
1.2. X.501 との関係
本文書には、本プロトコルを説明するために必要な [X.501] の資料を、 適合化したものと適合化していないものの両方を含めている。これらの適合化 (および本文書におけるその他の相違点) は、本プロトコルにのみ適用される。
1.3. 表記規則
本文書におけるキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、 "SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、および "OPTIONAL" は、BCP 14 [RFC2119] の記述どおりに解釈されるものとする。
スキーマ定義は、LDAP 記述形式 (4.1 節で定義) を用いて提示する。ここで 提示する定義は、読みやすさのために整形 (行折り返し) されている。これらの 定義で参照されるマッチング規則および LDAP 構文は、[RFC4517] で規定される。
1.4. 共通の ABNF 生成規則
本文書の多くの構文は、拡張バッカス・ナウア記法 (Augmented Backus-Naur Form、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)
オブジェクト識別子 (OID) [X.680] は、LDAP では次の ABNF に準拠する ドット区切りの 10 進数形式で表現される。
numericoid = number 1*( DOT number )
記述子 (descriptor) とも呼ばれる短い名前は、オブジェクト識別子の読みやすい 別名として使用される。短い名前では大文字と小文字が区別されず、次の ABNF に 準拠する。
descr = keystring
オブジェクト識別子と短い名前のどちらも指定できる場合は、次の生成規則を 使用する。
oid = descr / numericoid
使用範囲が、同種のオブジェクトを識別するオブジェクト識別子 (たとえば、
属性タイプ記述、マッチング規則記述、オブジェクトクラス記述) を参照する
短い名前に限定される場合は、一般に
実装は、上記の意味で曖昧に使用される短い名前 (記述子) を、認識不能として 扱うべきである (SHOULD)。
短い名前 (記述子) については、6.2 節でさらに論じる。 2. ディレクトリ利用者情報のモデル
[X.501] では、次のように述べられている。
ディレクトリの目的は、ある「世界」における対象となるオブジェクト
(object) に関する情報を保持し、その情報へのアクセスを提供すること
である。オブジェクトは、識別可能 (命名可能) なものであれば何でも
よい。
オブジェクトクラス (object class) は、一定の特性を共有する、識別
されたオブジェクトまたは想定可能なオブジェクトの集合である。すべて
のオブジェクトは、少なくとも 1 つのクラスに属する。オブジェクト
クラスは他のオブジェクトクラスのサブクラスである場合があり、その
場合、前者のクラス、すなわちサブクラスのメンバーは、後者のクラス、
すなわちスーパークラスのメンバーでもあると見なされる。サブクラス
のサブクラスという関係も、任意の深さまで存在し得る。
ディレクトリエントリ (directory entry) は、名前を持つ情報の集合であり、 ディレクトリに保持される情報の基本単位である。ディレクトリエントリ には複数の種類がある。
オブジェクトエントリ (object entry) は特定のオブジェクトを表す。 エイリアスエントリ (alias entry) は代替名を提供する。サブエントリ (subentry) は管理情報および／または運用情報を保持する。
ディレクトリ情報ベース (Directory Information Base、DIB) を表すエントリ の集合は、ディレクトリ情報ツリー (Directory Information Tree、DIT) と 呼ばれる木構造に階層的に編成される。
2.1 節では、ディレクトリ情報ツリーについて説明する。 2.2 節では、エントリの構造について論じる。 2.3 節では、エントリの命名について論じる。
2.4 節では、オブジェクトクラスについて論じる。 2.5 節では、属性記述について論じる。 2.6 節では、エイリアスエントリについて論じる。
2.1. ディレクトリ情報ツリー
前述のとおり、DIB はディレクトリ情報ツリー (DIT) と呼ばれる木構造に 階層的に編成されたエントリの集合で構成される。より厳密には、エントリ を頂点とする木である。
頂点間の辺は、エントリ間の関係を定義する。X から Y への辺が存在する 場合、X のエントリは Y の直接上位であり、Y は X の直接下位である。 あるエントリの上位には、その直接上位と、その上位にあるすべての エントリが含まれる。あるエントリの下位には、そのすべての直接下位と、 それらの下位にあるすべてのエントリが含まれる。
同様に、オブジェクトエントリ間の上位／下位関係を用いて、それらが表す オブジェクト間の関係を導出できる。DIT 構造規則を用いて、オブジェクト 間の関係を規定できる。
注: エントリの直接上位は、そのエントリの親とも呼ばれ、エントリの 直接下位は、そのエントリの子とも呼ばれる。同じ親を持つエントリは、 兄弟と呼ばれる。
2.2. エントリの構造
エントリは、そのエントリが表すオブジェクトに関する情報を保持する属性 の集合からなる。一部の属性は利用者情報を表し、利用者属性 (user attribute) と呼ばれる。それ以外の属性は運用情報および／または管理情報 を表し、運用属性 (operational attribute) と呼ばれる。
属性は、属性記述 (1 つの型と 0 個以上のオプション) と、それに関連付け られた 1 つ以上の値からなる。属性は、その属性記述によって参照される ことが多い。たとえば、'givenName' 属性は、属性記述 'givenName' ('givenName' 属性タイプ [RFC4519] と 0 個のオプション) およびそれに 関連付けられた 1 つ以上の値からなる属性である。
属性タイプは、その属性が複数の値を持てるかどうか、その属性の値を構築 および比較するために使用する構文とマッチング規則、ならびにその他の 機能を規定する。オプションは、サブタイプおよびその他の機能を示す。
属性値は、属性タイプに対して定義された構文に従う。
1 つの属性の 2 つの値が等価であってはならない。2 つの値は、その属性 タイプの等価マッチング規則に従って照合した場合に一致するとき、かつ そのときに限り等価と見なされる。あるいは、属性タイプに等価マッチング 規則が定義されていない場合、2 つの値が同一であるとき、かつそのときに 限り等価である。(その他の制約については 2.5.1 節を参照。)
たとえば、'givenName' 属性は複数の値を持つことができ、それらは Directory String でなければならず、大文字と小文字は区別されない。 属性タイプの等価マッチング規則によりこれらは等価な値であるため、 'givenName' 属性は "John" と "JOHN" の両方を保持できない。
さらに、属性は、それ自身と等価でない値を持ってはならない。たとえば、 'givenName' 属性は、REPLACEMENT CHARACTER (U+FFFD) コードポイントを 含む Directory String を値として持つことができない。この属性の等価 マッチング規則によれば、その Directory String が関与する照合は Undefined になるためである。
属性をエントリの命名に使用する場合、相対識別名 (Relative Distinguished Name) を構成する際には、その属性の値を 1 つだけ使用する。この値を 識別値 (distinguished value) と呼ぶ。
2.3. エントリの命名
2.3.1. 相対識別名
各エントリは、その直接上位に対して相対的に命名される。この相対名は 相対識別名 (Relative Distinguished Name、RDN) [X.501] と呼ばれ、0 個 のオプションを持つ属性記述と属性値とで構成される、1 つ以上の属性値 アサーション (attribute value assertion、AVA) の順序なし集合からなる。 これらの AVA は、エントリの属性値 (それぞれが識別値) と一致するように 選択される。
エントリの相対識別名は、そのエントリの直接上位に属するすべての直接 下位、すなわちすべての兄弟の間で一意でなければならない。
RDN の文字列表現の例を次に示す [RFC4514]。
UID=12345
OU=Engineering
CN=Kurt Zeilenga+L=Redwood Shores
最後の例は複数値 RDN、すなわち複数の AVA で構成される RDN の例である。
2.3.2. 識別名
エントリの完全修飾名は識別名 (Distinguished Name、DN) [X.501] と呼ばれ、 そのエントリの RDN と、その直接上位の DN を連結したものである。識別名 は、ツリー内のエントリを曖昧さなく参照する。DN の文字列表現の例を次に 示す [RFC4514]。
[email protected],DC=example,DC=com
CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US
2.3.3. エイリアス名
エイリアス (alias)、すなわちエイリアス名 (alias name) とは、「エイリアス エントリの使用によってオブジェクトに与えられる名前」である [X.501]。 エイリアスエントリについては 2.6 節で説明する。
2.4. オブジェクトクラス
オブジェクトクラスは、「一定の特性を共有する、識別されたオブジェクト (または想定可能なオブジェクト) の集合」である [X.501]。
[X.501] では、次のように定義されている。
オブジェクトクラスは、ディレクトリ内で次のような多くの目的に使用
される。
- オブジェクト、およびそのオブジェクトに対応するエントリを記述し、
分類する。
- 適切な場合、ディレクトリの動作を制御する。
- DIT 構造規則の仕様と組み合わせて、DIT 内のエントリの位置を規定
する。
- DIT 内容規則の仕様と組み合わせて、エントリに含まれる属性を規定
する。
- 適切な管理権限によって特定のポリシーと関連付けられるエントリの
クラスを識別する。
あるオブジェクトクラス (サブクラス) は、別のオブジェクトクラス
(その直接スーパークラス) から派生でき、そのクラス自体も、さらに
一般的なオブジェクトクラスから派生できる。構造型オブジェクトクラス
の場合、この過程は最も一般的なオブジェクトクラスである 'top'
(2.4.1 節で定義) で終了する。あるオブジェクトクラスからその最上位の
オブジェクトクラスまでのスーパークラスの順序付き集合を、その
スーパークラスチェーン (superclass chain) と呼ぶ。
オブジェクトクラスは、2 つ以上の直接スーパークラス (同じスーパー
クラスチェーンに属さないスーパークラス) から派生することもできる。
このサブクラス化の機能を多重継承 (multiple inheritance) と呼ぶ。
各オブジェクトクラスは、そのクラスに属するエントリに存在することが 必須の属性集合と、存在が許可される属性集合を識別する。あるクラスの エントリは、それが属する各クラスの要件を満たさなければならないため、 オブジェクトクラスは許可属性および必須属性の集合をスーパークラスから 継承するといえる。サブクラスは、そのスーパークラスで許可されている 属性を必須として識別できる。ある属性が両方の集合のメンバーである場合、 その属性は存在しなければならない。
各オブジェクトクラスは、抽象 (Abstract)、構造型 (Structural)、または 補助 (Auxiliary) の 3 種類のいずれかとして定義される。
各オブジェクトクラスは、オブジェクト識別子 (object identifier、OID) と、 任意で 1 つ以上の短い名前 (記述子) によって識別される。
2.4.1. 抽象オブジェクトクラス
抽象オブジェクトクラスは、その名が示すように、他のオブジェクトクラス が継承するよう定義できる特性の基礎を提供する。エントリは、その抽象 クラスを継承する構造型クラスまたは補助クラスに属していない限り、抽象 オブジェクトクラスに属することはできない。
抽象オブジェクトクラスは、構造型または補助オブジェクトクラスから派生 できない。
すべての構造型オブジェクトクラスは、抽象オブジェクトクラス 'top' から 直接または間接に派生する。補助オブジェクトクラスは、必ずしも 'top' から派生するとは限らない。
'top' オブジェクトクラスのオブジェクトクラス定義 (4.1.1 節を参照) を 次に示す。
( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
すべてのエントリは、抽象オブジェクトクラス 'top' に属する。
2.4.2. 構造型オブジェクトクラス
[X.501] では、次のように述べられている。
DIT の構造仕様で使用するために定義されたオブジェクトクラスを、
構造型オブジェクトクラスと呼ぶ。構造型オブジェクトクラスは、準拠
エントリが表すオブジェクトの名前構造を定義するために使用される。
オブジェクトエントリまたはエイリアスエントリは、最下位のオブジェクト
クラスとして 1 つの構造型オブジェクトクラスを持つ、正確に 1 本の
構造型オブジェクトクラスのスーパークラスチェーンによって特徴付け
られる。この構造型オブジェクトクラスを、そのエントリの構造型
オブジェクトクラスと呼ぶ。
構造型オブジェクトクラスは、関連するエントリと次のような関係を持つ。
- 構造型オブジェクトクラスに準拠するエントリは、そのオブジェクト
クラスによって制約される現実世界のオブジェクトを表す。
- DIT 構造規則は、構造型オブジェクトクラスだけを参照する。エントリ
の構造型オブジェクトクラスは、DIT 内でのエントリの位置を指定する
ために使用される。
- エントリの構造型オブジェクトクラスは、関連付けられた DIT 内容
規則とともに、エントリの内容を制御するために使用される。
エントリの構造型オブジェクトクラスを変更してはならない。
各構造型オブジェクトクラスは、抽象オブジェクトクラス 'top' の直接または 間接のサブクラスである。
構造型オブジェクトクラスは、補助オブジェクトクラスをサブクラス化できない。
各エントリは、その構造型オブジェクトクラス、およびその構造型オブジェクト クラスのスーパークラスチェーンに含まれるすべてのクラスに属するとされる。
2.4.3. 補助オブジェクトクラス
補助オブジェクトクラスは、エントリの特性を拡張するために使用される。 通常は、エントリに存在することが必須または許可される属性の集合を拡張 するために使用される。エントリまたはエントリのクラスを記述するために 使用できる。
補助オブジェクトクラスは、構造型オブジェクトクラスをサブクラス化できない。
エントリは、そのエントリの構造型オブジェクトクラスに関連付けられた DIT 内容規則によって許可される補助オブジェクトクラス集合の任意の部分集合に 属することができる。エントリの構造型オブジェクトクラスに DIT 内容規則 が関連付けられていない場合、そのエントリはいずれの補助オブジェクト クラスにも属することができない。
エントリが属する補助オブジェクトクラスの集合は、時間の経過とともに変更 できる。 2.5. 属性記述
属性記述は、属性タイプ（2.5.1 節を参照）と、0 個以上の属性オプション （2.5.2 節を参照）の集合から構成される。
属性記述は、次の ABNF で表される。
attributedescription = attributetype options
attributetype = oid
options = *( SEMI option )
option = 1*keychar
ここで、
有効な属性記述の例を次に示す。
2.5.4.0
cn;lang-de;lang-en
owner
認識されない属性タイプを持つ属性記述は、認識されないものとして扱う。 サーバーは、認識されない属性オプションを持つ属性記述を、認識されない ものとして扱わなければならない（SHALL）。クライアントは、認識されない 属性オプションをタグ付けオプションとして扱ってもよい（MAY）（2.5.2.1 節を参照）。
1 つのエントリのすべての属性は、それぞれ異なる属性記述を持たなければ ならない。
2.5.1. 属性タイプ
属性タイプは、その属性が複数の値を持てるかどうか、その属性の値を構築 および比較するために使用する構文とマッチング規則、ならびにその他の 機能を規定する。
属性タイプに等価マッチングが指定されていない場合、次のようになる。
- そのタイプの属性を命名に使用することはできない。
- 属性を追加する場合（またはすべての値を置換する場合）、いずれの
2 つの値も等価であってはならない（2.2 節を参照）。
- 多値属性の個々の値を独立して追加または削除してはならない。
- そのようなタイプの値を使用する属性値アサーション（検索フィルター
におけるマッチングや比較など）を実行することはできない。
それ以外の場合、指定された等価マッチング規則を使用して、その属性 タイプに関する属性値アサーションを評価する。指定される等価規則は、 推移的かつ可換でなければならない。
属性タイプは、その属性がユーザー属性であるか運用属性であるかを示す。 運用属性の場合、属性タイプは運用上の用途と、その属性をユーザーが変更 できるかどうかも示す。運用属性については 3.4 節で説明する。
属性タイプ（サブタイプ）は、より汎用的な属性タイプ（直接スーパー タイプ）から派生できる。サブタイプ化には次の制約が適用される。
- サブタイプは、その直接スーパータイプと同じ用途を持たなければ
ならない。
- サブタイプの構文は、そのスーパータイプの構文と同じであるか、
その構文をより限定したものでなければならない。
- スーパータイプが集合属性（collective）である場合、サブタイプも
集合属性でなければならない [RFC3671]。
あるサブタイプのみで構成され、オプションを持たない属性記述は、その サブタイプの直接スーパータイプのみで構成され、オプションを持たない 属性記述の直接記述サブタイプ（direct description subtype）と呼ばれる。
各属性タイプは、オブジェクト識別子（OID）によって識別され、必要に 応じて 1 つ以上の短い名前（記述子）によっても識別される。
2.5.2. 属性オプション
属性記述オプションには複数の種類がある。LDAP 技術仕様では、そのうち 1 種類であるタグ付けオプションについて詳述する。
すべてのオプションを、ディレクトリに保持されている属性に関連付けられる わけではない。タグ付けオプションは関連付けることができる。
すべてのオプションをすべての属性タイプと組み合わせて使用できるわけ ではない。その場合、属性記述は認識されないものとして扱う。
相互排他的なオプションを含む属性記述は、認識されないものとして扱う。 すなわち、"x-foo" と "x-bar" が相互排他的である場合、 "cn;x-bar;x-foo" は認識されないものとして扱う。
将来の文書で、別の種類のオプションが規定される可能性がある。それらの 文書では、定義する新しい種類のオプションとタグ付けオプションとの関係を 詳述しなければならない。特に、新しい種類のオプションをディレクトリに 保持されている属性に関連付けられるかどうか、属性値の転送にどのような 影響を与えるか、および属性記述階層でどのように扱うかを詳述しなければ ならない。
オプションは、本文書の 2.5 節で定義される
オプションの登録手順については、BCP 64、RFC 4520 [RFC4520] に詳述 されている。
2.5.2.1. タグ付けオプション
ディレクトリに保持されている属性は、任意の個数のタグ付けオプションを 持つ属性記述を使用できる。タグ付けオプションが相互排他的になることは ない。
N 個のタグ付けオプションを持つ属性記述は、同じ属性タイプを持ち、N 個 のオプションのうち 1 つだけを除いたすべてのオプションを持つ各属性記述 の直接（記述）サブタイプである。属性タイプにスーパータイプがある場合、 その属性記述は、スーパータイプと N 個のタグ付けオプションからなる属性 記述の直接（記述）サブタイプでもある。すなわち、 'cn;lang-de;lang-en' は 'cn;lang-de'、'cn;lang-en'、および 'name;lang-de;lang-en' の直接（記述）サブタイプである（'cn' は 'name' のサブタイプであり、両方とも [RFC4519] で定義されている）。
2.5.3. 属性記述階層
属性タイプのサブタイプ化（2.5.1 節で説明）または属性タグ付けオプション のサブタイプ化（2.5.2.1 節で説明）によって示されるとおり、属性記述は 0 個以上の他の属性記述の直接サブタイプになり得る。これらのサブタイプ 関係は、属性記述および属性の階層を形成するために使用される。
[X.501] を基にすると、次のようになる。
属性階層は、さまざまな粒度で DIB にアクセスできるようにする。これは、
属性の値成分に、その固有の属性記述（属性への直接参照）またはより
汎用的な属性記述（間接参照）のいずれかを使用してアクセスできるように
することで実現される。
意味的に関連する属性を階層関係に配置し、より特殊化されたものを、より
一般化されたものの下位に置くことができる。より一般化された属性記述を
指定すれば、属性とその値を容易に検索または取得できる。このように指定
されたフィルター項目は、指定された記述だけでなく、より特殊化された
記述についても評価される。
下位の特殊化された記述を検索結果の一部として返すよう選択した場合、
利用可能であればそれらの記述を返す。より一般的な記述を検索結果の一部
として返すよう選択した場合、利用可能であれば一般的な記述と特殊化され
た記述の両方を返す。属性値は、常にそれ自身の属性記述の値として返す。
ユーザーがエントリの内容を変更する場合、属性階層内のすべての属性記述
は、互いに異なり、関連のない記述として扱われる。
オブジェクトエントリまたは別名エントリに格納された属性値は、厳密に
1 つの属性記述に属する。その値をエントリに最初に追加するときに、
その記述が示される。
エントリのサブスキーマ管理において、属性が必須であるという指定は、 エントリに、属性階層に属する属性記述の値が含まれ、その記述の属性タイプ が必須属性のタイプと同じであれば満たされる。すなわち、"MUST name" の 指定は 'name' または 'name;x-tag-option' によって満たされるが、'CN' または 'CN;x-tag-option' によっては満たされない（'CN' が 'name' の サブタイプであっても同様である）。同様に、エントリには、属性階層に属する 属性記述の値を含めることができる。ただし、その記述の属性タイプが、 エントリの属するオブジェクトクラスの定義に明示的に含まれているか、 そのエントリに適用される DIT 内容規則によって許可されていなければなら ない。すなわち、"MAY name"（または "MUST name"）では 'name' と 'name;x-tag-option' が許可されるが、'CN' と 'CN;x-tag-option' は "MAY name"（または "MUST name"）では許可されない。
その他のポリシー管理については、個々の管理モデルの仕様に別段の規定が ない限り、属性階層内のすべての属性記述は、互いに異なり、関連のない記述 として扱われる。
2.6. 別名エントリ
[X.501] を基にすると、次のようになる。
オブジェクトの別名、すなわち別名名称とは、別名エントリを使用して
オブジェクトまたはオブジェクトエントリに与えられる代替名称である。
各別名エントリは、'aliasedObjectName' 属性（X.500 では
'aliasedEntryName' 属性として知られる）に、あるオブジェクトの名称を
含む。したがって、別名エントリの識別名も、そのオブジェクトの名称に
なる。
注 - 'aliasedObjectName' 内の名称は、別名が指している名称と
呼ばれる。この名称は、いずれかのエントリの識別名である
必要はない。
別名名称をオブジェクト名称に変換することを（別名）参照解除と呼ぶ。
これは、想定された名称の中に別名名称が見つかった場合に、それを対応
する 'aliasedObjectName' 属性の値で体系的に置換する処理である。
この処理では、複数の別名エントリを調べる必要が生じる場合がある。
DIT 内の個々のエントリには、0 個以上の別名名称を設定できる。したがって、
複数の別名エントリが同じエントリを指すことがある。別名エントリは、
リーフでないエントリを指すことも、別の別名エントリを指すこともできる。
別名エントリは下位エントリを持ってはならないため、常にリーフエントリ
となる。
すべての別名エントリは、'alias' オブジェクトクラスに属さなければ
ならない。
'alias' オブジェクトクラスを持つエントリは、適切な命名属性の存在を許可 する 1 つ以上のオブジェクトクラスにも属するか、またはその存在を許可する DIT 内容規則によって管理されなければならない。
例：
dn: cn=bar,dc=example,dc=com
objectClass: top
objectClass: alias
objectClass: extensibleObject
cn: bar
aliasedObjectName: cn=foo,dc=example,dc=com
2.6.1. 'alias' オブジェクトクラス
別名エントリは、'alias' オブジェクトクラスに属する。
( 2.5.6.1 NAME 'alias'
SUP top STRUCTURAL
MUST aliasedObjectName )
2.6.2. 'aliasedObjectName' 属性タイプ
'aliasedObjectName' 属性は、別名が指すエントリの名称を保持する。 'aliasedObjectName' 属性は、X.500 では 'aliasedEntryName' 属性として 知られている。
( 2.5.4.1 NAME 'aliasedObjectName'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE )
'distinguishedNameMatch' マッチング規則と DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) 構文は [RFC4517] で定義されている。 3. ディレクトリの管理情報および運用情報
本節では、X.500 ディレクトリの管理情報および運用情報モデル [X.501] から、いくつかの側面を取り上げる。LDAP 実装は、このモデルのその他の 側面をサポートしてもよい (MAY)。
3.1. サブツリー
[X.501] では次のように定義されている。
サブツリー (subtree) は、木の頂点に位置するオブジェクトエントリと
エイリアスエントリの集合である。サブツリーはサブエントリを含まない。
subtree の接頭辞 sub は、この木の基底 (または根) 頂点が通常 DIT の
根より下位にあることを強調している。
サブツリーは、ある頂点から始まり、識別可能な下側境界まで、場合に
よっては葉まで延びる。サブツリーは常に、その境界を暗黙に定める
コンテキスト内で定義される。たとえば、複製領域を定義するサブツリー
の頂点と下側境界は、命名コンテキストによって限定される。
3.2. サブエントリ
サブエントリは、「ディレクトリが認識する特殊な種類のエントリであり、 サブツリーまたはサブツリーの詳細化に関連付けられた情報を保持するため に使用される」[X.501]。サブエントリは、[X.501] で定義された管理上および 運用上の目的で情報を保持するためにディレクトリで使用される。LDAP での 使用法は [RFC3672] に詳述されている。
本仕様の用語「(sub)entry」は、X.500(93) モデルを実装するサーバーは、 [RFC3672] に記載された X.500(93) に従ってサブエントリを使用し、その他 のサーバーは、通常そのサブエントリとともに使用される適切な補助クラス に属するオブジェクトエントリ (たとえば、サブスキーマサブエントリには 'subschema') を使用してサブエントリを模倣することを示す。この オブジェクトエントリの RDN は、'cn' (commonName) 属性 [RFC4519] の値 から構成しなければならない (SHALL)。すべてのサブエントリが 'cn' で 命名されるためである。
3.3. 'objectClass' 属性
DIT 内の各エントリは 'objectClass' 属性を持つ。
( 2.5.4.0 NAME 'objectClass'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
'objectIdentifierMatch' マッチング規則および OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) 構文は [RFC4517] で定義されている。
'objectClass' 属性はエントリのオブジェクトクラスを指定する。これらは、 特に制御スキーマと組み合わせて、エントリで許可される属性を決定する ために使用される。この属性の値はクライアントが変更できるが、 'objectClass' 属性そのものは削除できない。
X.500(93) モデルに従うサーバーは、エントリの基本構造クラスが変更され ないよう、この属性の変更を制限しなければならない (SHALL)。すなわち、 'person' を 'country' に変更することはできない。
エントリを作成するとき、または 'objectClass' 値を追加するとき、指定 されたクラスの全スーパークラスがまだ存在しなければ、それらも暗黙に 追加しなければならない (SHALL)。つまり、補助クラス 'x-a' がクラス 'x-b' のサブクラスなら、'objectClass' に 'x-a' を追加すると、まだ存在 しない場合は 'x-b' も暗黙に追加される。
サーバーは、残る 'objectClass' 値のスーパークラスが削除されないよう、 この属性の変更を制限しなければならない (SHALL)。補助クラス 'x-a' が 補助クラス 'x-b' のサブクラスで、'objectClass' に 'x-a' と 'x-b' が 含まれる場合、'x-b' だけを削除しようとするとエラーになる。
3.4. 運用属性
運用属性と呼ばれる一部の属性は、管理上および運用上の目的でサーバーが 使用または維持する。[X.501] の記述によれば、「運用属性には、ディレクトリ 運用属性、DSA 共有運用属性、DSA 固有運用属性の 3 種類がある」。
ディレクトリ運用属性は、ディレクトリ情報モデルの運用情報および／または 管理情報を表す。サーバーが維持する運用属性 (例: 'createTimestamp') と、 利用者が管理する値を保持する運用属性 (例: 'ditContentRules') が含まれる。
DSA 共有運用属性は、DSA 間で共有される DSA 情報モデルの情報を表す。
DSA 固有運用属性は、その DSA に固有の DSA 情報モデル情報を表す (ただし、DSA 間で共有される情報から導出される場合もある。例: 'namingContexts')。
DSA 情報モデルの運用属性は [X.501] に詳述されている。
運用属性は通常は表示されず、名前で明示的に要求しない限り検索結果に 返されない。
すべての運用属性を利用者が変更できるわけではない。
エントリには、特に次の運用属性を含めることができる。
- creatorsName: このエントリをディレクトリに追加した利用者の識別名。
- createTimestamp: このエントリがディレクトリに追加された時刻。
- modifiersName: このエントリを最後に変更した利用者の識別名。
- modifyTimestamp: このエントリが最後に変更された時刻。
サーバーは、DIT の全エントリについて 'creatorsName'、'createTimestamp'、 'modifiersName'、'modifyTimestamp' 属性を維持することが望ましい (SHOULD)。
3.4.1. 'creatorsName'
この属性は、プロトコルを使用して追加されたエントリ (例: 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 )
'distinguishedNameMatch' マッチング規則および DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) 構文は [RFC4517] で定義されている。
3.4.2. 'createTimestamp'
この属性は、プロトコルを使用して追加されたエントリ (例: 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 )
'generalizedTimeMatch'、'generalizedTimeOrderingMatch' マッチング規則と GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) 構文は [RFC4517] で 定義されている。
3.4.3. 'modifiersName'
この属性は、プロトコルを使用して変更されたエントリ (例: Modify 操作を 使用) に現れる。値は最後の変更者の識別名である。
( 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 )
'distinguishedNameMatch' マッチング規則および DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) 構文は [RFC4517] で定義されている。
3.4.4. 'modifyTimestamp'
この属性は、プロトコルを使用して変更されたエントリ (例: Modify 操作を 使用) に現れる。値はエントリが最後に変更された時刻である。
( 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 )
'generalizedTimeMatch'、'generalizedTimeOrderingMatch' マッチング規則と GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) 構文は [RFC4517] で 定義されている。
3.4.5. 'structuralObjectClass'
この属性は、エントリの構造型オブジェクトクラスを示す。
( 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 )
'objectIdentifierMatch' マッチング規則および OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) 構文は [RFC4517] で定義されている。
3.4.6. 'governingStructureRule'
この属性は、エントリを規定する構造規則を示す。
( 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 )
'integerMatch' マッチング規則および INTEGER (1.3.6.1.4.1.1466.115.121.1.27) 構文は [RFC4517] で定義されている。 4. ディレクトリスキーマ
[X.501] では、次のように定義されている。
ディレクトリスキーマとは、DIT の構造、エントリに可能な命名方法、
エントリに保持できる情報、その情報を表すために使用される属性、
情報の検索と取得を容易にするためのそれらの階層編成、ならびに属性値
アサーションおよびマッチング規則アサーションにおいて属性値を照合する
方法に関する定義と制約の集合である。
注記 1 - スキーマにより、ディレクトリシステムは、たとえば次のことを
行える。
- 不適切なオブジェクトクラスの下位エントリ (たとえば、人の下位に
国を置くこと) が作成されるのを防ぐ。
- オブジェクトクラスに不適切な属性タイプ (たとえば、人のエントリに
シリアル番号を付加すること) がエントリに追加されるのを防ぐ。
- 属性タイプに定義された構文と一致しない構文の属性値 (たとえば、
ビット列に印字可能文字列を追加すること) が追加されるのを防ぐ。
形式的には、ディレクトリスキーマは次の定義の集合から構成される。
a) 構造型オブジェクトクラスの基本的な命名関係を定義する名前形式定義。
b) エントリが持つことのできる名前、および DIT 内でエントリを相互に
関連付ける方法を定義する DIT 構造規則定義。
c) エントリの構造型オブジェクトクラスによって示される範囲を超えて、
エントリに許容される属性の仕様を拡張する DIT 内容規則定義。
d) 特定のクラスのエントリにそれぞれ存在しなければならない必須属性と、
存在してもよい任意属性の基本集合を定義し、定義対象のオブジェクト
クラスの種類を示すオブジェクトクラス定義。
e) 属性を識別するオブジェクト識別子、その構文、関連するマッチング規則、
運用属性であるかどうかと、そうである場合の種類、集合属性であるか
どうか、複数の値を持つことが許可されるかどうか、および別の属性
タイプから派生したものかどうかを識別する属性タイプ定義。
f) マッチング規則を定義するマッチング規則定義。
LDAP では、さらに次が含まれる。
g) LDAP で使用される符号化を定義する LDAP 構文定義。
4.1. スキーマ定義
本節のスキーマ定義は ABNF を使用して記述され、第 1.2 節で規定した 共通生成規則に加えて次の生成規則に依存する。
noidlen = numericoid [ 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
; Any ASCII character except %x27 ("\'") and %x5C ("\")
QUTF1 = %x00-26 / %x28-5B / %x5D-7F
本節のスキーマ定義では、多くの共通用語も共有される。
NAME フィールドは、OID の別名として使用する短い名前 (記述子) の集合を 提供する。
DESC フィールドでは、ディレクトリ管理者および／または実装者が説明文字列を 任意に指定できる。仕様が説明文字列を提案することはできるが、提案された 説明文字列 (または何らかの説明文字列) を使用する必要はない。
OBSOLETE フィールドが存在する場合、その要素が有効でないことを示す。
実装者は、本文書の将来の版でこれらの定義が拡張され、追加の用語が含まれる
可能性があることに留意すべきである。識別子が "X-" で始まる用語は私的な
実験用に予約されており、その後に
4.1.1. オブジェクトクラス定義
オブジェクトクラス定義は、次の 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"
ここで、
4.1.2. 属性タイプ
属性タイプ定義は、次の 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
ここで、
各属性タイプ記述には、SUP または SYNTAX フィールドの少なくとも一方を 含めなければならない。SYNTAX フィールドが指定されていない場合、属性 タイプ記述はその値を上位タイプから継承する。
SUP フィールドが指定されている場合、EQUALITY、ORDERING、および SUBSTRING フィールドは、指定されていなければ上位タイプの値を継承する。
デフォルトである userApplications の用途は、このタイプの属性が利用者 情報を表すことを示す。すなわち、これらは利用者属性である。
directoryOperation、distributedOperation、または dSAOperation の用途は、 このタイプの属性が運用情報および／または管理情報を表すことを示す。 すなわち、これらは運用属性である。
directoryOperation の用途は、このタイプの属性がディレクトリ運用属性で あることを示す。distributedOperation の用途は、このタイプの属性が DSA 共有用途の運用属性であることを示す。dSAOperation の用途は、この タイプの属性が DSA 固有の運用属性であることを示す。
COLLECTIVE には userApplications の用途が必要である。LDAP における 集合属性タイプの使用については、[RFC3671] で論じられている。
NO-USER-MODIFICATION には運用用途が必要である。
本文書では、
文字列ベースの構文を持つ値の文字数、またはその他すべての構文を持つ値の バイト数について、推奨される最小上限を示すことができる。この上限は、 属性タイプ記述において、構文の OBJECT IDENTIFIER の後に中括弧で囲んだ 上限値を付加することで示す。この上限は構文名自体の一部ではない。たとえば、 "1.3.6.4.1.1466.0{64}" は、サーバー実装が 64 文字の長さの文字列を許容 すべきであることを示唆するが、より長い文字列を許容してもよい。UTF-8 [RFC3629] は可変長符号化であるため、Directory String 構文の 1 文字が 複数のオクテットで符号化される場合があることに注意されたい。
4.1.3. マッチング規則
マッチング規則は、Compare 操作の実行時など、属性値アサーションを実行する 際に使用される。また、検索フィルタの評価、Modify 操作の実行中に追加または 削除する個々の値の決定、および識別名の比較にも使用される。
各マッチング規則は、オブジェクト識別子 (OID) と、任意で 1 つ以上の 短い名前 (記述子) によって識別される。
マッチング規則定義は、次の 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
ここで、
マッチング規則の使用は、extensibleMatch 検索フィルターとの使用に適した 属性タイプを列挙する。
マッチング規則使用記述は、次の 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
ここで、
4.1.5. LDAP 構文
（属性値およびアサーション値の）LDAP 構文は ASN.1 [X.680] を用いて 記述され、必要に応じて LDAP 固有の符号化として知られるオクテット文字列 符号化を持つ。一般に、LDAP 固有の符号化は UTF-8 [RFC3629] 形式の Unicode [Unicode] 文字列に制約される。
各 LDAP 構文は、オブジェクト識別子（OID）によって識別される。
LDAP 構文定義は、次の ABNF に従って記述される。
SyntaxDescription = LPAREN WSP
numericoid ; object identifier
[ SP "DESC" SP qdstring ] ; description
extensions WSP RPAREN ; extensions
ここで、
4.1.6. DIT 内容規則
DIT 内容規則は、「特定の構造型オブジェクトクラスのエントリ内容を管理 する規則」である [X.501]。
特定の構造型オブジェクトクラスに属する DIT エントリについて、DIT 内容 規則は、エントリが属することを許される補助オブジェクトクラスと、エントリ 内に必要、許可、または禁止される追加属性（タイプ別）を規定する。
禁止属性のリストには、その規則、構造型オブジェクトクラス、または許可 された補助オブジェクトクラスのいずれかで必須として列挙された属性を含める ことはできない。
各内容規則は、適用対象となる構造型オブジェクトクラスのオブジェクト 識別子と、存在する場合は短い名前（記述子）によって識別される。
エントリは、適用される内容規則に列挙された補助オブジェクトクラスにのみ 属することができる。
エントリには、そのエントリが属するオブジェクトクラスで必須とされるすべて の属性と、適用される内容規則で必須とされるすべての属性が含まれなければ ならない。
エントリには、そのエントリが属するオブジェクトクラスによって許可され、 かつ禁止されていない任意の属性と、適用される内容規則によって許可される すべての属性を含めることができる。
エントリには、適用される内容規則によって禁止される属性を含めることは できない。
エントリには、そのエントリの構造型オブジェクトクラスに適用される DIT 内容規則が適用される（その規則が存在し、サブスキーマ内で有効な場合。 2.4.2 節を参照）。そのエントリの構造型オブジェクトクラスに有効な規則が 存在しない場合、エントリの内容は構造型オブジェクトクラス（場合によっては ユーザースキーマおよびシステムスキーマの他の側面）によって管理される。 エントリの構造型オブジェクトクラスのスーパークラスに対する DIT 内容規則 は、そのエントリには適用されない。
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
ここで、
MUST、MAY、および NOT は、この DIT 内容規則の対象となるエントリに
おいて、それぞれ必須、許可、および禁止される属性タイプのリストを
指定する。
<extensions> は、拡張を記述する。
4.1.7. DIT 構造規則と名前形式
オブジェクトエントリと別名エントリを DIT 内のどこに配置できるか、および それらを構造型オブジェクトクラスに基づいてどのように命名できるかを規制 することが望ましい場合がある。
4.1.7.1. DIT 構造規則
DIT 構造規則は、「許可される上位エントリと下位エントリの関係を指定する ことにより、DIT の構造を管理する規則である。構造規則は名前形式、した がって構造型オブジェクトクラスを上位構造規則に関連付ける。これにより、 名前形式で識別される構造型オブジェクトクラスのエントリは、指定された 上位構造規則の適用を受けるエントリの下位として DIT 内に存在できる」 [X.501]。
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
ここで、
上位規則が識別されない場合、DIT 構造規則は自律管理点（たとえば、 サブスキーマによって制御されるサブツリーのルート頂点）に適用される [X.501]。
4.1.7.2. 名前形式
名前形式は、「特定の構造型オブジェクトクラスのエントリに許可される RDN を指定する。名前形式は、命名対象のオブジェクトクラスと、命名（すなわち RDN）に使用する 1 つ以上の属性タイプを識別する。名前形式は、DIT 構造 規則の定義で使用される基本的な仕様要素である」[X.501]。
各名前形式は、命名対象の構造型オブジェクトクラス、必須属性タイプの集合、 および許可属性タイプの集合を示す。特定の属性タイプが両方の集合に含まれる ことはできない。
その形式の適用を受けるエントリは、各必須属性タイプの値と、許可属性タイプ の 0 個以上の値を使用して命名されなければならない。
各名前形式は、オブジェクト識別子（OID）と、必要に応じて 1 つ以上の短い 名前（記述子）によって識別される。
名前形式記述は、次の 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
ここで、
必須（"MUST"）リストと許可（"MAY"）リストに含まれるすべての属性タイプ は、それぞれ異なっていなければならない。
4.2. サブスキーマサブエントリ
サブスキーマサブエントリは、ディレクトリスキーマに関する情報を管理 するために使用される。1 つのサブスキーマサブエントリには、 ディレクトリツリーの特定部分にあるエントリが使用するすべてのスキーマ定義 （4.1 節を参照）が含まれる。
X.500(93) モデルに従うサーバーは、X.500 サブスキーマ機構（[X.501] の 12 節に詳述）を使用してサブスキーマを実装するべきである（SHOULD）。 したがって、これらは通常のオブジェクトエントリではなく、サブエントリ である（3.2 節を参照）。LDAP クライアントは、サーバーが X.500 サブスキーマのその他の側面を実装していると仮定するべきではない （SHOULD NOT）。
サーバーは、サブスキーマの変更を許可してもよい（MAY）。サブスキーマを 変更する手順については、[X.501] の 14.5 節で説明されている。
エントリをマスターし、クライアントによるそのエントリの変更を許可する サーバーは、変更可能な各エントリに 'subschemaSubentry' 属性を提供する ことを含め、これらのサブスキーマサブエントリを実装してアクセスを 提供しなければならない（SHALL）。これにより、クライアントは存在を許可 される属性とオブジェクトクラスを検出できる。その他のすべてのサーバーも これを実装することが強く推奨される（RECOMMENDED）。
'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 )
'distinguishedNameMatch' マッチング規則と DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) 構文は [RFC4517] で定義されている。
サブスキーマは、subschema 補助オブジェクトクラスに属する（サブ）エントリ に保持される。
( 2.5.20.1 NAME 'subschema' AUXILIARY
MAY ( dITStructureRules $ nameForms $ ditContentRules $
objectClasses $ attributeTypes $ matchingRules $
matchingRuleUse ) )
'ldapSyntaxes' 運用属性もサブスキーマエントリに存在できる。
サーバーは、サブスキーマサブエントリに（他の文書で記述される）追加 属性を提供してもよい（MAY）。
クライアントがスキーマ情報のキャッシュを維持できるよう、サーバーは サブスキーマサブエントリに 'createTimestamp' 属性と 'modifyTimestamp' 属性を提供するべきである（SHOULD）。
以下の各項では、それぞれのスキーマ定義属性タイプについて属性タイプ定義 を示す。 4.2.1. 'objectClasses'
この属性はオブジェクトクラスの定義を保持する。
( 2.5.21.6 NAME 'objectClasses'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.37
USAGE directoryOperation )
'objectIdentifierFirstComponentMatch' マッチング規則および ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) 構文は [RFC4517] で定義されている。
4.2.2. 'attributeTypes'
この属性は属性タイプの定義を保持する。
( 2.5.21.5 NAME 'attributeTypes'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.3
USAGE directoryOperation )
'objectIdentifierFirstComponentMatch' マッチング規則および AttributeTypeDescription (1.3.6.1.4.1.1466.115.121.1.3) 構文は [RFC4517] で定義されている。
4.2.3. 'matchingRules'
この属性はマッチング規則の定義を保持する。
( 2.5.21.4 NAME 'matchingRules'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.30
USAGE directoryOperation )
'objectIdentifierFirstComponentMatch' マッチング規則および MatchingRuleDescription (1.3.6.1.4.1.1466.115.121.1.30) 構文は [RFC4517] で定義されている。
4.2.4 'matchingRuleUse'
この属性はマッチング規則の使用の定義を保持する。
( 2.5.21.8 NAME 'matchingRuleUse'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.31
USAGE directoryOperation )
'objectIdentifierFirstComponentMatch' マッチング規則および MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) 構文は [RFC4517] で定義されている。
4.2.5. 'ldapSyntaxes'
この属性は 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 )
'objectIdentifierFirstComponentMatch' マッチング規則および SyntaxDescription (1.3.6.1.4.1.1466.115.121.1.54) 構文は [RFC4517] で定義されている。
4.2.6. 'dITContentRules'
この属性は、サブスキーマに存在する DIT 内容規則を列挙する。
( 2.5.21.2 NAME 'dITContentRules'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.16
USAGE directoryOperation )
'objectIdentifierFirstComponentMatch' マッチング規則および DITContentRuleDescription (1.3.6.1.4.1.1466.115.121.1.16) 構文は [RFC4517] で定義されている。
4.2.7. 'dITStructureRules'
この属性は、サブスキーマに存在する DIT 構造規則を列挙する。
( 2.5.21.1 NAME 'dITStructureRules'
EQUALITY integerFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.17
USAGE directoryOperation )
'integerFirstComponentMatch' マッチング規則および DITStructureRuleDescription (1.3.6.1.4.1.1466.115.121.1.17) 構文は [RFC4517] で定義されている。
4.2.8 'nameForms'
この属性は、有効な名前形式を列挙する。
( 2.5.21.7 NAME 'nameForms'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.35
USAGE directoryOperation )
'objectIdentifierFirstComponentMatch' マッチング規則および NameFormDescription (1.3.6.1.4.1.1466.115.121.1.35) 構文は [RFC4517] で定義されている。
4.3. 'extensibleObject' オブジェクトクラス
'extensibleObject' 補助オブジェクトクラスは、それに属するエントリが任意の利用者属性を保持することを許可する。このオブジェクトクラスで許可される属性タイプの集合は、暗黙に userApplications 用途の全属性タイプの集合となる。
( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
SUP top AUXILIARY )
このエントリの他のオブジェクトクラスで必須の属性は引き続き存在しなければならず、禁止された属性は引き続き存在してはならない。
4.4. サブスキーマの発見
特定のエントリを制御するサブスキーマを保持するサブスキーマサブエントリ の DN を検出するには、そのエントリの 'subschemaSubentry' 運用属性を読み取る。そこからスキーマ属性を読むには、クライアントは Search 操作 [RFC4511] を発行しなければならない (MUST)。baseObject はサブスキーマサブエントリ の DN、scope は baseObject、filter は "(objectClass=subschema)" [RFC4515] とし、attributes フィールドに必要なスキーマ属性名を列挙する。注: "(objectClass=subschema)" フィルターにより、X.500 へのゲートウェイとなる LDAP サーバーはサブエントリ情報の要求を検出できる。
クライアントは、公開サブスキーマが完全であること、サーバーが公開した全スキーマ要素をサポートすること、または非公開要素をサポートしないことを仮定すべきではない (SHOULD NOT)。
- DSA (サーバー) 情報モデル
LDAP プロトコルは、1 台以上のサーバーが共同で DIT へのアクセスを提供すると仮定する。元の情報を保持するサーバーを、その情報の「マスター (master)」と呼ぶ。コピーを保持するサーバーを「シャドウイング (shadowing)」または「キャッシュ (caching)」サーバーと呼ぶ。
[X.501] の定義は次のとおりである。
コンテキスト接頭辞 (context prefix): DIT の根から命名コンテキストの初期頂点までの RDN 列。その頂点の識別名に対応する。
命名コンテキスト (naming context): 単一のマスター DSA に保持されるエントリのサブツリー。
つまり命名コンテキストは、特定サーバーがマスターであるエントリから始まり、別サーバーがマスターであるエントリに至るまで、その全下位とさらにその下位を含む最大のエントリ集合である。コンテキスト接頭辞は初期エントリの名前である。
DIT の根は DSA 固有エントリ (DSA-specific Entry、DSE) であり、どの命名コンテキスト (またはサブツリー) にも属さない。各サーバーのルート DSE は異なる属性値を持つ。
5.1. サーバー固有データの要件
LDAP サーバーは、自身に関する情報と各サーバー固有のその他の情報を提供しなければならない (SHALL)。これは、0 個の RDN を持つ DN ([RFC4514] での表現は長さ 0 の文字列) で命名されたルート DSE 内の属性群として表される。
クライアントが、空の baseObject、baseObject の scope、filter "(objectClass=*)" [RFC4515]、必要な属性名を列挙した attributes フィールドで Search 操作 [RFC4511] を実行すれば、アクセス制御などの制限下で取得できる。ルート DSE 属性は運用属性であり、名前で要求しない限り検索要求で返されない。
クライアントがルートからサブツリー検索を行う場合、ルート DSE を含めてはならない (SHALL NOT)。
サーバーは、適切な場合にクライアントによるルート DSE 属性の変更を許可できる。
ルート DSE の次の属性を以下で定義する。他の文書で追加属性を定義できる。
- altServer: 代替サーバー。
- namingContexts: 命名コンテキスト。
- supportedControl: 認識される LDAP コントロール。
- supportedExtension: 認識される LDAP 拡張操作。
- supportedFeatures: 認識される LDAP 機能。
- supportedLDAPVersion: サポートされる LDAP バージョン。
- supportedSASLMechanisms: 認識される Simple Authentication and Security Layers (SASL) [RFC4422] メカニズム。
これらの値は、セッション固有要因などに依存し得る。たとえば SASL EXTERNAL をサポートするサーバーは、下位層でクライアントの身元が確立された場合にのみ "EXTERNAL" を列挙することがある。[RFC4513] を参照。
ルート DSE は 'subschemaSubentry' 属性を含むこともできる。その場合、ルート DSE を制御するスキーマを保持するサブスキーマサブエントリ を参照する。クライアントは、このサブスキーマサブエントリ がサーバー上の他のエントリも制御すると仮定すべきではない (SHOULD NOT)。一般的な検出手順は 4.4 節に示す。 5.1.1. 'altServer'
'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 )
IA5String (1.3.6.1.4.1.1466.115.121.1.26) 構文は [RFC4517] で定義 されている。
5.1.2. 'namingContexts'
'namingContexts' 属性は、サーバーがマスターまたはシャドウとして保持する （一部または全部の）名前付けコンテキストのコンテキスト接頭辞を列挙する。 サーバーが第 1 レベルの DSA [X.501] である場合は、さらに空文字列（DIT のルートを示す）も列挙するべきである。サーバーが情報をマスターとしても シャドウとしても保持しない場合（たとえば、公開 X.500 ディレクトリへの LDAP ゲートウェイである場合）、この属性は存在しない。サーバーが ディレクトリ全体をマスターまたはシャドウとして保持していると判断して いる場合、この属性は 1 つの値だけを持ち、その値は空文字列（DIT のルート を示す）となる。
この属性は、たとえば、このサーバーを使用する後続操作に適したエントリ名を 選択するために使用できる。
( 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 )
DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) 構文は [RFC4517] で定義されている。
5.1.3. 'supportedControl'
'supportedControl' 属性は、サーバーがサポートする要求制御 [RFC4511] を 識別するオブジェクト識別子を列挙する。サーバーが要求制御をサポートして いない場合、この属性は存在しない。応答制御を識別するオブジェクト識別子 は列挙する必要がない。
プロトコル機構の検出に使用されるオブジェクト識別子の登録手順については、 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 )
OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) 構文は [RFC4517] で定義されている。
5.1.4. 'supportedExtension'
'supportedExtension' 属性は、サーバーがサポートする拡張操作 [RFC4511] を識別するオブジェクト識別子を列挙する。サーバーが拡張操作をサポートして いない場合、この属性は存在しない。
拡張操作は通常、拡張要求と拡張応答から構成されるが、他のプロトコルデータ 単位（中間応答など）が含まれる場合もある。拡張要求に割り当てられた オブジェクト識別子が、拡張操作の識別に使用される。拡張操作で使用される その他のオブジェクト識別子を、この属性の値として列挙する必要はない。
プロトコル機構の検出に使用されるオブジェクト識別子の登録手順については、 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 )
OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) 構文は [RFC4517] で定義されている。
5.1.5. 'supportedFeatures'
'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 )
プロトコル機構の検出に使用されるオブジェクト識別子の登録手順については、 BCP 64、RFC 4520 [RFC4520] に詳述されている。
OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) 構文および objectIdentifierMatch マッチング規則は [RFC4517] で定義されている。
5.1.6. 'supportedLDAPVersion'
'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 )
INTEGER (1.3.6.1.4.1.1466.115.121.1.27) 構文は [RFC4517] で定義 されている。
5.1.7. 'supportedSASLMechanisms'
'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 )
Directory String (1.3.6.1.4.1.1466.115.121.1.15) 構文は [RFC4517] で定義されている。
- その他の考慮事項
6.1. ユーザー情報の保存
特定の値および／または値形式（表現形式）の保存要件を持つ構文を定義できる。 たとえば、デジタル署名されたデータを含む構文では、署名が無効にならない ように、提示された値と値形式の両方をサーバーが保存するよう義務付けること ができる。
このような要件が明示的に定められていない場合、サーバーはユーザー情報の 値を保存するべきである（SHOULD）が、異なる形式で値を返してもよい （MAY）。サーバーがユーザー情報の値を保存できない（または保存しない） 場合、サーバーは等価な値（2.3 節による）が返されることを保証しなければ ならない（SHALL）。
6.2. 短い名前
記述子とも呼ばれる短い名前は、オブジェクト識別子の読みやすい別名として 使用され、さまざまなスキーマ要素を識別するために使用される。ただし、 人間向けユーザーインターフェイスを持つ LDAP 実装が、このような短い名前 （またはそれが参照するオブジェクト識別子）をユーザーに表示することは想定 されていない。代わりに、何らかの変換（短い名前を地域のいずれかの言語で 表現するなど）を行う可能性が最も高い。たとえば、短い名前 "st" （stateOrProvinceName）は、ドイツ語を話すユーザーに "Land" と表示される ことがある。
同じ短い名前が異なるサブスキーマでは異なる意味を持つことがあり、特定の サブスキーマ内では、同じ短い名前が、それぞれ異なる種類のスキーマ要素を 識別する異なるオブジェクト識別子を参照することがある。
実装は、同じ短い名前が 1 つのサブスキーマ内で異なる種類のスキーマ要素を 参照するために使用される場合に備えなければならない（MUST）。すなわち、 1 つのサブスキーマ内にオブジェクトクラス 'x-fubar' と属性タイプ 'x-fubar' が存在する場合がある。
実装は、同じ短い名前が異なるサブスキーマ内で異なるスキーマ要素を参照する ために使用される場合に備えなければならない（MUST）。すなわち、それぞれ 異なるサブスキーマ内に 2 つのマッチング規則 'x-fubar' が存在する場合が ある。
短い名前（記述子）の登録手順については、BCP 64、RFC 4520 [RFC4520] に詳述されている。
6.3. キャッシュとシャドウイング
一部のサーバーはエントリのキャッシュコピーまたはシャドウコピーを保持し、 それを検索および比較照会への応答に使用できるが、変更操作が要求された場合 は参照を返すか、他のサーバーに接続する。シャドウイングまたはキャッシュを 行うサーバーは、発信元サーバーがデータに設定したアクセス制御上の制約に 違反しないことを保証しなければならない（MUST）。
- 実装ガイドライン
7.1. サーバー向けガイドライン
サーバーは、本文書で定義される属性タイプとオブジェクトクラスのすべての 名前を認識しなければならない（MUST）が、別段の規定がない限り、関連する 機能をサポートする必要はない。サーバーは、[RFC4519] の 3 節と 4 節で それぞれ定義される属性タイプとオブジェクトクラスのすべての名前を認識する べきである（SHOULD）。
サーバーは、エントリがユーザースキーマ規則、システムスキーマ規則、または その他のデータモデル制約に準拠することを保証しなければならない（MUST）。
サーバーは DIT 内容規則をサポートしてもよい（MAY）。サーバーは DIT 構造 規則と名前形式をサポートしてもよい（MAY）。
サーバーは別名エントリをサポートしてもよい（MAY）。
サーバーは 'extensibleObject' オブジェクトクラスをサポートしてもよい （MAY）。
サーバーはサブエントリをサポートしてもよい（MAY）。その場合、[RFC3672] に従ってサポートしなければならない（MUST）。サブエントリをサポートしない サーバーは、3.2 節の詳述に従い、オブジェクトエントリを使用してサブ エントリを模倣するべきである（SHOULD）。
サーバーは追加のスキーマ要素を実装してもよい（MAY）。サーバーは、 サポートするすべてのスキーマ要素の定義をサブスキーマサブエントリで 提供するべきである（SHOULD）。
7.2. クライアント向けガイドライン
サーバーとの事前の合意がない場合、クライアントは、7.1 節で参照される ものを超える特定のスキーマ要素をサーバーがサポートしていると仮定する べきではない（SHOULD NOT）。クライアントは、4.4 節の説明に従って サブスキーマ情報を取得できる。
値の構文が不明な場合、クライアントはその値を ASN.1 として表示したり デコードを試みたりしてはならない（MUST NOT）。そのような制限が明示されて いない限り、LDAP 固有の文字列符号化が Unicode 文字の UTF-8 符号化文字列 または Unicode の特定の部分集合（印字可能な部分集合など）に制限されると 仮定してはならない（MUST NOT）。クライアントは、属性に定義された構文に よれば無効な属性値を要求内で送信するべきではない（SHOULD NOT）。
- セキュリティに関する考慮事項
ディレクトリエントリの属性は、それが表す現実世界の対象に関する説明情報を 提供するために使用される。対象には、人、組織、または機器があり得る。 ほとんどの国には、人に関する情報の公開についてのプライバシー法がある。
LDAP を使用してディレクトリ情報にアクセスする際の一般的なセキュリティ上の 考慮事項については、[RFC4511] および [RFC4513] で論じられている。
- IANA に関する考慮事項
Internet Assigned Numbers Authority (IANA) は、次のテンプレートに示す とおり LDAP 記述子レジストリを更新した。
件名: LDAP 記述子登録更新要求
記述子 (短い名前): コメントを参照
オブジェクト識別子: コメントを参照
詳細情報の問い合わせ先および電子メールアドレス:
Kurt Zeilenga <[email protected]>
用途: コメントを参照
仕様: RFC 4512
作成者/変更管理者: IESG
コメント:
次の記述子 (短い名前) がレジストリに追加された。
名前 種別 OID
------------------------ ---- -----------------
governingStructureRule A 2.5.21.10
structuralObjectClass A 2.5.21.9
次の記述子 (短い名前) は、本 RFC を参照するよう更新された。
名前 種別 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
10. 謝辞
本文書は、M. Wahl、T. Howes、および S. Kille による RFC 2251、 M. Wahl、A. Coulbeck、T. Howes、および S. Kille による RFC 2252、 ならびに M. Wahl による RFC 2556 に一部基づいている。これらはいずれも IETF Access, Searching and Indexing of Directories (ASID) 作業部会の 成果である。本文書は、International Telephone Union (ITU) の成果である "The Directory: Models" [X.501] にも一部基づいている。さらに、M. Wahl、 T. Howes、および S. Kille による RFC 2253 から文章を引用している。
本文書は IETF LDAP Revision (LDAPBIS) 作業部会の成果である。
- 規範的参考文献
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3671] Zeilenga, K., "Collective Attributes in the Lightweight Directory Access Protocol (LDAP)", RFC 3671, December 2003.
[RFC3672] Zeilenga, K., "Subentries in the Lightweight Directory Access Protocol (LDAP)", RFC 3672, December 2003.
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006.
[RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006.
[RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters", RFC 4515, June 2006.
[RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator", RFC 4516, June 2006.
[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
[RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, June 2006.
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
[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/).
[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.501] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory -- Models," X.501(1993) (also 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).
付録 A. 変更点
この付録は規範的ではない。
本文書は RFC 2251、RFC 2252、RFC 2256 の一部をほぼ全面的に書き直したものであり、技術仕様全体の明確性を高めるために行われた。本付録は、これらから本文書に取り込んだ部分に対する実質的変更を要約する。残りの部分については [RFC4510]、[RFC4511]、[RFC4517]、[RFC4519] を参照されたい。
A.1. RFC 2251 からの変更
本文書は、以下のとおり RFC 2251 の 3.2 節、3.4 節、および 4 節と 6 節の一部を取り込んでいる。
A.1.1. RFC 2251 の 3.2 節
RFC 2251 の 3.2 節は、LDAP で使用される X.500 データモデルを簡単に紹介した。以前の仕様は [X.501] に依存していたが、X.500 モデルを LDAP 用にどのように適応するかが不明確だった。本文書は、特に適応が必要な領域について、LDAP で使用される X.500 データモデルをより詳細に記述する。
RFC 2251 の 3.2.1 節は、属性を「1 つの型と 1 つ以上の関連値」と記述した。LDAP では、属性記述、すなわち 0 個以上のオプションを持つ型と 1 つ以上の関連値、と記述する方が適切である。
RFC 2251 の 3.2.2 節は、サブスキーマサブエントリが objectClasses と attributeTypes を含むことを義務付けたが、X.500(93) では任意である。通常、X.500(93) のサブスキーマ機構をサポートする実装は両方を提供するが、相互運用性のために全サーバーへ絶対に要求する必要はない。X.500(93) との整合性のため義務を削除した。また、エントリを制御するサブスキーマは、そのエントリの 'subschemaSubentry' 属性が参照する (sub)entry を読み取って取得することを明確にした。
A.1.2. RFC 2251 の 3.4 節
RFC 2251 の 3.4 節は「サーバー固有データの要件」を規定した。この内容は変更を加えて本文書の 5.1 節に取り込まれた。
変更点:
- ルート DSE の属性は、アクセス制御に加えて「その他の制限」を受けることを明確化。
- 認識される拡張要求だけを 'supportedExtension' に列挙すればよいことを明確化。
- 認識される要求コントロールだけを 'supportedControl' に列挙すればよいことを明確化。
- ルート DSE 属性は運用属性であり、名前で要求しない限り検索要求で返されないことを明確化。
- すべてのルート DSE 属性を利用者が変更できるわけではないことを明確化。
- ルート DSE 内の 'subschemaSubentry' の扱いに関する矛盾した記述を削除。以前の仕様は、この属性が「このサーバーに既知のサブスキーマエントリ (またはサブエントリ)」を参照するとしたが、意図された用途にも単一値属性という正式定義 [X.501] にも整合しない。単純な、場合によっては不完全なサブスキーマサブエントリ の一覧も有用性が低い。本文書の 5.1 節は、ルート DSE の 'subschemaSubentry' がルート DSE を制御するサブスキーマを参照すると規定する。一般的な検出機構は引き続き利用できる (本文書 4.4 節参照)。
A.1.3. RFC 2251 の 4 節
LDAP 情報モデルを詳述する RFC 2251 の 4 節から、次を取り込んだ。
- 識別値を、記述にオプションを持たない属性に限定 (4.1.3 節)。
- 属性タイプ (4.1.4 節)、属性記述 (4.1.5 節)、属性 (4.1.8 節)、マッチング規則識別子 (4.1.9 節) のデータモデル面。
- 利用者スキーマ要件 (4.1.6、4.5.1、4.7 節)。
これらに対する明確化には次が含まれる。
- サブタイプ化、およびオプションを持つ AttributeDescriptions。
A.1.4. RFC 2251 の 6 節
RFC 2251 の 6.1 節と 6.2 節の第 2 段落を本文書に取り込んだ。
A.2. RFC 2252 からの変更
本文書は RFC 2252 の 4、5、7 節を取り込んでいる。
A.2.1. RFC 2252 の 4 節
仕様を Augmented BNF [RFC4234] を使用するよう更新した。OBJECT IDENTIFIER の文字列表現を厳格化し、RFC 2252 の記述どおり先行ゼロを禁止した。
RFC 2252 は
引用符付き文字列 (qdstring) の ABNF を更新し、RFC 2252 の 4.3 節に記述されたエスケープ機構を反映した。
A.2.2. RFC 2252 の 5 節
RFC 2252 の 5 節で示された運用属性定義を本文書に取り込んだ。
'namingContexts' の記述を明確化した。最上位 DSA は、他の値に加えて DIT の根を示す "" を公開することが望ましい。
'altServer' は任意の URI を保持できることを明確化した。
'supportedExtension' は、サーバーが認識する拡張操作の拡張要求に関連付けられた OBJECT IDENTIFIER だけを列挙すればよいことを明確化した。
'supportedControl' は、認識する要求コントロールに関連付けられた OBJECT IDENTIFIER だけを列挙すればよいことを明確化した。
'structuralObjectClass' と 'governingStructureRule' の運用属性タイプ記述を追加した。
'subschemaSubentry' の属性定義を修正し、SINGLE-VALUE と NO-USER-MODIFICATION を正しい順序で列挙した。
A.2.3. RFC 2252 の 7 節
RFC 2252 の 7 節は 'subschema' と 'extensibleObject' の定義を提供した。これらをそれぞれ本文書の 4.2 節と 4.3 節に統合した。また同節のオブジェクトクラス実装要件を本文書の 7 節に取り込んだ。
'extensibleObject' と禁止属性の相互作用を明確化した。
A.3. RFC 2256 からの変更
本文書は RFC 2256 の 5.1、5.2、7.1、7.2 節を取り込んでいる。
RFC 2256 の 5.1 節の 'objectClass' 属性タイプ定義を本文書の 2.4.1 節に統合した。「値の 1 つは 'top' または 'alias' である」を、'alias' に属するエントリも 'top' に属するため、「値の 1 つは 'top' である」に置き換えた。
RFC 2256 の 5.2 節の 'aliasedObjectName' 属性タイプ定義を本文書の 2.6.2 節に統合した。
RFC 2256 の 7.1 節の 'top' オブジェクトクラス定義を本文書の 2.4.1 節に統合した。
RFC 2256 の 7.2 節の 'alias' オブジェクトクラス定義を本文書の 2.6.1 節に統合した。
A.4. RFC 3674 からの変更
本文書は、RFC 3674 の 'supportedFeatures' 技術仕様に実質的な変更を加えていない。
編集者の連絡先
Kurt D. Zeilenga OpenLDAP Foundation
EMail: [email protected]
完全な著作権表示
Copyright (C) The Internet Society (2006).
本文書は BCP 78 に記載された権利、ライセンスおよび制限の対象となり、そこで定める場合を除き、著者はすべての権利を留保する。
本文書およびここに含まれる情報は「現状有姿」で提供される。寄稿者、その者が代表する、または支援を受ける組織 (存在する場合)、THE INTERNET SOCIETY、および THE INTERNET ENGINEERING TASK FORCE は、明示または黙示を問わず、ここに含まれる情報の使用がいかなる権利も侵害しないとの保証、ならびに商品性または特定目的への適合性に関する黙示の保証を含むがこれらに限定されない、あらゆる保証を否認する。
知的財産
IETF は、本文書に記載された技術の実装または使用に関係すると主張され得る知的財産権その他の権利の有効性もしくは範囲、またはそれらに基づくライセンスが利用可能となり得る範囲について、いかなる立場も取らない。また、そのような権利を特定するため独自の調査を行ったとも表明しない。RFC 文書の権利に関する手続きは BCP 78 および BCP 79 に記載されている。
IETF 事務局に提出された IPR 開示の写し、利用可能とするライセンスに関する保証、または本仕様の実装者もしくは利用者が当該専有権を使用するための一般ライセンスまたは許可を得ようとした結果は、IETF のオンライン IPR リポジトリ http://www.ietf.org/ipr から入手できる。
IETF は、本標準の実装に必要となり得る技術を対象とする著作権、特許、特許出願、その他の専有権について、関係者が IETF に通知することを求めている。情報は [email protected] 宛てに送付されたい。
謝辞
RFC Editor 機能の資金は IETF Administrative Support Activity (IASA) が提供している。