[要約] RFC 4516は、LDAPのURL形式に関する仕様であり、LDAPサーバーへのアクセスを簡素化するために設計されています。このRFCの目的は、LDAPクライアントが効率的にサーバーに接続し、ディレクトリ情報を取得するための一貫した方法を提供することです。
Network Working Group M. Smith, Ed.
Request for Comments: 4516 Pearl Crescent, LLC
Obsoletes: 2255 T. Howes
Category: Standards Track Opsware, Inc.
June 2006
Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator
軽量ディレクトリアクセスプロトコル（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
概要
This document describes a format for a Lightweight Directory Access Protocol (LDAP) Uniform Resource Locator (URL). An LDAP URL describes an LDAP search operation that is used to retrieve information from an LDAP directory, or, in the context of an LDAP referral or reference, an LDAP URL describes a service where an LDAP operation may be progressed.
このドキュメントでは、軽量ディレクトリアクセスプロトコル（LDAP）ユニフォームリソースロケーター（URL）の形式について説明します。LDAP URLは、LDAPディレクトリから情報を取得するために使用されるLDAP検索操作、またはLDAPの紹介または参照のコンテキストで、LDAPのURLがLDAP操作が進行する可能性のあるサービスを説明します。
Table of Contents
目次
1. Introduction ....................................................2
2. URL Definition ..................................................2
2.1. Percent-Encoding ...........................................4
3. Defaults for Fields of the LDAP URL .............................5
4. Examples ........................................................6
5. Security Considerations .........................................8
6. Normative References ............................................9
7. Informative References .........................................10
8. Acknowledgements ...............................................10
Appendix A: Changes Since RFC 2255 ................................11
A.1. Technical Changes .........................................11
A.2. Editorial Changes .........................................11
LDAP is the Lightweight Directory Access Protocol [RFC4510]. This document specifies the LDAP URL format for version 3 of LDAP and clarifies how LDAP URLs are resolved. This document also defines an extension mechanism for LDAP URLs. This mechanism may be used to provide access to new LDAP extensions.
LDAPは、軽量ディレクトリアクセスプロトコル[RFC4510]です。このドキュメントは、LDAPのバージョン3のLDAP URL形式を指定し、LDAP URLの解決方法を明確にします。このドキュメントは、LDAP URLの拡張メカニズムも定義しています。このメカニズムは、新しいLDAP拡張機能へのアクセスを提供するために使用できます。
Note that not all the parameters of the LDAP search operation described in [RFC4511] can be expressed using the format defined in this document. Note also that URLs may be used to represent reference knowledge, including that for non-search operations.
[RFC4511]で説明されているLDAP検索操作のすべてのパラメーターが、このドキュメントで定義されている形式を使用して表現できるわけではないことに注意してください。また、URLは、非検索操作を含む参照知識を表すために使用できることに注意してください。
This document is an 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 replaces RFC 2255. See Appendix A for a list of changes relative to RFC 2255.
このドキュメントは、RFC 2255に置き換えられます。RFC2255に関連する変更のリストについては、付録Aを参照してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14 [RFC2119]に記載されているように解釈される。
An LDAP URL begins with the protocol prefix "ldap" and is defined by the following grammar, following the ABNF notation defined in [RFC4234].
LDAP URLは、プロトコルプレフィックス「LDAP」から始まり、[RFC4234]で定義されているABNF表記に従って、次の文法で定義されます。
ldapurl = scheme COLON SLASH SLASH [host [COLON port]]
[SLASH dn [QUESTION [attributes]
[QUESTION [scope] [QUESTION [filter]
[QUESTION extensions]]]]]
; <host> and <port> are defined
; in Sections 3.2.2 and 3.2.3
; of [RFC3986].
; <filter> is from Section 3 of
; [RFC4515], subject to the
; provisions of the
; "Percent-Encoding" section
; below.
scheme = "ldap"
dn = distinguishedName ; From Section 3 of [RFC4514],
; subject to the provisions of
; the "Percent-Encoding"
; section below.
attributes = attrdesc *(COMMA attrdesc)
attrdesc = selector *(COMMA selector)
selector = attributeSelector ; From Section 4.5.1 of
; [RFC4511], subject to the
; provisions of the
; "Percent-Encoding" section
; below.
scope = "base" / "one" / "sub"
extensions = extension *(COMMA extension)
extension = [EXCLAMATION] extype [EQUALS exvalue]
extype = oid ; From section 1.4 of [RFC4512].
exvalue = LDAPString ; From section 4.1.2 of
; [RFC4511], subject to the
; provisions of the
; "Percent-Encoding" section
; below.
EXCLAMATION = %x21 ; exclamation mark ("!")
SLASH = %x2F ; forward slash ("/")
COLON = %x3A ; colon (":")
QUESTION = %x3F ; question mark ("?")
The "ldap" prefix indicates an entry or entries accessible from the LDAP server running on the given hostname at the given portnumber. Note that the <host> may contain literal IPv6 addresses as specified in Section 3.2.2 of [RFC3986].
「LDAP」プレフィックスは、指定されたPortNumberで指定されたホスト名で実行されているLDAPサーバーからアクセスできるエントリまたはエントリを示します。<Host>には、[RFC3986]のセクション3.2.2で指定されているように、文字通りのIPv6アドレスが含まれている場合があることに注意してください。
The <dn> is an LDAP Distinguished Name using the string format described in [RFC4514]. It identifies the base object of the LDAP search or the target of a non-search operation.
<dn>は、[RFC4514]で説明されている文字列形式を使用したLDAPの著名な名前です。LDAP検索のベースオブジェクトまたは非検索操作のターゲットを識別します。
The <attributes> construct is used to indicate which attributes should be returned from the entry or entries.
<属性>コンストラクトは、エントリまたはエントリからどの属性を返すべきかを示すために使用されます。
The <scope> construct is used to specify the scope of the search to perform in the given LDAP server. The allowable scopes are "base" for a base object search, "one" for a one-level search, or "sub" for a subtree search.
<scope>コンストラクトは、特定のLDAPサーバーで実行する検索の範囲を指定するために使用されます。許容スコープは、ベースオブジェクト検索の「ベース」、「1つのレベル検索の1つ」、またはサブツリー検索の「サブ」です。
The <filter> is used to specify the search filter to apply to entries within the specified scope during the search. It has the format specified in [RFC4515].
<filter>は、検索中に指定されたスコープ内のエントリに適用する検索フィルターを指定するために使用されます。[RFC4515]で指定された形式があります。
The <extensions> construct provides the LDAP URL with an extensibility mechanism, allowing the capabilities of the URL to be extended in the future. Extensions are a simple comma-separated list of type=value pairs, where the =value portion MAY be omitted for options not requiring it. Each type=value pair is a separate extension. These LDAP URL extensions are not necessarily related to any of the LDAP extension mechanisms. Extensions may be supported or unsupported by the client resolving the URL. An extension prefixed with a '!' character (ASCII 0x21) is critical. An extension not prefixed with a '!' character is non-critical.
<extensions>コンストラクトは、LDAP URLに拡張性メカニズムを提供し、URLの機能を将来拡張できるようにします。拡張機能は、タイプ=値のペアの単純なコンマ区切りリストであり、=値部分を必要としないオプションの場合、値部分を省略できます。各タイプ=値ペアは個別の拡張機能です。これらのLDAP URL拡張機能は、必ずしもLDAP拡張メカニズムのいずれかに関連しているわけではありません。拡張機能は、URLを解決するクライアントによってサポートまたはサポートされていない場合があります。'！'が付いた拡張機能文字（ASCII 0x21）が重要です。「！」が付いていない拡張機能キャラクターは非クリティカルです。
If an LDAP URL extension is implemented (that is, if the implementation understands it and is able to use it), the implementation MUST make use of it. If an extension is not implemented and is marked critical, the implementation MUST NOT process the URL. If an extension is not implemented and is not marked critical, the implementation MUST ignore the extension.
LDAP URL拡張機能が実装されている場合（つまり、実装が理解し、使用できる場合）、実装はそれを利用する必要があります。拡張機能が実装されておらず、クリティカルとマークされている場合、実装はURLを処理してはなりません。拡張機能が実装されておらず、クリティカルとマークされていない場合、実装は拡張機能を無視する必要があります。
The extension type (<extype>) MAY be specified using the numeric OID <numericoid> form (e.g., 1.2.3.4) or the descriptor <descr> form (e.g., myLDAPURLExtension). Use of the <descr> form SHOULD be restricted to registered object identifier descriptive names. See [RFC4520] for registration details and usage guidelines for descriptive names.
拡張型（<ExType>）は、数値oid <numericoiod>フォーム（例：1.2.3.4）または記述子<descr>形式（例：myldapurlextension）を使用して指定できます。<descr>フォームの使用は、登録されたオブジェクト識別子記述名に制限する必要があります。記述名については、登録の詳細と使用ガイドラインについては[RFC4520]を参照してください。
No LDAP URL extensions are defined in this document. Other documents or a future version of this document MAY define one or more extensions.
このドキュメントでは、LDAP URL拡張機能は定義されていません。このドキュメントの他のドキュメントまたは将来のバージョンは、1つ以上の拡張機能を定義する場合があります。
A generated LDAP URL MUST consist only of the restricted set of characters included in one of the following three productions defined in [RFC3986]:
生成されたLDAP URLは、[RFC3986]で定義されている次の3つのプロダクションのいずれかに含まれる文字の制限付きセットでのみ構成する必要があります。
<reserved>
<unreserved>
<pct-encoded>
Implementations SHOULD accept other valid UTF-8 strings [RFC3629] as input. An octet MUST be encoded using the percent-encoding mechanism described in section 2.1 of [RFC3986] in any of these situations:
実装は、他の有効なUTF-8文字列[RFC3629]を入力として受け入れる必要があります。オクテットは、これらの状況のいずれかで[RFC3986]のセクション2.1で説明されているパーセントエンコードメカニズムを使用してエンコードする必要があります。
The octet is not in the reserved set defined in section 2.2 of [RFC3986] or in the unreserved set defined in section 2.3 of [RFC3986].
オクテットは、[RFC3986]のセクション2.2または[RFC3986]のセクション2.3で定義されている予約されていないセットで定義されている予約セットにはありません。
It is the single Reserved character '?' and occurs inside a <dn>, <filter>, or other element of an LDAP URL.
それは単一の予約済みのキャラクター「？」です。<dn>、<filter>、またはLDAP URLの他の要素内で発生します。
It is a comma character ',' that occurs inside an <exvalue>.
それはコンマのキャラクターであり、「<exvalue>内部で発生します。
Note that before the percent-encoding mechanism is applied, the extensions component of the LDAP URL may contain one or more null (zero) bytes. No other component may.
パーセントエンコードメカニズムが適用される前に、LDAP URLの拡張コンポーネントには1つ以上のnull（ゼロ）バイトが含まれる場合があることに注意してください。他のコンポーネントはありません。
Some fields of the LDAP URL are optional, as described above. In the absence of any other specification, the following general defaults SHOULD be used when a field is absent. Note that other documents MAY specify different defaulting rules; for example, section 4.1.10 of [RFC4511] specifies a different rule for determining the correct DN to use when it is absent in an LDAP URL that is returned as a referral.
上記のように、LDAP URLの一部のフィールドはオプションです。他の仕様がない場合、フィールドがない場合は、次の一般的なデフォルトを使用する必要があります。他のドキュメントは、異なるデフォルトルールを指定する場合があることに注意してください。たとえば、[RFC4511]のセクション4.1.10は、紹介として返されるLDAP URLに存在しない場合に使用する正しいDNを決定するための異なるルールを指定します。
<host> If no <host> is given, the client must have some a priori knowledge of an appropriate LDAP server to contact.
<host> no <host>が与えられた場合、クライアントは連絡する適切なLDAPサーバーの先験的な知識を持っている必要があります。
<port> The default LDAP port is TCP port 389.
<port>デフォルトのLDAPポートはTCPポート389です。
<dn> If no <dn> is given, the default is the zero-length DN, "".
<dn> no <dn>が指定されている場合、デフォルトはゼロ長dn ""です。
<attributes> If the <attributes> part is omitted, all user attributes of the entry or entries should be requested (e.g., by setting the attributes field AttributeDescriptionList in the LDAP search request to a NULL list, or by using the special <alluserattrs> selector "*").
<属性> <属性>パーツが省略されている場合、エントリまたはエントリのすべてのユーザー属性を要求する必要があります（たとえば、LDAP検索リクエストの属性フィールド属性リストをnullリストに設定するか、特別な<alluserattrs>セレクター "*"）。
<scope> If <scope> is omitted, a <scope> of "base" is assumed.
<Scope> <scope>が省略されている場合、「ベース」の<scope>が想定されます。
<filter> If <filter> is omitted, a filter of "(objectClass=*)" is assumed.
<filter> <filter>が省略されている場合、「（objectclass =*）」のフィルターが想定されます。
<extensions> If <extensions> is omitted, no extensions are assumed.
<extensions> <extensions>が省略されている場合、拡張機能は想定されていません。
The following are some example LDAP URLs that use the format defined above. The first example is an LDAP URL referring to the University of Michigan entry, available from an LDAP server of the client's choosing:
以下は、上記の形式を使用するLDAP URLの例です。最初の例は、ミシガン大学のエントリを参照するLDAP URLです。クライアントの選択のLDAPサーバーから入手できます。
ldap:///o=University%20of%20Michigan,c=US
The next example is an LDAP URL referring to the University of Michigan entry in a particular ldap server:
次の例は、特定のLDAPサーバーでのミシガン大学のエントリーを指すLDAP URLです。
ldap://ldap1.example.net/o=University%20of%20Michigan,c=US
Both of these URLs correspond to a base object search of the "o=University of Michigan,c=US" entry using a filter of "(objectclass=*)", requesting all attributes.
これらのURLはどちらも、「O =ミシガン大学、c = us」エントリのベースオブジェクト検索に対応しています。
The next example is an LDAP URL referring to only the postalAddress attribute of the University of Michigan entry:
次の例は、ミシガン大学のエントリの郵便放送属性のみを参照するLDAP URLです。
ldap://ldap1.example.net/o=University%20of%20Michigan, c=US?postalAddress
ldap：//ldap1.example.net/o = university%20of%20michigan、c = us？postaladdress
The corresponding LDAP search operation is the same as in the previous example, except that only the postalAddress attribute is requested.
対応するLDAP検索操作は、前の例と同じです。ただし、郵便放棄属性のみが要求されます。
The next example is an LDAP URL referring to the set of entries found by querying the given LDAP server on port 6666 and doing a subtree search of the University of Michigan for any entry with a common name of "Babs Jensen", retrieving all attributes:
次の例は、ポート6666で指定されたLDAPサーバーをクエリすることで見つかったエントリのセットを参照し、ミシガン大学のサブツリー検索を行って、「Babs Jensen」の共通名を持つエントリのサブツリー検索を行うことです。
ldap://ldap1.example.net:6666/o=University%20of%20Michigan,
c=US??sub?(cn=Babs%20Jensen)
The next example is an LDAP URL referring to all children of the c=GB entry:
次の例は、C = GBエントリのすべての子供を指すLDAP URLです。
LDAP://ldap1.example.com/c=GB?objectClass?ONE
ldap：//ldap1.example.com/c = gb？objectclass？one
The objectClass attribute is requested to be returned along with the entries, and the default filter of "(objectclass=*)" is used.
ObjectClass属性はエントリとともに返されるように要求され、「（objectClass =*）」のデフォルトフィルターが使用されます。
The next example is an LDAP URL to retrieve the mail attribute for the LDAP entry named "o=Question?,c=US", illustrating the use of the percent-encoding mechanism on the reserved character '?'.
次の例は、「o = question？、c = us」という名前のLDAPエントリのメール属性を取得するLDAP URLです。
ldap://ldap2.example.com/o=Question%3f,c=US?mail
The next example (which is broken into two lines for readability) illustrates the interaction between the LDAP string representation of the filters-quoting mechanism and the URL-quoting mechanisms.
次の例（読みやすさのために2つの線に分割されている）は、フィルター引用機構のLDAP文字列表現とURL引用機構の相互作用を示しています。
ldap://ldap3.example.com/o=Babsco,c=US
???(four-octet=%5c00%5c00%5c00%5c04)
The filter in this example uses the LDAP escaping mechanism of \ to encode three zero or null bytes in the value. In LDAP, the filter would be written as (four-octet=\00\00\00\04). Because the \ character must be escaped in a URL, the \s are percent-encoded as %5c (or %5C) in the URL encoding.
この例のフィルターは、\のLDAP脱出メカニズムを使用して、値の3つのゼロまたはヌルバイトをエンコードします。LDAPでは、フィルターは（4-OCTET = \ 00 \ 00 \ 00 \ 04）として記述されます。\文字はURLで脱出する必要があるため、\ sはURLエンコーディングの％5c（または％5c）としてエンコードされます。
The next example illustrates the interaction between the LDAP string representation of the DNs-quoting mechanism and URL-quoting mechanisms.
次の例は、DNS引用機構のLDAP文字列表現とURL引用機構の相互作用を示しています。
ldap://ldap.example.com/o=An%20Example%5C2C%20Inc.,c=US
The DN encoded in the above URL is:
上記のURLでエンコードされたDNは次のとおりです。
o=An Example\2C Inc.,c=US
o =例\ 2c Inc.、c = us
That is, the left-most RDN value is:
つまり、左のRDN値は次のとおりです。
An Example, Inc.
例、Inc。
The following three URLs are equivalent, assuming that the defaulting rules specified in Section 3 of this document are used:
次の3つのURLは、このドキュメントのセクション3で指定されているデフォルトのルールが使用されていると仮定して、次のように同等です。
ldap://ldap.example.net ldap://ldap.example.net/ ldap://ldap.example.net/?
ldap：//ldap.example.net ldap：//ldap.example.net/ ldap：//ldap.example.net/？
These three URLs point to the root DSE on the ldap.example.net server.
これらの3つのURLは、LDAP.example.netサーバーのルートDSEを指します。
The final two examples show use of a hypothetical, experimental bind name extension (the value associated with the extension is an LDAP DN).
最後の2つの例は、仮説的な実験的バインド名拡張の使用を示しています（拡張に関連する値はLDAP DNです）。
ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com
ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com
The two URLs are the same, except that the second one marks the e-bindname extension as critical. Notice the use of the percent-encoding mechanism to encode the commas within the distinguished name value in the e-bindname extension.
2つのURLは同じですが、2番目のURLがe-bindname拡張機能を重要なものとしてマークしていることを除きます。e-bindname拡張機能の著名な名前値内でコンマをエンコードするパーセントエンコードメカニズムの使用に注意してください。
The general URL security considerations discussed in [RFC3986] are relevant for LDAP URLs.
[RFC3986]で説明されている一般的なURLセキュリティの考慮事項は、LDAP URLに関連しています。
The use of security mechanisms when processing LDAP URLs requires particular care, since clients may encounter many different servers via URLs, and since URLs are likely to be processed automatically, without user intervention. A client SHOULD have a user-configurable policy that controls which servers the client will establish LDAP sessions with and with which security mechanisms, and SHOULD NOT establish LDAP sessions that are inconsistent with this policy. If a client chooses to reuse an existing LDAP session when resolving one or more LDAP URLs, it MUST ensure that the session is compatible with the URL and that no security policies are violated.
LDAP URLを処理する際のセキュリティメカニズムの使用には、クライアントがURLを介して多くの異なるサーバーに遭遇する可能性があるため、URLはユーザーの介入なしで自動的に処理される可能性が高いため、特定のケアが必要です。クライアントは、クライアントがセキュリティメカニズムと一緒にLDAPセッションを確立することを組み立てるユーザー構成ポリシーを持つ必要があり、このポリシーと矛盾するLDAPセッションを確立すべきではありません。クライアントが1つ以上のLDAP URLを解決するときに既存のLDAPセッションを再利用することを選択した場合、セッションがURLと互換性があり、セキュリティポリシーが違反されないことを確認する必要があります。
Sending authentication information, no matter the mechanism, may violate a user's privacy requirements. In the absence of specific policy permitting authentication information to be sent to a server, a client should use an anonymous LDAP session. (Note that clients conforming to previous LDAP URL specifications, where all LDAP sessions are anonymous and unprotected, are consistent with this specification; they simply have the default security policy.) Simply opening a transport connection to another server may violate some users' privacy requirements, so clients should provide the user with a way to control URL processing.
認証情報を送信しても、メカニズムに関係なく、ユーザーのプライバシー要件に違反する可能性があります。認証情報をサーバーに送信する特定のポリシーがない場合、クライアントは匿名のLDAPセッションを使用する必要があります。（すべてのLDAPセッションが匿名で保護されていない以前のLDAP URL仕様に準拠しているクライアントは、この仕様と一致しています。デフォルトのセキュリティポリシーを持っているだけです。、そのため、クライアントはユーザーにURL処理を制御する方法を提供する必要があります。
Some authentication methods, in particular, reusable passwords sent to the server, may reveal easily-abused information to the remote server or to eavesdroppers in transit and should not be used in URL processing unless they are explicitly permitted by policy. Confirmation by the human user of the use of authentication information is appropriate in many circumstances. Use of strong authentication methods that do not reveal sensitive information is much preferred. If the URL represents a referral for an update operation, strong authentication methods SHOULD be used. Please refer to the Security Considerations section of [RFC4513] for more information.
一部の認証方法、特にサーバーに送信される再利用可能なパスワードは、リモートサーバーまたは輸送中の盗聴者に簡単に違反した情報を明らかにする場合があり、ポリシーで明示的に許可されていない限り、URL処理で使用すべきではありません。多くの状況では、認証情報の使用の人間ユーザーによる確認が適切です。機密情報を明らかにしない強力な認証方法の使用が非常に好まれます。URLが更新操作の紹介を表している場合、強力な認証方法を使用する必要があります。詳細については、[RFC4513]のセキュリティに関する考慮事項セクションを参照してください。
The LDAP URL format allows the specification of an arbitrary LDAP search operation to be performed when evaluating the LDAP URL. Following an LDAP URL may cause unexpected results, for example, the retrieval of large amounts of data or the initiation of a long-lived search. The security implications of resolving an LDAP URL are the same as those of resolving an LDAP search query.
LDAP URL形式により、LDAP URLを評価するときに任意のLDAP検索操作の仕様を実行できます。LDAP URLに続いて、たとえば、大量のデータの取得や長寿命の検索の開始など、予期しない結果が発生する可能性があります。LDAP URLを解決することのセキュリティへの影響は、LDAP検索クエリを解決するものと同じです。
[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月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：ジェネリック構文」、STD 66、RFC 3986、2005年1月。
[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月。
[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月。
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006.
[RFC4512] Zeilenga、K。、「Lightweight Directory Access Protocol（LDAP）：ディレクトリ情報モデル」、RFC 4512、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。Ed。およびT. Howes、「Lightweight Directory Access Protocol（LDAP）：検索フィルターの文字列表現」、RFC 4515、2006年6月。
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC2396] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：ジェネリック構文」、RFC 2396、1998年8月。
[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）Lightwight Directory Access Protocol（LDAP）の考慮事項」、BCP 64、RFC 4520、2006年6月。
The LDAP URL format was originally defined at the University of Michigan. This material is based upon work supported by the National Science Foundation under Grant No. NCR-9416667. The support of both the University of Michigan and the National Science Foundation is gratefully acknowledged.
LDAP URL形式は、もともとミシガン大学で定義されていました。この資料は、Grant No. NCR-9416667の下で国立科学財団によってサポートされている作業に基づいています。ミシガン大学と国立科学財団の両方の支援は感謝されています。
This document obsoletes RFC 2255 by Tim Howes and Mark Smith. Changes included in this revised specification are based upon discussions among the authors, discussions within the LDAP (v3) Revision Working Group (ldapbis), and discussions within other IETF Working Groups. The contributions of individuals in these working groups is gratefully acknowledged. Several people in particular have made valuable comments on this document: RL "Bob" Morgan, Mark Wahl, Kurt Zeilenga, Jim Sermersheim, and Hallvard Furuseth deserve special thanks for their contributions.
この文書は、ティム・ハウズとマーク・スミスによるRFC 2255を廃止します。この改訂された仕様に含まれる変更は、著者間の議論、LDAP（V3）改訂ワーキンググループ（LDAPBIS）内の議論、および他のIETFワーキンググループ内の議論に基づいています。これらのワーキンググループにおける個人の貢献は感謝されています。特に何人かの人々がこの文書について貴重なコメントをしています：RL "Bob" Morgan、Mark Wahl、Kurt Zeilenga、Jim Sermersheim、およびHallvard Furusethは、彼らの貢献に特別な感謝に値します。
Appendix A: Changes Since RFC 2255
付録A：RFC 2255以降の変更
The following technical changes were made to the contents of the "URL Definition" section:
「URL定義」セクションの内容に対して、次の技術的な変更が行われました。
Revised all of the ABNF to use common productions from [RFC4512].
[RFC4512]の一般的なプロダクションを使用するために、すべてのABNFを修正しました。
Replaced references to [RFC2396] with a reference to [RFC3986] (this allows literal IPv6 addresses to be used inside the <host> portion of the URL, and a note was added to remind the reader of this enhancement). Referencing [RFC3986] required changes to the ABNF and text so that productions that are no longer defined by [RFC3986] are not used. For example, <hostport> is not defined by [RFC3986] so it has been replaced with host [COLON port]. Note that [RFC3986] includes new definitions for the "Reserved" and "Unreserved" sets of characters, and the net result is that the following two additional characters should be percent-encoded when they appear anywhere in the data used to construct an LDAP URL: "[" and "]" (these two characters were first added to the Reserved set by RFC 2732).
[RFC2396]への参照を[RFC3986]への参照に置き換えました（これにより、URLの<ホスト>部分内で文字通りのIPv6アドレスを使用することができ、この強化を読者に思い出させるためにメモを追加しました）。[RFC3986]を参照すると、[RFC3986]によって定義されなくなった作品が使用されないように、ABNFとテキストに変更が必要です。たとえば、<hostport>は[RFC3986]で定義されていないため、ホスト[コロンポート]に置き換えられています。[RFC3986]には、「予約済み」および「予約されていない」セットの文字の新しい定義が含まれており、最終的な結果は、LDAP URLの構築に使用されるデータのどこにでも表示されるときに次の2つの追加文字をパーセントエンコードする必要があることに注意してください。： "[" and "]"（これら2つのキャラクターは、最初にRFC 2732によって予約されたセットに追加されました）。
Changed the definition of <attrdesc> to refer to <attributeSelector> from [RFC4511]. This allows the use of "*" in the <attrdesc> part of the URL. It is believed that existing implementations of RFC 2255 already support this.
[rfc4511]から<attributeselector>を参照するように<attrdesc>の定義を変更しました。これにより、URLの<attrdesc>部分で「*」を使用できます。RFC 2255の既存の実装はすでにこれをサポートしていると考えられています。
Avoided use of <prose-val> (bracketed-string) productions in the <dn>, <host>, <attrdesc>, and <exvalue> rules.
<dn>、<dn>、<host>、<attrdesc>、および<exvalue>ルールでの<prose-val>（bracketed-string）プロダクションの使用を回避しました。
Changed the ABNF for <ldapurl> to group the <dn> component with the preceding <SLASH>.
<ldapurl>のabnfを変更して、<dn>コンポーネントを前の<slash>とグループ化しました。
Changed the <extype> rule to be an <oid> from [RFC4512].
<extype>ルールを[rfc4512]から<oid>に変更しました。
Changed the text about extension types so it references [RFC4520]. Reordered rules to more closely follow the order in which the elements appear in the URL.
[RFC4520]を参照するために、拡張タイプに関するテキストを変更しました。並べ替えられたルールは、URLに要素が表示される順序をより厳密に追跡します。
"Bindname Extension": removed due to lack of known implementations.
「BindName Extension」：既知の実装がないため削除されました。
Changed document title to include "LDAP:" prefix.
ドキュメントタイトルを変更して、「LDAP：」プレフィックスを含めました。
IESG Note: removed note about lack of satisfactory mandatory authentication mechanisms.
IESG注：満足のいく必須認証メカニズムの欠如に関するメモを削除しました。
"Status of this Memo" section: updated boilerplate to match current I-D guidelines.
「このメモのステータス」セクション：現在のI-Dガイドラインと一致するように、ボイラープレートを更新しました。
"Abstract" section: separated from introductory material.
「要約」セクション：入門資料から分離。
"Table of Contents" and "Intellectual Property" sections: added.
「目次」および「知的財産」セクション：追加。
"Introduction" section: new section; separated from the Abstract. Changed the text indicate that RFC 2255 is replaced by this document (instead of RFC 1959). Added text to indicate that LDAP URLs are used for references and referrals. Fixed typo (replaced the nonsense phrase "to perform to retrieve" with "used to retrieve"). Added a note to let the reader know that not all of the parameters of the LDAP search operation described in [RFC4511] can be expressed using this format.
「はじめに」セクション：新しいセクション。要約から分離されています。変更されたテキストは、RFC 2255が（RFC 1959ではなく）このドキュメントに置き換えられていることを示しています。LDAP URLが参照と紹介に使用されることを示すテキストが追加されました。タイプミスを修正しました（「取得するために使用される」で「実行するために実行する」というナンセンスなフレーズを置き換えました）。[RFC4511]に記載されているLDAP検索操作のすべてのパラメーターをこの形式を使用して表現できるわけではないことを読者に知らせるメモを追加しました。
"URL Definition" section: removed second copy of <ldapurl> grammar and following two paragraphs (editorial error in RFC 2255). Fixed line break within '!' sequence. Reformatted the ABNF to improve readability by aligning comments and adding some blank lines. Replaced "residing in the LDAP server" with "accessible from the LDAP server" in the sentence immediately following the ABNF. Removed the sentence "Individual attrdesc names are as defined for AttributeDescription in [RFC4511]." because [RFC4511]'s <attributeSelector> is now used directly in the ABNF. Reworded last paragraph to clarify which characters must be percent-encoded. Added text to indicate that LDAP URLs are used for references and referrals. Added text that refers to the ABNF from RFC 4234. Clarified and strengthened the requirements with respect to processing of URLs that contain implemented and not implemented extensions (the approach now closely matches that specified in [RFC4511] for LDAP controls).
「URL定義」セクション：<ldapurl>グラマーの2番目のコピーと2つの段落に続く（RFC 2255の編集エラー）。「！」内の固定回線ブレーク順序。コメントを調整し、いくつかの空白線を追加することにより、読みやすさを改善するためにABNFを再フォーマットしました。ABNFの直後の文の「LDAPサーバーに住んでいる」「LDAPサーバーからアクセス可能」に置き換えました。「個々の属性名は、[RFC4511]で起因するように定義されているように定義されている」という文を削除しました。[rfc4511] 's <attributeselector>がABNFで直接使用されるためです。最後の段落を書き直して、どの文字がパーセントエンコードされている必要があるかを明確にします。LDAP URLが参照と紹介に使用されることを示すテキストが追加されました。RFC 4234からのABNFを指すテキストが追加されました。実装および実装されていない拡張機能を含むURLの処理に関する要件を明確にし、強化しました（現在、LDAPコントロールに[RFC4511]で指定されたものと密接に一致します）。
"Defaults for Fields of the LDAP URL" section: added; formed by moving text about defaults out of the "URL Definition" section. Replaced direct reference to the attribute name "*" with a reference to the special <alluserattrs> selector "*" defined in [RFC4511].
「LDAP URLのフィールドのデフォルト」セクション：追加。「URL定義」セクションからデフォルトに関するテキストを移動することによって形成されます。[RFC4511]で定義されているSpecial <alluserattrs> selector "*"への参照に属性名「*」への直接参照を置き換えました。
"URL Processing" section: removed.
「URL処理」セクション：削除。
"Examples" section: Modified examples to use example.com and example.net hostnames. Added missing '?' to the LDAP URL example whose filter contains three null bytes. Removed space after one comma within a DN. Revised the bindname example to use e-bindname. Changed the name of an attribute used in one example from "int" to "four-octet" to avoid potential confusion. Added an example that demonstrates the interaction between DN escaping and URL percent-encoding. Added some examples to show URL equivalence with respect to the <dn> portion of the URL. Used uppercase in some examples to remind the reader that some tokens are case-insensitive.
「例」セクション：example.comおよびembles.netホスト名を使用するための修正された例。不足している「？」を追加しましたフィルターに3つのヌルバイトが含まれているLDAP URLの例。DN内の1つのコンマの後にスペースを削除しました。bindnameの例を改訂して、e-bindnameを使用しました。潜在的な混乱を避けるために、1つの例で使用された属性の名前を「int」から「four-octet」に変更しました。DNの脱出とURLパーセントエンコードの間の相互作用を示す例を追加しました。URLの<dn>部分とのURLの等価性を示す例をいくつか追加しました。いくつかの例で大文字を使用して、一部のトークンがケースに依存しないことを読者に思い出させます。
"Security Considerations" section: Added a note about connection reuse. Added a note about using strong authentication methods for updates. Added a reference to [RFC4513]. Added note that simply opening a connection may violate some users' privacy requirements. Adopted the working group's revised LDAP terminology specification by replacing the word "connection" with "LDAP session" or "LDAP connection" as appropriate.
「セキュリティ上の考慮事項」セクション：接続の再利用に関するメモを追加しました。更新に強力な認証方法を使用することに関するメモを追加しました。[RFC4513]への参照を追加しました。接続を開くだけで、一部のユーザーのプライバシー要件に違反する可能性があるという注意が追加されました。「接続」という単語を「LDAPセッション」または「LDAP接続」に置き換えることにより、ワーキンググループの修正されたLDAP用語仕様を採用しました。
"Acknowledgements" section: added statement that this document obsoletes RFC 2255. Added Kurt Zeilenga, Jim Sermersheim, and Hallvard Furuseth.
「謝辞」セクション：この文書がRFC2255が廃止されたという声明を追加しました。カート・ゼイレンガ、ジム・セルマーズハイム、およびハルバード・フルーゼスを追加しました。
"Normative References" section: renamed from "References" per new RFC guidelines. Changed from [1] style to [RFC4511] style throughout the document. Added references to RFC 4234 and RFC 3629. Updated all RFC 1738 references to point to the appropriate sections within [RFC3986]. Updated the LDAP references to refer to LDAPBis WG documents. Removed the reference to the LDAP Attribute Syntaxes document and added references to the [RFC4513], [RFC4520], and [RFC4510] documents.
「規範的参照」セクション：新しいRFCガイドラインごとに「参照」から改名されました。ドキュメント全体で[1]スタイルから[RFC4511]スタイルに変更されました。RFC 4234およびRFC3629への参照を追加しました。すべてのRFC 1738参照を更新して、[RFC3986]内の適切なセクションを指します。LDAP参照を更新して、LDAPBIS WGドキュメントを参照しました。LDAP属性のSyntaxesドキュメントへの参照を削除し、[RFC4513]、[RFC4520]、および[RFC4510]ドキュメントへの参照を追加しました。
"Informative References" section: added.
「有益な参照」セクション：追加。
Header and "Authors' Addresses" sections: added "editor" next to Mark Smith's name. Updated affiliation and contact information.
ヘッダーと「著者のアドレス」セクション：マークスミスの名前の横に「エディター」が追加されました。提携と連絡先情報を更新しました。
Copyright: updated the year.
著作権：年を更新しました。
Throughout the document: surrounded the names of all ABNF productions with "<" and ">" where they are used in descriptive text.
ドキュメント全体で：すべてのABNFプロダクションの名前を「<」と「>」で説明し、説明的なテキストで使用されています。
Authors' Addresses
著者のアドレス
Mark Smith, Editor Pearl Crescent, LLC 447 Marlpool Dr. Saline, MI 48176 USA
マーク・スミス、編集者パール・クレセント、LLC 447 Marlpool Dr. Saline、MI 48176 USA
Phone: +1 734 944-2856
EMail: mcs@pearlcrescent.com
Tim Howes Opsware, Inc. 599 N. Mathilda Ave. Sunnyvale, CA 94085 USA
Tim Howes Opsware、Inc。599 N. Mathilda Ave. Sunnyvale、CA 94085 USA
Phone: +1 408 744-7509
EMail: howes@opsware.com
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）によって提供されます。