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
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
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.
この文書では、Lightweight Directory Access Protocol（LDAP）のURL（Uniform Resource Locator）の形式を説明しています。 LDAPのURLは、LDAP参照または参照のコンテキストで、LDAPのURLは、LDAP操作が進行することができるサービスを記述し、LDAPディレクトリから情報を取得するために使用される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技術仕様、RFC 3377を時代遅れLDAP技術仕様書[RFC4510]の不可欠な部分です。
This document replaces RFC 2255. See Appendix A for a list of changes relative to RFC 2255.
この文書は、RFC 2255に対する変更のリストについては、RFC 2255を参照してください、付録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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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は[RFC4234]で定義されたABNF表記法以下、プロトコルプレフィックス「LDAP」で始まり、次の文法によって定義されています。
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.
LDAPURL =スキーム結腸スラッシュ[ホスト[COLON口] [スラッシュDN [質問[属性] [質問[範囲] [質問[フィルタ] [質問拡張子]]]]]スラッシュ。 <ホスト>および<ポート>が定義されています。セクション3.2.2と3.2.3で、 [RFC3986]の。 ; <フィルタ>の3章からのものです。 [RFC4515]に従います。の規定; 「パーセントエンコーディング」セクション。未満。
scheme = "ldap" dn = distinguishedName ; From Section 3 of [RFC4514], ; subject to the provisions of ; the "Percent-Encoding" ; section below.
スキーム= "LDAP" DN = distinguishedNameの。 [RFC4514]のセクション3から、。の規定に従います。 「パーセントエンコーディング」。以下のセクション。
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.
属性= attrdesc *（COMMA attrdesc）attrdesc =セレクタ*（COMMAセレクタ）セレクタ= attributeSelector。のセクション4.5.1から。 [RFC4511]に従います。の規定; 「パーセントエンコーディング」セクション。未満。
scope = "base" / "one" / "sub" extensions = extension *(COMMA extension) extension = [EXCLAMATION] extype [EQUALS exvalue] extype = oid ; From section 1.4 of [RFC4512].
範囲= "ベース" / "1" / "サブ" の拡張子=拡張*（COMMA拡張子）拡張子= [EXCLAMATION] extype extype = OID [exvalueに等しいです]。 [RFC4512]のセクション1.4から。
exvalue = LDAPString ; From section 4.1.2 of ; [RFC4511], subject to the ; provisions of the ; "Percent-Encoding" section ; below.
exvalue = LDAPString。のセクション4.1.2から。 [RFC4511]に従います。の規定; 「パーセントエンコーディング」セクション。未満。
EXCLAMATION = %x21 ; exclamation mark ("!") SLASH = %x2F ; forward slash ("/") COLON = %x3A ; colon (":") QUESTION = %x3F ; question mark ("?")
EXCLAMATION =％のX21。感嘆符（ "！"）SLASH =％x2F。スラッシュ（ "/"）COLON =％のX3A。コロン（ "："）QUESTION =％のからx3F。疑問符（ "？"）
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」プレフィックスは、指定されたポート番号で指定したホスト名で実行されているLDAPサーバーからアクセスつまたは複数のエントリを示します。 [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.
<スコープ>コンストラクトは、与えられた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].
<フィルター>検索中に指定された範囲内のエントリに適用する検索フィルタを指定するために使用されます。これは、[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.
<拡張子>構文URLの能力を将来的に拡張することができるように、拡張機構とLDAPの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 <numericoid>フォーム（例えば、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の拡張子は、この文書で定義されていません。他の文書や、この文書の将来のバージョンでは、一つ以上の拡張機能を定義することができます。
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つの作品の1つに含まれ：
<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>、<フィルター>、または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つのまたは複数のヌル（ゼロ）バイトを含んでいてもよいことに留意されたいです。ない他のコンポーネントがよいです。
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.
何の<ホスト>が指定されていない場合、<ホスト>は、クライアントが連絡するための適切な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>が指定されていない場合<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 "*").
<属性> <属性>の部分が省略された場合、エントリまたはエントリのすべてのユーザ属性が要求されなければならない（例えば、NULLリストにLDAP検索要求の属性フィールドAttributeDescriptionListを設定することにより、または<alluserattrs>特別を使用して、セレクタ "*"）。
<scope> If <scope> is omitted, a <scope> of "base" is assumed.
<スコープ>が省略された場合、<スコープ>、「ベース」の<スコープ>が想定されます。
<filter> If <filter> is omitted, a filter of "(objectClass=*)" is assumed.
<フィルター>場合<フィルター>「（オブジェクトクラス= *）」のフィルタを想定し、省略されています。
<extensions> If <extensions> is omitted, no extensions are assumed.
<拡張子>が省略されている場合、<拡張子>は、何の拡張が想定されていません。
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サーバから利用ミシガン大学のエントリを参照するLDAP URL、次のとおりです。
ldap:///o=University%20of%20Michigan,c=US
LDAP：/// 0 =大学％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
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:
次の例は、ミシガン大学のエントリの唯一のPostalAddress属性を参照する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検索操作はのみのPostalAddress属性が要求されていることを除いて、前の例と同じです。
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サーバーを照会し、「バブスジェンセン」の共通名を持つすべてのエントリのためのミシガン大学のサブツリー検索を実行して見つかったエントリのセットを参照するLDAPのURLです：
ldap://ldap1.example.net:6666/o=University%20of%20Michigan, c=US??sub?(cn=Babs%20Jensen)
LDAP：//ldap1.example.net：？6666 / O =大学％20of％20Michigan、C = US ??サブ（CN =バブス％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属性は、エントリとともに返すことを要求され、そして「（オブジェクトクラス= *）」のデフォルトフィルタが使用されています。
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 =質問？、C = US」という名前のLDAPエントリのmail属性を取得するためのLDAPのURLです「？」。
ldap://ldap2.example.com/o=Question%3f,c=US?mail
LDAP：？//ldap2.example.com/o=Question%3f,c=USメール
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行に分割される）次の例では、フィルタ・引用機構とURL-引用機構のLDAP文字列表現との間の相互作用を示します。
ldap://ldap3.example.com/o=Babsco,c=US ???(four-octet=%5c00%5c00%5c00%5c04)
LDAP：//ldap3.example.com/o=Babsco,c=US ???（4オクテット=％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エスケープメカニズムを使用します。 LDAPでは、フィルタは、（4オクテット= \ 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-引用機構とURL-引用機構のLDAP文字列表現との間の相互作用を示します。
ldap://ldap.example.com/o=An%20Example%5C2C%20Inc.,c=US
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（株）、C = US
That is, the left-most RDN value is:
つまり、一番左のRDN値は次のとおりです。
An Example, 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
LDAP：/// ?? ??サブ電子BINDNAME = CN =マネージャ％の2cdc =例％2cdc = comのLDAP：/// ?? ??サブ電子BINDNAME = CN =マネージャ％の2cdc =例％2cdc =！コム
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は、第1の重要として電子BINDNAME拡張をマークしていることを除いて、同じです。電子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.
クライアントは、URLを介して、多くの異なるサーバーが発生する可能性がありますので、LDAP 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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]バーナーズ - リー、T.、フィールディング、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]クロッカー、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.、エド、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：技術仕様ロードマップ"。、RFC 4510、2006年6月。
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511] Sermersheim、J.、エド、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：プロトコル"、RFC 4511、2006年6月。
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006.
[RFC4512] Zeilenga、K.、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：ディレクトリ情報モデル"、RFC 4512、2006年6月。
[RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006.
[RFC4513]ハリソン、R.、エド、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：認証方法とセキュリティメカニズム"。、RFC 4513、2006年6月。
[RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006.
[RFC4514] Zeilenga、K.、エド、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：識別名の文字列表現"。、RFC 4514、2006年6月。
[RFC4515] Smith, M. Ed. and T. Howes, "Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters", RFC 4515, June 2006.
[RFC4515]スミス、M.編。そして、T.ハウズ、「ライトウェイトディレクトリアクセスプロトコル（LDAP）：検索フィルタの文字列表現」、RFC 4515、2006年6月。
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC2396]バーナーズ=リー、T.、フィールディング、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.、 "IANA（Internet Assigned Numbers Authority）のライトウェイトディレクトリアクセスプロトコル（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形式は、元々ミシガン大学で定義されました。この材料は、助成金番号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「ボブ」・モーガン、マーク・ワール、クルトZeilenga、ジムSermersheim、およびHallvard Furusethは彼らの貢献のために特別な感謝に値します。
Appendix A: Changes Since RFC 2255
付録A：RFC 2255からの変更点
A.1. Technical Changes
A.1。技術的な変更点
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).
[RFC3986]を参照して、[RFC2396]への参照を置き換える（これはリテラルIPv6はURLの<ホスト>部分内で使用されるようにアドレスでき、メモは、この拡張のリーダーを思い出させるために添加しました）。もはや[RFC3986]で定義されている作品が使用されないように、[RFC3986]を参照ABNFやテキストへの変更を必要としていました。例えば、<のHostPort> [RFC3986]で定義されていないので、ホスト[大腸ポート]で置換されています。 [RFC3986]は、文字の「予約済み」と「非予約」のセットのための新しい定義を含み、そして最終結果は、彼らがどこにでもLDAPのURLを構築するために使用されるデータで表示されたときに、次の二つの追加の文字はパーセントエンコードでなければならないことであることに注意してください：「[」と「]」（これらの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>、<ホスト>、<attrdesc>、および<exvalue>ルールで<散文-VAL>（括弧文字列）制作の回避使用。
Changed the ABNF for <ldapurl> to group the <dn> component with the preceding <SLASH>.
先行<SLASH>でグループに<LDAPURL>ため<DN>コンポーネントをABNFを変更しました。
Changed the <extype> rule to be an <oid> from [RFC4512].
[RFC4512]から<OID>すべき<extype>ルールを変更しました。
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拡張」：により知られている実装の不足のために削除されます。
A.2. Editorial Changes
A.2。編集上の変更
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サーバーに存在します」。文を削除し、「個々のattrdesc名は、[RFC4511]でのAttributeDescriptionのために定義された通りです。」 [RFC4511]の<attributeSelector>は現在ABNFに直接使用されるからです。文字をパーセントエンコードでなければならない明確にするために最後の段落を言い換えました。 LDAPのURLを参照して照会のために使用されていることを示すために、テキストを追加しました。清澄化RFC 4234.からABNFを参照し、（アプローチが今密接LDAPコントロールのために[RFC4511]で指定されたものと一致する）実装と拡張機能を実装しない含むURLの処理に関する要件を強化し、テキストを追加しました。
"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]で定義された特別な<alluserattrs>セレクタを参照して属性名「*」に置き換え直接参照「*」。
"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とexample.netのホスト名を使用します。不足している追加しました「？」そのフィルタ3つのNULLバイトが含まれているLDAP URLの例に。 DN内の1つのコンマの後にスペースを削除しました。電子BINDNAMEを使用するBINDNAME例を改訂。潜在的な混乱を避けるために、「4オクテット」に「INT」の一例で使用される属性の名前を変更しました。 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.
「謝辞」セクション：この文書はRFC 2255を追加しましたクルトZeilenga、ジムSermersheim、およびHallvard Furusethを廃止することを追加陳述。
"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のガイドラインに従って、「参考文献」から改名しました。文書全体[RFC4511]スタイルに、[1]スタイルに変更。追加しましたRFC 4234への参照およびRFC 3629.は、[RFC3986]内の適切なセクションを指すように、すべてのRFC 1738の参照を更新しました。 LDAPBis WG文書を参照するためにLDAP参照を更新しました。 LDAPへの参照は、構文の文書属性と[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博士は生理食塩水、MI 48176 USA
Phone: +1 734 944-2856 EMail: mcs@pearlcrescent.com
電話：+1 734 944-2856 Eメール：mcs@pearlcrescent.com
Tim Howes Opsware, Inc. 599 N. Mathilda Ave. Sunnyvale, CA 94085 USA
ティム・ハウズOpsware社、（株）599 N.マチルダアベニュー。サニーベール、CA 94085 USA
Phone: +1 408 744-7509 EMail: howes@opsware.com
電話：+1 408 744-7509 Eメール：howes@opsware.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。