Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions

このメモの位置付け

本文書は、 インターネットコミュニティのための標準化プロトコルを規定するとともに、 それを改良するための議論や提言を求めるものである。 本プロトコルの標準化状態、および、 ステータスについては「Internet Official Protocol Standards」(STD 1)の最新版を参照してほしい。 このメモの配布に制限は無い。

著作権表記

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

IESGノート

本文書では、 読み出しおよび更新アクセスを提供するディレクトリアクセスプロトコルについて述べる。 更新アクセスには安全な認証が必要である。 しかし、本文書は十分な認証機構の実装についてはなにも指示しない。

このような制限は存在するが、本仕様書は、 RFC 2026のセクション4.4.1に従って、Proposed StandardとしてIESGに認可されている。 その理由は次の通りである：

1. 配備される前に、(更新アクセスの有無に関わらず)本プロトコルの実装と相互運用性の試験を奨励するため。
2. 読み出し専用のアプリケーション中でのこれらのプロトコルの配備と利用を奨励するため。(例えば、LDAP以外の安全な方法で更新されるディレクトリに対して、LDAPv3が問い合わせ言語として使用されているアプリケーション）
3. LDAPv3ディレクトリサーバへの問い合わせ機能が必要であるが、更新を必要としない他の標準化過程にあるプロトコルの配備あるいは、進歩を遅らせないため。

必須の認証機構が標準化されるまで、 本仕様に従って書かれた更新機能を利用するクライアントとサーバは相互運用できない、 あるいは、認証レベルが受け入れ難いレベルにまで下げられる場合に限り相互運用できる、 という可能性があることを読者にあらかじめ警告する。

実装者は、LDAPv3で必須となる認証のための Proposed Standardが認められ、 RFCとして発行されるまで、更新機能を実装するLDAPv3クライアント、 およびサーバの配備を行わないことが望ましい。

Lightweight Directory Access Protocol (LDAP) [1]では、 プロトコル要素中のAttributeValueフィールドの中味がオクテット文字列であることが要求される。 本文書では、LDAPv3の構文セット、および、LDAPプロトコルでの送信のために、 これらの構文の属性値をオクテット文字列として表記する規則を定義する。 本文書で定義されている構文は、 本文書および属性型を定義する他の文書によっても参照される。 本文書はLDAPサーバがサポートすべき属性型のセットについても定義する。

本文書は、LDAP(Lightweight Directory Access Protocol)を介してアクセス可能なディレクトリのスキーマを開発するためのフレームワークを定義する。

スキーマは、属性型定義、オブジェクトクラス定義、および、 サーバが(比較オペレーションにおいて)エントリの属性に対して、 いかにしてフィルタや属性値宣言を適用するか、 追加や変更オペレーションを認めるかどうか、 等を決定するために用いる様々の情報の集合である。

セクション4は、属性型、オブジェクトクラス、 構文と適合規則定義の一般的な必要条件と属性型の表記法について述べる。

セクション5では属性、セクション6では構文、 セクション7ではオブジェクトクラスを列挙する。

追加文書によって、 実世界のオブジェクトをディレクトリエントリとして表記するためのスキーマを定義する。

本文書はインターネットプロトコルで使用されている符号化について述べる。

本文書中のキーワード、"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL"は、 RFC 2119[4]に記述されたように解釈されるべき用語である。

属性型とオブジェクトクラス定義は、 X.501(93)[3]で定義されているAttributeTypeDescriptionとObjectClassDescriptionデータ型の文字列表記で記述される。 実装者には、本文書の残りを読む前に、 まずX.500におけるスキーマの表記法についての記述を読むことを強く勧める。

属性構文の符号化規則を定義するために、 以下に示すようなBNF定義が用いられる。 それらはRFC822[13]のBNF記法に基づいている。

    a     = "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" /
            "j" / "k" / "l" / "m" / "n" / "o" / "p" / "q" / "r" /
            "s" / "t" / "u" / "v" / "w" / "x" / "y" / "z" / "A" /
            "B" / "C" / "D" / "E" / "F" / "G" / "H" / "I" / "J" /
            "K" / "L" / "M" / "N" / "O" / "P" / "Q" / "R" / "S" /
            "T" / "U" / "V" / "W" / "X" / "Y" / "Z"

    d               = "0" / "1" / "2" / "3" / "4" /
                      "5" / "6" / "7" / "8" / "9"

    hex-digit       =  d / "a" / "b" / "c" / "d" / "e" / "f" /
                           "A" / "B" / "C" / "D" / "E" / "F"

    k               = a / d / "-" / ";"

    p               = a / d / """ / "(" / ")" / "+" / "," /
                      "-" / "." / "/" / ":" / "?" / " "

    letterstring    = 1*a

    numericstring   = 1*d

    anhstring       = 1*k

    keystring       = a [ anhstring ]

    printablestring = 1*p

    space           = 1*" "

    whsp            = [空白]

    utf8            =＜ISO 10646[10]中の文字のUTF-8[9]変換によって作られた
        オクテットのあらゆるシーケンス＞

    dstring         = 1*utf8

    qdstring        = whsp "'" dstring "'" whsp

    qdstringlist    = [ qdstring *( qdstring ) ]

    qdstrings       = qdstring / ( whsp "(" qdstringlist ")" whsp )

OBJECT IDENTIFIERの文字列表現のための次のBNFでは、 descrは文字と数字から成り、 文字で始まるオブジェクト記述子の構文的な表現である。 NumericoidフォーマットであるOBJECT IDENTIFIERは、 先頭にゼロを持つべきではない。 （例えば、「0.9.3」が許されるが、「0.09.3」は生成されるべきではない）

値中の「oid」要素を符号化する際には、descr符号化オプションは、 numericoidよりも優先的に使用されるべきである(SHOULD)。 オブジェクト記述子は、数字によるOBJECT IDENTIFIERの読み易い別名である。 そして(実装で割り振られ利用される)これらはnumericoidよりもできる限り優先して使用されるべきである(SHOULD)。 LDAPにおけるオブジェクト記述子の例は、属性型、 オブジェクトクラスおよび適合規則名である。

     oid             = descr / numericoid

     descr           = keystring

     numericoid      = numericstring *( "." numericstring )

     woid            = whsp oid whsp

     ; set of oids of either form
     oids            = woid / ( "(" oidlist ")" )

     oidlist         = woid *( "$" woid )

     ；スキーマ要素名として使用されるオブジェクト記述子
     qdescrs         = qdescr / ( whsp "(" qdescrlist ")" whsp )

     qdescrlist      = [ qdescr *( qdescr ) ]


     qdescr          = whsp "'" descr "'" whsp

属性型は、AttributeTypeDescription構文で書かれており、 サブスキーマのattributeType属性のためのサンプル値によって記述されている。 読みやすくするために行が折り返されているが、 プロトコル中で転送される値は改行を含まない。

AttributeTypeDescriptionは以下のBNFに従って符号化される。 そしてoid、qdescrsおよびqdstringの生成子はセクション4.1で記述されている。 実装者は、本書の今後のバージョンが追加の項を含むために、 このBNFを拡張してもよいことに注意するべきである。 「X-」文字から始まる項は、私的な実験のために予約されており、 <qdstrings>に従わなければならない(MUST)。

      AttributeTypeDescription = "(" whsp
            numericoid whsp              ; AttributeType identifier
          [ "NAME" qdescrs ]             ; name used in AttributeType
          [ "DESC" qdstring ]            ; description
          [ "OBSOLETE" whsp ]
          [ "SUP" woid ]                 ; derived from this other
                                         ; AttributeType
          [ "EQUALITY" woid              ; Matching Rule name
          [ "ORDERING" woid              ; Matching Rule name
          [ "SUBSTR" woid ]              ; Matching Rule name
          [ "SYNTAX" whsp noidlen whsp ] ; see section 4.3
          [ "SINGLE-VALUE" whsp ]        ; default multi-valued
          [ "COLLECTIVE" whsp ]          ; default not collective
          [ "NO-USER-MODIFICATION" whsp ]; default user modifiable
          [ "USAGE" whsp AttributeUsage ]; default userApplications
          whsp ")"

      AttributeUsage =
          "userApplications"     /
          "directoryOperation"   /
          "distributedOperation" / ; DSA-shared
          "dSAOperation"          ; DSA-specific, value depends on server

サーバは、それが保持するサブスキーマ値の記述部分中のものと同じ、 もしくはそのいかなる文書を提供することも要求されない。 サーバはそれぞれのAttributeTypeDescriptionに対して少なくとも「SUP」と「SYNTAX」フィールドのどちらかを供給するべきである(SHOULD)。

サーバは、セクション5.1、5.2、 および5.3で参照される全属性型を実装しなければならない(MUST)。

サーバは、 本文書でリストアップされてない追加の名前と属性を認識してもよい(MAY)が、 その場合、サブスキーマエントリのattributeTypes属性で型の定義を公表しなければならない(MUST)。

スキーマ開発者は、 その名前が既存のStandard Track RFCでLDAP使用するために定義された属性と衝突する属性の定義を作成してはならない(MUST NOT)。

AttributeDescriptionは、 AttributeTypeDescriptionのNAME部分で値として使用することができる。 これらは、大文字小文字を区別しないことに注意。

extensibleMatch検索フィルタ中で、AttributeTypeDescriptionは、 属性型に使用され得る適合規則をリストしないことに注意。 これはセクション4.5で記述されるmatchingRuleUse属性を使って行われる。

本文書は、AttributeTypeDescriptionのSYNTAXフィールドが、 LDAP文字列構文定義のためのOBJECT IDENTIFIERの文字列表現であり、 またこの属性値の最大長をオプション表示（セクション4.3.2で定義されている）することを要求することによって、X.501のスキーマ記述を改善する。

本セクションでは、 LDAP属性値構文の符号化に関する一般的要件について定義する。 LDAPが用いる属性構文の符号化を定義するすべての文書は、 これらの要件に準拠することが求められる。

与えられた属性構文に対して定義された符号化規則は、 オクテット文字列を生成しなければならない。 符号化されたオクテット文字列は、表示目的に使用できるように、 可能な限りそこで使用されている符号化形式で使用できるものであるべきだ。 特に、非バイナリ値を定義する属性構文で使用される符号化規則は、 LDAPを実装しているクライアントがほとんど、 あるいはまったく変換しないで表示できる文字列を生成するべきである。 しかし、 いくつかの場合(例えば音声)に印刷可能な表記を作成する意味はなく、 かつ、クライントは認識できない構文が文字列表記であると仮定してはならない(MUST NOT)。

識別名ではない任意の文字列が、より大きな生成子の一部として、かつ、 識別名の一部以外として使用される符号化では、 文字列に以下の分離記号文字(例えば「'」、「$」、「#」)があれば、 それをエスケープするためにバックスラッシュ引用機構が使われる。 バックスラッシュは次の文字を表記している1対の16進数字の前にある。 より大きな構文の部分をなす文字列中のバックスラッシュ自身は常にいつも「\5C」あるいは「\5c」として転送される。 例はセクション6.27にある。

また、 宣言値構文が属性値構文と異なっている適合規則のための構文も定義される。

この符号化形式は、 クライアントがある属性のためにバイナリ符号化を要求する場合、 あるいは属性構文名が「1.3.6.1.4.1.1466.115.121.1.5」である場合に使用される。 LDAPattributeValueまたは、AssertionValueフィールドの内容は、 BER符号化された属性値のインスタンス、もしくは、 X.500で用いるために定義された適合規則宣言値のASN.1データである。 (オクテット文字列中の最初のバイトはタグオクテットである。 しかし、オクテット文字列は依然プリミティブ形式で符号化される。)

属性型が認識され、属性構文名がBinaryのそれであるなら、 検索応答における属性値の生成と、追加、比較、 修正要求における属性値解析の両者のために、 すべてのサーバはこの形式を実装しなければならない(MUST)。 すべての属性がエントリから返されることを要求するクライントは、 バイナリ値を受け取らなければならない(MUST)。 (例えばuserCertificate；binary)、そしてユーザには、 バイナリあるいは認識されない値を単純に表示するべきではない(SHOULD NOT)。

LDAPを用いるための構文は、 ドットで区切られた10進数文字列であるOBJECT IDENTIFIERによって名付けられる。 これらをユーザに表示することは意図されていない。

   noidlen = numericoid [ "{" len "}" ]

   len     = numericstring

次の表は、LDAPのためにこれまで定義された構文のいくつかを列挙している。 H-R列はその構文による値が人に読み易い文字列になっているかどうかの示唆である。 クライントとサーバはここに列挙されているすべての構文を実装する必要はなく、 また、他の構文を実装してもよい(MAY)。

他の文書が追加の構文を定義してもよい。 しかし、相互運用の妨げになるため、 任意の追加構文定義の作成には強く反対する： 現在のクライントとサーバ実装は新しい構文を動的に認識する能力を持っていない。 たいていの場合、属性はディレクトリ文字列のための構文で定義される。

   表現されている値                H-R オブジェクト 識別子
   =================================================================
   ACI Item                        N  1.3.6.1.4.1.1466.115.121.1.1
   Access Point                    Y  1.3.6.1.4.1.1466.115.121.1.2
   Attribute Type Description      Y  1.3.6.1.4.1.1466.115.121.1.3
   Audio                           N  1.3.6.1.4.1.1466.115.121.1.4
   Binary                          N  1.3.6.1.4.1.1466.115.121.1.5
   Bit String                      Y  1.3.6.1.4.1.1466.115.121.1.6
   Boolean                         Y  1.3.6.1.4.1.1466.115.121.1.7
   Certificate                     N  1.3.6.1.4.1.1466.115.121.1.8
   Certificate List                N  1.3.6.1.4.1.1466.115.121.1.9
   Certificate Pair                N  1.3.6.1.4.1.1466.115.121.1.10
   Country String                  Y  1.3.6.1.4.1.1466.115.121.1.11
   DN                              Y  1.3.6.1.4.1.1466.115.121.1.12
   Data Quality Syntax             Y  1.3.6.1.4.1.1466.115.121.1.13
   Delivery Method                 Y  1.3.6.1.4.1.1466.115.121.1.14
   Directory String                Y  1.3.6.1.4.1.1466.115.121.1.15
   DIT Content Rule Description    Y  1.3.6.1.4.1.1466.115.121.1.16
   DIT Structure Rule Description  Y  1.3.6.1.4.1.1466.115.121.1.17
   DL Submit Permission            Y  1.3.6.1.4.1.1466.115.121.1.18
   DSA Quality Syntax              Y  1.3.6.1.4.1.1466.115.121.1.19
   DSE Type                        Y  1.3.6.1.4.1.1466.115.121.1.20
   Enhanced Guide                  Y  1.3.6.1.4.1.1466.115.121.1.21
   Facsimile Telephone Number      Y  1.3.6.1.4.1.1466.115.121.1.22
   Fax                             N  1.3.6.1.4.1.1466.115.121.1.23
   Generalized Time                Y  1.3.6.1.4.1.1466.115.121.1.24
   Guide                           Y  1.3.6.1.4.1.1466.115.121.1.25
   IA5 String                      Y  1.3.6.1.4.1.1466.115.121.1.26
   INTEGER                         Y  1.3.6.1.4.1.1466.115.121.1.27
   JPEG                            N  1.3.6.1.4.1.1466.115.121.1.28
   LDAP Syntax Description         Y  1.3.6.1.4.1.1466.115.121.1.54
   LDAP Schema Definition          Y  1.3.6.1.4.1.1466.115.121.1.56
   LDAP Schema Description         Y  1.3.6.1.4.1.1466.115.121.1.57
   Master And Shadow Access Points Y  1.3.6.1.4.1.1466.115.121.1.29
   Matching Rule Description       Y  1.3.6.1.4.1.1466.115.121.1.30
   Matching Rule Use Description   Y  1.3.6.1.4.1.1466.115.121.1.31
   Mail Preference                 Y  1.3.6.1.4.1.1466.115.121.1.32
   MHS OR Address                  Y  1.3.6.1.4.1.1466.115.121.1.33
   Modify Rights                   Y  1.3.6.1.4.1.1466.115.121.1.55
   Name And Optional UID           Y  1.3.6.1.4.1.1466.115.121.1.34
   Name Form Description           Y  1.3.6.1.4.1.1466.115.121.1.35
   Numeric String                  Y  1.3.6.1.4.1.1466.115.121.1.36
   Object Class Description        Y  1.3.6.1.4.1.1466.115.121.1.37
   Octet String                    Y  1.3.6.1.4.1.1466.115.121.1.40
   OID                             Y  1.3.6.1.4.1.1466.115.121.1.38
   Other Mailbox                   Y  1.3.6.1.4.1.1466.115.121.1.39
   Postal Address                  Y  1.3.6.1.4.1.1466.115.121.1.41
   Protocol Information            Y  1.3.6.1.4.1.1466.115.121.1.42

   Presentation Address            Y  1.3.6.1.4.1.1466.115.121.1.43
   Printable String                Y  1.3.6.1.4.1.1466.115.121.1.44
   Substring Assertion             Y  1.3.6.1.4.1.1466.115.121.1.58
   Subtree Specification           Y  1.3.6.1.4.1.1466.115.121.1.45
   Supplier Information            Y  1.3.6.1.4.1.1466.115.121.1.46
   Supplier Or Consumer            Y  1.3.6.1.4.1.1466.115.121.1.47
   Supplier And Consumer           Y  1.3.6.1.4.1.1466.115.121.1.48
   Supported Algorithm             N  1.3.6.1.4.1.1466.115.121.1.49
   Telephone Number                Y  1.3.6.1.4.1.1466.115.121.1.50
   Teletex Terminal Identifier     Y  1.3.6.1.4.1.1466.115.121.1.51
   Telex Number                    Y  1.3.6.1.4.1.1466.115.121.1.52
   UTC Time                        Y  1.3.6.1.4.1.1466.115.121.1.53

文字列ベース構文における値の文字数、 あるいは他の全ての構文における値の最小バイト数の提案上限は、 Attribute Type Description中の構文名のOBJECT IDENTIFIERに続く中カッコの中に、 この限度の数を付加することで示してもよい。 この限度は構文名の一部ではない。 例えば、「1.3.6.4.1.1466.0{64}」は、 サーバ実装がもっと長い文字列を認めてもよいが、 長さが64文字の文字列を許すべきであることを示している。 UTF-8は可変長の符号化であるため、 Directory String構文の１つの文字が１バイト以上で符号化される可能性に注意。

以下のBNFは、短い記述をOBJECT IDENTIFIER構文に関連付けるために使用される。 実装者は、 本書の今後のバージョンが追加の項を含むためにこのBNFを拡張してもよいことに注意するべきである。 「X-」文字から始まる項は、私的な実験のために予約されており、 <qdstrings>に従わなければならない(MUST)。

SyntaxDescription = "(" whsp numericoid whsp [ "DESC" qdstring ] whsp ")"

オブジェクトクラスを表記するための形式はX.501[3]で定義されている。 一般に、全てのエントリは一つの抽象クラス(「top」あるいは「alias」)、 少なくとも１つの構造型オブジェクトクラス、 および0個以上の補助的なオブジェクトクラスを含んでいる。 オブジェクトクラスが抽象か、構造型か、あるいは補助的であるかは、 オブジェクトクラス識別子が割り当てられる際に定義される。 オブジェクトクラス定義は、 新しい識別子の割り当てなしに変えられるべきではない。

オブジェクトクラス記述は以下のBNFに従って書かれる。 実装者は、 本書の今後のバージョンが追加の項を含むためにこのBNFを拡張してもよいことに注意するべきである。 「X-」文字から始まる項は、私的な実験のために予約されており、 <qdstrings>に従わなければならない(MUST)。

      ObjectClassDescription = "(" whsp
          numericoid whsp      ; ObjectClass identifier
          [ "NAME" qdescrs ]
          [ "DESC" qdstring ]
          [ "OBSOLETE" whsp ]
          [ "SUP" oids ]       ; Superior ObjectClasses
          [ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ]
                               ; default structural
          [ "MUST" oids ]      ; AttributeTypes
          [ "MAY" oids ]       ; AttributeTypes
      whsp ")"

これらはLDAPスキーマを実装するサーバのためにサブスキーマの「objectClasses」属性のサンプル値として記述されている。 読み易くするために行が折り返されているが、 プロトコル中で転送される値は改行を含まない。

サーバは、オプションであるextensibleObject以外の、 セクション7で参照される全てのオブジェクトクラスを実装するべきである(SHOULD)。 サーバは、本文書でリストアップされていない追加のオブジェクトクラスを実装してもよい(MAY)。 その場合、それらのサブスキーマエントリの「objectClasses」属性でクラスの定義を公表しなければならない(MUST)。

スキーマ開発者はStandards-Track RFCでLDAPを用いるために定義された属性と衝突する名前のオブジェクトクラス定義を作成してはならない(MUST NOT)。

適合規則は、サーバによって検索と比較のオペレーションを行う際に、 宣言値に対して属性値を比較するために使用される。 それらは、エントリを修正する際に追加あるいは削除される値を確認するため、 および、識別名をエントリの名前と比較する際に使用される。

本書で与えられる属性の大部分は、等価適合規則が定義されている。

適合規則記述は、以下のBNFによって書かれている。 実装者は、 本書の今後のバージョンが追加の項を含むためにこのBNFを拡張してもよいことに注意するべきである。 「X-」文字から始まる項は、私的な実験のために予約されており、 <qdstrings>に従わなければならない(MUST)。

      MatchingRuleDescription = "(" whsp
          numericoid whsp  ; MatchingRule identifier
          [ "NAME" qdescrs ]
          [ "DESC" qdstring ]
          [ "OBSOLETE" whsp ]
          "SYNTAX" numericoid
      whsp ")"

MatchingRuleUseの値は、拡張可能適合規則の使用に適した属性を列挙する。

      MatchingRuleUseDescription = "(" whsp
          numericoid whsp  ; MatchingRule identifier
          [ "NAME" qdescrs ]
          [ "DESC" qdstring ]
          [ "OBSOLETE" ]
         "APPLIES" oids    ; AttributeType identifiers
      whsp ")"

適合規則とextensibleMatchをサポートするサーバは、 セクション7のすべての適合規則を実装する必要がある(SHOULD)。

サーバは、 本文書でリストアップされてない追加の適合規則を実装してもよい(MAY)。 その場合、それらのサブスキーマエントリの「matchingRules」属性で適合規則の定義を公開しなければならない(MUST)。 サーバがextensibleMatchをサポートするなら、 サーバはmatchingRuleUseの属性中の適合規則と属性の関係を公開しなければならない(MUST)。

例えば、Directory String-valued属性でsound-alike適合を行うために私的に定義された適合規則を実装しているサーバは、 サブスキーマエントリに以下のものを含む。(1.2.3.4.5は例であり実際の適合規則OIDは異なっている）

   matchingRule: ( 1.2.3.4.5 NAME 'soundAlikeMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

この適合規則が属性2.5.4.41と2.5.4.15で使われるなら、以下のものも存在する：

   matchingRuleUse: ( 1.2.3.4.5 APPLIES (2.5.4.41 $ 2.5.4.15) )

クライアントはその場合、フィルタにextensibleMatchを選択し、 matchingRuleフィールドが「soundAlikeMatch」、 そして型フィールドが「2.5.4.41」あるいは「2.5.4.15」である検索オペレーションを送ることによってこの適合規則を利用することができる。

すべてのLDAPサーバ実装は、 本セクションで定義されている属性型を認識しなければならない(MUST)。

サーバは、 [12]のセクション5からのすべての属性も認識するべきである(SHOULD)。

サーバは、 X.501(93)の定義に従ってこれらの属性の値を保持しなければならない(MUST)。

この属性は、 Addオペレーションを使って生成されたエントリに表れるべきである(SHOULD)。

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

この属性はModifyオペレーションを使って変更されたエントリに表れるべきである(SHOULD)。

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

この属性はAddオペレーションを使って生成されたエントリに表れるべきである(SHOULD)。

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

この属性はModifyオペレーションを使って変更されたエントリに表れるべきである(SHOULD)。

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

この属性の値は、 スキーマを指定する属性を利用可能にするサーバ中のサブスキーマエントリ(あるいは、 サーバがX.500(93)に基づいているなら、サブエントリ)の名前である。

    ( 2.5.18.10 NAME 'subschemaSubentry'
      EQUALITY distinguishedNameMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATION
      SINGLE-VALUE USAGE directoryOperation )

この属性は普通、サブスキーマエントリに置かれる。

    ( 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.6 NAME 'objectClasses'
      EQUALITY objectIdentifierFirstComponentMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.37 USAGE directoryOperation )

この属性は普通、サブスキーマエントリに置かれる。

    ( 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.8 NAME 'matchingRuleUse'
      EQUALITY objectIdentifierFirstComponentMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.31 USAGE directoryOperation )

これらの属性はルートDSEだけに存在する([1]、 [3]参照）。

サーバはこれらの属性名を認識しなければならないが(MUST)、 その属性がサーバが実装しない機能に対するものである場合は、 これらの属性の値の提供は要求されない。

この属性の値は、このサーバが所有する、 あるいはシャドウするネーミングコンテキストに対応するものである。 もしサーバが何の情報も所有しないなら(例えば、 そのサーバが公共のX.500ディレクトリに対するLDAPゲートウェイのとき)、 この属性は存在しない。 サーバがディレクトリ全体を含んでいることを確信するなら、 この属性は値を一つ持ち、 それは空の文字列(ルートの長さゼロのDNを示している)とする。 この属性はクライントがサーバと通信を行った際に、 検索のための適当なベースオブジェクトを選択することを認める。

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

この属性の値は、 このサーバが利用不可能になった際に連絡を取ることができる他のサーバのURLである。 サーバが使用できる他のサーバを知らない場合には、 この属性は存在しない。 クライントは、後に優先的なLDAPサーバが利用できなくなる場合は、 この情報をキャッシュしてもよい。

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

この属性の値は、 サーバがサポートする拡張されたオペレーションを識別するOBJECT IDENTIFIERである。

サーバが拡張をサポートしないなら、この属性は存在しない。

    ( 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.101.120.13 NAME 'supportedControl'
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation )

この属性の値は、サーバがサポートする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 )

この属性の値は、サーバが実装する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 )

この属性は普通、サブスキーマエントリに置かれる。

サーバは、 実装されている構文を列挙するためにこの属性を使用してもよい(MAY)。 そして、それぞれの値が１つの構文に対応する。

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

この属性はサブスキーマエントリに置かれる。 典型的にはX.500サーバだけがそれらの機能を実装するが、 すべてのサーバはそれらの名前を認識するべきである(SHOULD)。

 ( 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.7 NAME 'nameForms'
      EQUALITY objectIdentifierFirstComponentMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.35 USAGE directoryOperation )

    ( 2.5.21.2 NAME 'dITContentRules'
      EQUALITY objectIdentifierFirstComponentMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.16 USAGE directoryOperation )

サーバは、 本セクションで記述されたすべての構文を認識する必要がある(SHOULD)。

   ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' )

この構文による値がセクション4.2の最初に与えられたBNFによって符号化される。 例えば、

        ( 2.5.4.0 NAME 'objectClass'
          SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )

   ( 1.3.6.1.4.1.1466.115.121.1.5 DESC 'Binary' )

この構文による値が、セクション4.3.1で記述されるように符号化される。

   ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' )

この構文による値が以下のBNFによって符号化される：

      bitstring = "'" *binary-digit "'B"

      binary-digit = "0" / "1"

   Example:

        '0101111101'B

   ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )

この構文による値が以下のBNFに従って符号化される：

      boolean = "TRUE" / "FALSE"

ブール値はそれらが論理的に真であるなら、TRUEとして符号化される。 そうでない場合は、FALSEとして符号化される。

   ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' )
    

X.509(1988)からX.509(1993)への変更、および、 認証拡張をサポートするためのASN.1定義への追加変更のために、 文字列表現は定義されていない。 そして「userCertificate;binary」や「caCertificate;binary」の記述とともに属性を要求、 または返し、この構文による値はバイナリ符号化だけを用いて転送されなければならない(MUST)。 「User Certificate」のためにRFC 1778のBNF記法の使用は推奨されない。

   ( 1.3.6.1.4.1.1466.115.121.1.9 DESC 'Certificate List' )
    

廃止リストのX.509(1988)とX.509(1993)定義の不一致のため、 この構文による値は、 「userCertificate;binary」や「caCertificate;binary」の記述とともに属性を要求、または返し、 バイナリ符号化だけを用いて転送されなければならない(MUST)。 「Authority Revocation List」のためにRFC 1778のBNF記法を用いることは推奨されない。

   ( 1.3.6.1.4.1.1466.115.121.1.10 DESC 'Certificate Pair' )
    

Certificateはバイナリで転送されるため、 「crossCertificatePair;binary」の属性記述を要求または返すことによって、 この構文による値はバイナリ符号化だけを用いて転送されなければならない(MUST)。 「Certificate Pair」のためにRFC 1778のBNF記法を用いることは推奨されない。

   ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' )
    

この構文による値はDirectory String構文による値と同じように符号化される。 この構文は、ISO 3166[14]でリストアップされているように、 印字可能な２文字の文字列に限定されることに注意。

      CountryString  = p p

   例 ：
      US

   ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )
    

識別名構文による値は、 [5]で定義された表記を持つように符号化される。 RDN中のどのDirectoryString要素のCHOICEも失われているため、 この表記は、識別名に対して、 X.500で使用されるASN.1符号化に逆変換できないことに注意。

   例 ([5]から):
      CN=Steve Kille,O=Isode Limited,C=GB
      OU=Sales+CN=J. Smith,O=Widget Inc.,C=US
      CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB
      CN=Before\0DAfter,O=Test,C=GB
      1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB
      SN=Lu\C4\8Di\C4\87

   ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )
    

この構文の文字列は、 ISO 10646のUTF-8形式(Unicodeのスーパセット)によって符号化される。 サーバとクライアントは、 任意のUnicode文字の(現在どの文字集合にも割り当てられていない文字も含めて)符号化されたものも受け取らなければならない(MUST)。

PrintableString形式の文字では、値は文字列値自体として符号化される。

文字がTeletexString形式であるなら、 それらはUniversalString中の同等のものに変換されてUTF-8[9]によって符号化される。

それがUniversalString形式、 あるいはBMPString形式[10]であるなら、 それらを符号化するためにUTF-8が使用される。

注意：属性値がバイナリで送信されない限り、 DirectoryStringの形式はプロトコルに示されない。 DAPに変換するサーバは、 適切な形式を選択しなければならない(MUST)。 それらは印刷可能なASCIIの範囲外の正規のUnicode文字を含んでいるため、 サーバは、これらの値をただ単に拒否してはならない(MUST NOT)。

   例 ：

        This is a string of DirectoryString containing #!%#@

   ( 1.3.6.1.4.1.1466.115.121.1.16 DESC 'DIT Content Rule Description' )
    

この構文による値は、以下のBNFに従って符号化される。 実装者は本文書の今後のバージョンが、 追加の項のために拡張されるかもしれないことに注意するべきである。

      DITContentRuleDescription = "("
          numericoid   ; Structural ObjectClass identifier
          [ "NAME" qdescrs ]
          [ "DESC" qdstring ]
          [ "OBSOLETE" ]
          [ "AUX" oids ]    ; Auxiliary ObjectClasses
          [ "MUST" oids ]   ; AttributeType identifiers
          [ "MAY" oids ]    ; AttributeType identifiers
          [ "NOT" oids ]    ; AttributeType identifiers
         ")"

   ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number' )
    

この構文による値は、次のBNFに従って符号化される。

      fax-number    = printablestring [ "$" faxparameters ]

      faxparameters = faxparm / ( faxparm "$" faxparameters )

      faxparm = "twoDimensional" / "fineResolution" /
                "unlimitedLength" /
                "b4Length" / "a3Width" / "b4Width" / "uncompressed"
    

上記の最初のprintablestringは、E.123「15」に基づいた電話番号である。 また、faxparmトークンはファックスパラメータを表記する。

   ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' )
    

この構文による値は、 [7]で定義されるグループ3ファックスイメージを含むオクテット文字列として符号化される。

   ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' )
    

この構文による値は、X.208で指定されているように表記され、 printablestringとして符号化される。 ここでタイムゾーンを指定しなければならないことに注意。 GMTの使用を強く勧める。例えば、

                199412161032Z

   ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )
    

この構文による値の符号化は、その文字列値そのものである。

   ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' )
    

この構文による値は、それらの値の10進数表記として符号化される。 それぞれの10進数は対応する文字によって表記される。 番号1321は文字列「1321」として表記される。

   ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )
    

この構文による値は、 [8]で説明されているJPEGファイル交換フォーマット(JPEG File Interchange Format：JFIF）のJPEG画像を含む文字列として符号化される。

   ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' )
    

matchingRules型の値はセクション4.5で与えられたBNFに従って、 文字列として符号化される。

   ( 1.3.6.1.4.1.1466.115.121.1.31 DESC 'Matching Rule Use Description'
   )
    

MatchingRuleUse型の値はセクション4.5で与えられたBNFに従って文字列として符号化される。

   ( 1.3.6.1.4.1.1466.115.121.1.33 DESC 'MHS OR Address' )
    

この構文による値は、 [11]で定義する形式に従って文字列として符号化される。

   ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' )
    

この構文による値は、以下のBNFに従って符号化される：

 NameAndOptionalUID = DistinguishedName [ "#" bitstring ]
    

「#」文字が識別名の文字列表記中に存在する可能性があるが、 特別な付加的クオートは行われない。 この構文はRFC 1778以降に付け加えられた。

   例えば ：

      1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B

   ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' )
    

この構文による値は、以下のBNFに従って符号化される。 実装者は、本文書の今後のバージョンが、 追加の項のために拡張されるかもしれないことに注意するべきである。

      NameFormDescription = "(" whsp
          numericoid whsp  ; NameForm identifier
          [ "NAME" qdescrs ]
          [ "DESC" qdstring ]
          [ "OBSOLETE" whsp ]
          "OC" woid         ; Structural ObjectClass
          "MUST" oids       ; AttributeTypes
          [ "MAY" oids ]    ; AttributeTypes
      whsp ")"

   ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' )
    

この構文の文字列の符号化は、その文字列値そのものである。

例えば ：

      1997

   ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' )
    

この構文による値はセクション4.4のBNFに従って符号化される。

   ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' )
    

Object Identifier構文による値は、 セクション4.1のBNFに従って符号化される。

 例えば ：

      1.2.3.4
      cn

   ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' )
    

この構文による値は、以下のBNFに従って符号化される ：

      otherMailbox = mailbox-type "$" mailbox

      mailbox-type = printablestring

      mailbox =  <an encoded IA5 String>
    

ここでのmailbox-typeは、 例えば「MCIMail」といったメールボックスが設置されているメールシステムの型を表している。 また、mailboxは、 mailbox-typeで定義されるメールシステムにおける実際のメールボックスである。

   ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' )
    

この構文による値は、以下のBNFに従って符号化される ：

      postal-address = dstring *( "$" dstring )
    

上記で、郵便住所値の各dstring構成要素は、 Directory String構文型の値として符号化される。 バックスラッシュやドル文字が構成要素にあるとすれば、 セクション4.3で記述されたようにクオートされる。 多くのサーバが郵便用住所を30文字までの6行に制限する。

  例えば ：

      1234 Main St.$Anytown, CA 12345$USA
      \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA

   ( 1.3.6.1.4.1.1466.115.121.1.43 DESC 'Presentation Address' )
    

この構文による値は、 RFC 1278[6]に記述された表記で符号化される。

   ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )
    

この構文による値の符号化は、その文字列値そのものである。 PrintableStringはセクション4.1の生成子ｐ中の文字に制限される。

   例えば ：

      This is a PrintableString

   ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )
    

この構文による値は、PrintableString型の値として符号化される。 電話番号は、E.123[15]で記述されているように、 国際的な形式であることがX.520で推奨されている。

   例えば ：

     +1 512 305 0280

   ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' )
    

この構文による値は、UTCTime値を含む文字列からなる、 printablestring型の値として符号化される。 これは過去のやり方である； 新しい属性定義はその代わりにGeneralizedTimeを用いるべきである(SHOULD)。

   ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' )
    

この構文による値は、セクション4.3にあるBNFに従って符号化される。

   ( 1.3.6.1.4.1.1466.115.121.1.17 DESC 'DIT Structure Rule Description')
    

この構文による値は、以下のBNFに従って符号化される :

      DITStructureRuleDescription = "(" whsp
          ruleidentifier whsp            ; DITStructureRule identifier
          [ "NAME" qdescrs ]
          [ "DESC" qdstring ]
          [ "OBSOLETE" whsp ]
          "FORM" woid whsp               ; NameForm
          [ "SUP" ruleidentifiers whsp ] ; superior DITStructureRules
      ")"

      ruleidentifier = integer

      ruleidentifiers = ruleidentifier |
          "(" whsp ruleidentifierlist whsp ")"

      ruleidentifierlist = [ ruleidentifier *( ruleidentifier ) ]

サーバは、 [12]のセクション7のすべての標準クラスの名前を認識するべきである(SHOULD)。

ExtensibleObjectオブジェクトクラスは、エントリ中に存在すれば、 そのエントリがいずれの属性も自由に保持することを可能にする。 このクラスのMAY属性リストは暗黙的にすべての属性のセットである。

    ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
      SUP top AUXILIARY )

依然として、このエントリの他のオブジェクトクラスの必須属性は、 存在することを要求されている。

すべてのサーバがこのオブジェクトクラスを実装するわけではなく、 実装しないサーバは、このオブジェクトクラスを含むエントリの追加要求、 および、このオブジェクトクラスの追加のためにエントリを修正することを拒否することに注意。

このオブジェクトクラスはサブスキーマエントリで使用される。

    ( 2.5.20.1 NAME 'subschema' AUXILIARY
      MAY ( dITStructureRules $ nameForms $ ditContentRules $
      objectClasses $ attributeTypes $ matchingRules $
      matchingRuleUse ) )

LdapSyntaxesオペレーション属性はサブスキーマエントリにも存在してもよい。

ExtensibleMatchフィルタを実装するサーバは、extensibleMatchにおいて、 このセクションでリストアップされたすべての適合規則の使用を認めるべきである(SHOULD)。 一般に、適合規則の宣言構文が属性の値構文と同じである場合、サーバは、 そのサーバに知られているすべての属性型に対して適合規則が適用されることを許すべきである(SHOULD)。

サーバは、追加の適合規則を実装してもよい(MAY)。

サーバは以下の適合規則を適用する能力を持つべきである(SHOULD)。

すべての規則において宣言構文は値構文と同じである。

    ( 2.5.13.0 NAME 'objectIdentifierMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )

クライアントがmatchValueのoidが「descr」形式となっているobjectIdentifierMatchを使ってフィルタを提供し、 サーバでそのoidが認識されないなら、フィルタはUndefinedである。

    ( 2.5.13.1 NAME 'distinguishedNameMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

    ( 2.5.13.2 NAME 'caseIgnoreMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

    ( 2.5.13.8 NAME 'numericStringMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )

    ( 2.5.13.11 NAME 'caseIgnoreListMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )

    ( 2.5.13.14 NAME 'integerMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )

    ( 2.5.13.16 NAME 'bitStringMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )

    ( 2.5.13.20 NAME 'telephoneNumberMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )

    ( 2.5.13.22 NAME 'presentationAddressMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.43 )

    ( 2.5.13.23 NAME 'uniqueMemberMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )

    ( 2.5.13.24 NAME 'protocolInformationMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.42 )

    ( 2.5.13.27 NAME 'generalizedTimeMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )

    ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

    ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

CaseIgnoreMatch、caseIgnoreListMatch、telephoneNumberMatch、 caseExactIA5Match、caseIgnoreIA5Matchを行う際、 隣接している複数の空白文字が一つの空白と同様に扱われ、 前後の空白は無視される。

クライアントは、 サーバがUnicode値の変換能力があると想定してはならない (MUST NOT)。

サーバは、 greaterOrEqualとlessOrEqualフィルタで使用される以下の適合規則を適用できるべきである(SHOULD)。

    ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )

    ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

CaseIgnoreOrderingMatchの分類順序は実装に依存する。

Substring Assertion構文は、拡張適合で宣言値の構文としてのみ使用される。 それは属性の構文として、あるいはサブ文字列フィルタとしては使用されない。

   ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' )

Substring Assertionは次のBNFに従って符号化される：

      substring = [initial] any [final]
      initial = value
      any = "*" *(value "*")
      final = value

<value>生成子は、UTF-8によって符号化された文字列である。 バックスラッシュあるいはアスタリスク文字が<value>生成子中に存在するなら、 それらはセクション4.3で記述されたように引用される。

サーバは、 サブ文字列フィルタで使用される以下の適合規則を適用できるべきである(SHOULD)。

   ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

   ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

   ( 2.5.13.10 NAME 'numericStringSubstringsMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

クライアントによるサブスキーマエントリの修正を容認するサーバは、 それらがいくつかのサブスキーマ属性に対する等価適合規則であるため、 次の適合規則をサポートしなければならない(MUST)。

   ( 2.5.13.29 NAME 'integerFirstComponentMatch'
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )

   ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch'
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )

実装者は、INTEGERあるいはOIDであるこれらの適合規則の宣言構文は、 等価適合規則である属性の値構文とは異なっていることに注意するべきである。

クライアントが、 matchValueが「descr」形式であるobjectIdentifierFirstComponentMatchを使ってフィルタを提供し、 サーバでそのOIDが認識されない場合、フィルタはUndefinedである。

ディレクトリエントリの属性は、 それらが表記する実世界のオブジェクト（例えば、人間、 組織や装置）についての記述的な情報を提供するために使用される。 ほとんどの国には個人の情報公開に関してプライバシーを守るための法律がある。

AttributeValue値のX.501形式からLDAP文字列表記ヘの変換はBER、 あるいはDER形式に逆変換できない場合もある。 識別名のDER形式を要求する場合の例はX.509証明書の照合である。

例えば、型がcommonNameで値が‘Sam'というTeletexStringの一つのAVAから成る一つのRDNで構成される識別名は、 LDAPでは文字列CN=Samと表される。 値が'Sam'であるPrintableStringの他の識別名の場合にも、 LDAPでは同じ文字列CN=Samと示される。

値のDER形式の再構成を要求するアプリケーションは、 識別名をLDAPフォーマットに変換する際、 属性構文の文字列表現を用いるべきではない(SHOULD NOT)。 その代わり、セクション2.4の最初の節で記述したように、 シャープ（”#”）を前につけた16進数形式を用いるべきである(SHOULD)。

本書は Tim Howes 、Steve Kille、Wengyik Yeong 、 Colin Robbinsによって書かれたRFC 1778に基づいている。

本書と関連したドキュメントで定義される属性構文符号の多くはQUIPUとIC R3 X.500の実装で使用される符号を改変して利用したものである。 構文の仕様に関するこの両者の実装を行った方々の貢献に対し、 こころより謝意を贈る。

   Mark Wahl
   Critical Angle Inc.
   4815 West Braker Lane #502-385
   Austin, TX 78759
   USA

   Phone:  +1 512 372-3160
   EMail:  M.Wahl@critical-angle.com

   Andy Coulbeck
   Isode Inc.
   9390 Research Blvd Suite 305
   Austin, TX 78759
   USA

   Phone:  +1 512 231-8993
   EMail:  A.Coulbeck@isode.com

   Tim Howes
   Netscape Communications Corp.
   501 E. Middlefield Rd, MS MV068
   Mountain View, CA 94043
   USA

   Phone:  +1 650 937-3419
   EMail:   howes@netscape.com

   Steve Kille
   Isode Limited
   The Dome, The Square
   Richmond
   TW9 1DT
   UK

   Phone:  +44-181-332-9091
   EMail:  S.Kille@isode.com

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

[2] The Directory: Selected Attribute Types. ITU-T Recommendation X.520, 1993.

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

[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.

[5] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997.

[6] Kille, S., "A String Representation for Presentation Addresses",RFC 1278, November 1991.

[7] Terminal Equipment and Protocols for Telematic Services - Standardization of Group 3 facsimile apparatus for document transmission.  CCITT, Recommendation T.4.

[8] JPEG File Interchange Format (Version 1.02). Eric Hamilton,C-Cube Microsystems, Milpitas, CA, September 1, 1992.

[9] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996.

[10] Universal Multiple-Octet Coded Character Set (UCS) - Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 : 1993 (With amendments).

[11] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC 822", RFC 1327, May 1992.

[12] Wahl, M., "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, December 1997.

[13] Crocker, D., "Standard of the Format of ARPA-Internet Text Messages", STD 11, RFC 822, August 1982.

[14] ISO 3166, "Codes for the representation of names of countries".

[15] ITU-T Rec. E.123, Notation for national and international telephone numbers, 1988.

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

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works.  However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of   developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.