[要約] RFC 2255は、LDAP URLの形式と目的についての仕様を提供しています。LDAP URLは、LDAPサーバーへのアクセスを容易にするために使用されます。
Network Working Group T. Howes
Request for Comments: 2255 M. Smith
Category: Standards Track Netscape Communications Corp.
December 1997
The LDAP URL Format
LDAP URL形式
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 (1997). All Rights Reserved.
Copyright（C）The Internet Society（1997）。全著作権所有。
IESG NOTE
IESGノート
This document describes a directory access protocol that provides both read and update access. Update access requires secure authentication, but this document does not mandate implementation of any satisfactory authentication mechanisms.
このドキュメントでは、読み取りアクセスと更新アクセスの両方を提供するディレクトリアクセスプロトコルについて説明します。更新アクセスには安全な認証が必要ですが、このドキュメントでは満足できる認証メカニズムの実装を義務付けていません。
In accordance with RFC 2026, section 4.4.1, this specification is being approved by IESG as a Proposed Standard despite this limitation, for the following reasons:
RFC 2026のセクション4.4.1に従って、この仕様は次の理由により、この制限にもかかわらず、提案された標準としてIESGによって承認されています。
a. to encourage implementation and interoperability testing of these protocols (with or without update access) before they are deployed, and
a。展開する前に、これらのプロトコルの実装と相互運用性テスト（更新アクセスありまたはなし）を促進するため。
b. to encourage deployment and use of these protocols in read-only applications. (e.g. applications where LDAPv3 is used as a query language for directories which are updated by some secure mechanism other than LDAP), and
b。読み取り専用アプリケーションでのこれらのプロトコルの導入と使用を促進するため。 （たとえば、LDAPv3がLDAP以外の安全なメカニズムによって更新されるディレクトリのクエリ言語として使用されるアプリケーション）、および
c. to avoid delaying the advancement and deployment of other Internet standards-track protocols which require the ability to query, but not update, LDAPv3 directory servers.
c。 LDAPv3ディレクトリサーバーを更新するのではなく、照会する機能を必要とする他のインターネット標準トラックプロトコルの進歩と展開の遅延を回避するため。
Readers are hereby warned that until mandatory authentication mechanisms are standardized, clients and servers written according to this specification which make use of update functionality are UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
読者は、必須の認証メカニズムが標準化されるまで、更新機能を利用するこの仕様に従って作成されたクライアントとサーバーは、相互運用が不可能であるか、認証が許容できない弱いレベルに低下した場合にのみ相互運用が可能であることを警告します。
Implementors are hereby discouraged from deploying LDAPv3 clients or servers which implement the update functionality, until a Proposed Standard for mandatory authentication in LDAPv3 has been approved and published as an RFC.
これにより、実装者は、LDAPv3での必須認証の提案された標準が承認され、RFCとして公開されるまで、更新機能を実装するLDAPv3クライアントまたはサーバーのデプロイを推奨しません。
LDAP is the Lightweight Directory Access Protocol, defined in [1], [2] and [3]. This document describes a format for an LDAP Uniform Resource Locator. The format describes an LDAP search operation to perform to retrieve information from an LDAP directory. This document replaces RFC 1959. It updates 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, so that future documents can extend their functionality, for example, to provide access to new LDAPv3 extensions as they are defined.
LDAPは、[1]、[2]、および[3]で定義されているライトウェイトディレクトリアクセスプロトコルです。このドキュメントでは、LDAP Uniform Resource Locatorの形式について説明します。この形式は、LDAPディレクトリから情報を取得するために実行するLDAP検索操作を記述します。このドキュメントはRFC 1959に代わるものです。LDAPのバージョン3のLDAP URL形式を更新し、LDAP URLの解決方法を明確にします。このドキュメントは、LDAP URLの拡張メカニズムも定義しているため、将来のドキュメントは、たとえば、定義されている新しいLDAPv3拡張機能へのアクセスを提供するなど、機能を拡張できます。
The key words "MUST", "MAY", and "SHOULD" used in this document are to be interpreted as described in [6].
このドキュメントで使用されているキーワード「MUST」、「MAY」、および「SHOULD」は、[6]で説明されているように解釈されます。
An LDAP URL begins with the protocol prefix "ldap" and is defined by the following grammar.
LDAP URLは、プロトコルプレフィックス「ldap」で始まり、次の文法で定義されます。
ldapurl = scheme "://" [hostport] ["/"
[dn ["?" [attributes] ["?" [scope]
["?" [filter] ["?" extensions]]]]]]
scheme = "ldap"
attributes = attrdesc *("," attrdesc)
scope = "base" / "one" / "sub"
dn = distinguishedName from Section 3 of [1]
hostport = hostport from Section 5 of RFC 1738 [5]
attrdesc = AttributeDescription from Section 4.1.5 of [2]
filter = filter from Section 4 of [4]
extensions = extension *("," extension)
extension = ["!"] extype ["=" exvalue]
extype = token / xtoken
exvalue = LDAPString from section 4.1.2 of [2]
token = oid from section 4.1 of [3]
xtoken = ("X-" / "x-") token
The "ldap" prefix indicates an entry or entries residing in the LDAP server running on the given hostname at the given portnumber. The default LDAP port is TCP port 389. If no hostport is given, the client must have some apriori knowledge of an appropriate LDAP server to contact.
「ldap」接頭辞は、指定されたポート番号の指定されたホスト名で実行されているLDAPサーバーに存在する1つまたは複数のエントリを示します。デフォルトのLDAPポートはTCPポート389です。ホストポートが指定されていない場合、クライアントは、接続する適切なLDAPサーバーについてある程度の知識を持っている必要があります。
The dn is an LDAP Distinguished Name using the string format described in [1]. It identifies the base object of the LDAP search.
dnは、[1]で説明されている文字列形式を使用したLDAP識別名です。これは、LDAP検索の基本オブジェクトを識別します。
ldapurl = scheme "://" [hostport] ["/"
[dn ["?" [attributes] ["?" [scope]
["?" [filter] ["?" extensions]]]]]]
scheme = "ldap"
attributes = attrdesc *("," attrdesc)
scope = "base" / "one" / "sub"
dn = distinguishedName from Section 3 of [1]
hostport = hostport from Section 5 of RFC 1738 [5]
attrdesc = AttributeDescription from Section 4.1.5 of [2]
filter = filter from Section 4 of [4]
extensions = extension *("," extension)
extension = ["!"] extype ["=" exvalue]
extype = token / xtoken
exvalue = LDAPString from section 4.1.2 of [2]
token = oid from section 4.1 of [3]
xtoken = ("X-" / "x-") token
The "ldap" prefix indicates an entry or entries residing in the LDAP server running on the given hostname at the given portnumber. The default LDAP port is TCP port 389. If no hostport is given, the client must have some apriori knowledge of an appropriate LDAP server to contact.
「ldap」接頭辞は、指定されたポート番号の指定されたホスト名で実行されているLDAPサーバーに存在する1つまたは複数のエントリを示します。デフォルトのLDAPポートはTCPポート389です。ホストポートが指定されていない場合、クライアントは、接続する適切なLDAPサーバーについてある程度の知識を持っている必要があります。
The dn is an LDAP Distinguished Name using the string format described in [1]. It identifies the base object of the LDAP search.
dnは、[1]で説明されている文字列形式を使用したLDAP識別名です。これは、LDAP検索の基本オブジェクトを識別します。
The attributes construct is used to indicate which attributes should be returned from the entry or entries. Individual attrdesc names are as defined for AttributeDescription in [2]. 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 (in LDAPv3) by requesting the special attribute name "*").
属性コンストラクトは、エントリから返される属性を示すために使用されます。個々のattrdesc名は、[2]のAttributeDescriptionで定義されているとおりです。属性部分が省略されている場合、1つまたは複数のエントリのすべてのユーザー属性を要求する必要があります（たとえば、LDAP検索要求の属性フィールドAttributeDescriptionListをNULLリストに設定するか、または（LDAPv3で）特別な属性名 "* "）。
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. If scope is omitted, a scope of "base" is assumed.
スコープ構成は、特定のLDAPサーバーで実行する検索のスコープを指定するために使用されます。許容範囲は、ベースオブジェクト検索の「ベース」、1レベル検索の「1」、またはサブツリー検索の「サブ」です。スコープを省略すると、「base」のスコープが想定されます。
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 [4]. If filter is omitted, a filter of "(objectClass=*)" is assumed.
フィルターは、検索中に指定されたスコープ内のエントリに適用する検索フィルターを指定するために使用されます。それは[4]で指定されたフォーマットを持っています。フィルターが省略された場合、「（objectClass = *）」のフィルターが想定されます。
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 LDAPv3 extension mechanisms. Extensions may be supported or unsupported by the client resolving the URL. An extension prefixed with a '!' character (ASCII 33) is critical. An extension not prefixed with a ' !' character is non-critical.
拡張コンストラクトはLDAP URLに拡張性メカニズムを提供し、URLの機能を将来拡張できるようにします。拡張機能は、type = valueペアの単純なコンマ区切りリストです。= valueの部分は、それを必要としないオプションの場合は省略できます。 type = valueの各ペアは個別の拡張です。これらのLDAP URL拡張は、必ずしもLDAPv3拡張メカニズムのいずれかに関連しているとは限りません。拡張機能は、URLを解決するクライアントによってサポートされている場合とサポートされていない場合があります。 「！」で始まる拡張子文字（ASCII 33）は重要です。 '！'が前に付いていない拡張文字は重要ではありません。
If an extension is supported by the client, the client MUST obey the extension if the extension is critical. The client SHOULD obey supported extensions that are non-critical.
拡張機能がクライアントによってサポートされている場合、拡張機能が重要な場合、クライアントは拡張機能に従う必要があります。クライアントは、重要ではないサポートされている拡張機能に従う必要があります（SHOULD）。
If an extension is unsupported by the client, the client MUST NOT process the URL if the extension is critical. If an unsupported extension is non-critical, the client MUST ignore the extension.
拡張機能がクライアントでサポートされていない場合、拡張機能が重要な場合、クライアントはURLを処理してはなりません（MUST NOT）。サポートされていない拡張機能が重要でない場合、クライアントは拡張機能を無視する必要があります。
If a critical extension cannot be processed successfully by the client, the client MUST NOT process the URL. If a non-critical extension cannot be processed successfully by the client, the client SHOULD ignore the extension.
重要な拡張機能がクライアントで正常に処理できない場合、クライアントはURLを処理してはなりません（MUST NOT）。重要でない拡張機能がクライアントで正常に処理できない場合、クライアントは拡張機能を無視する必要があります（SHOULD）。
Extension types prefixed by "X-" or "x-" are reserved for use in bilateral agreements between communicating parties. Other extension types MUST be defined in this document, or in other standards-track documents.
「X-」または「x-」で始まる拡張タイプは、通信する当事者間の二国間協定での使用のために予約されています。他の拡張タイプは、このドキュメントまたは他の標準化過程ドキュメントで定義されなければなりません。
One LDAP URL extension is defined in this document in the next section. Other documents or a future version of this document MAY define other extensions.
このドキュメントの次のセクションで、1つのLDAP URL拡張が定義されています。他のドキュメントまたはこのドキュメントの将来のバージョンでは、他の拡張機能が定義される可能性があります。
Note that any URL-illegal characters (e.g., spaces), URL special characters (as defined in section 2.2 of RFC 1738) and the reserved character '?' (ASCII 63) occurring inside a dn, filter, or other element of an LDAP URL MUST be escaped using the % method described in RFC 1738 [5]. If a comma character ',' occurs inside an extension value, the character MUST also be escaped using the % method.
URLが不正な文字（スペースなど）、URL特殊文字（RFC 1738のセクション2.2で定義）、予約文字「？」 （ASCII 63）LDAP URLのdn、フィルター、またはその他の要素内で発生する場合は、RFC 1738 [5]に記述されている％メソッドを使用してエスケープする必要があります。コンマ文字「、」が拡張値の内部にある場合、％メソッドを使用して文字をエスケープする必要もあります。
This section defines an LDAP URL extension for representing the distinguished name for a client to use when authenticating to an LDAP directory during resolution of an LDAP URL. Clients MAY implement this extension.
このセクションでは、LDAP URLの解決中にLDAPディレクトリへの認証時にクライアントが使用する識別名を表すためのLDAP URL拡張を定義します。クライアントはこの拡張機能を実装してもよい（MAY）。
The extension type is "bindname". The extension value is the distinguished name of the directory entry to authenticate as, in the same form as described for dn in the grammar above. The dn may be the NULL string to specify unauthenticated access. The extension may be either critical (prefixed with a '!' character) or non-critical (not prefixed with a '!' character).
拡張タイプは「バインド名」です。拡張値は、上記の文法のdnで説明したのと同じ形式で、認証するディレクトリエントリの識別名です。 dnは、認証されていないアクセスを指定するNULL文字列である場合があります。拡張子は、クリティカル（接頭辞が '！'文字）または非クリティカル（接頭辞が '！'文字ではない）のいずれかです。
If the bindname extension is critical, the client resolving the URL MUST authenticate to the directory using the given distinguished name and an appropriate authentication method. Note that for a NULL distinguished name, no bind MAY be required to obtain anonymous access to the directory. If the extension is non-critical, the client MAY bind to the directory using the given distinguished name.
bindname拡張子が重要な場合、URLを解決するクライアントは、指定された識別名と適切な認証方法を使用してディレクトリを認証する必要があります。 NULL識別名の場合、ディレクトリへの匿名アクセスを取得するためにバインドは必要ありません。拡張子が重要でない場合、クライアントは指定された識別名を使用してディレクトリにバインドしてもよい（MAY）。
This section describes how an LDAP URL SHOULD be resolved by a client.
このセクションでは、クライアントがLDAP URLを解決する方法を説明します。
First, the client obtains a connection to the LDAP server referenced in the URL, or an LDAP server of the client's choice if no LDAP server is explicitly referenced. This connection MAY be opened specifically for the purpose of resolving the URL or the client MAY reuse an already open connection. The connection MAY provide confidentiality, integrity, or other services, e.g., using TLS. Use of security services is at the client's discretion if not specified in the URL.
最初に、クライアントはURLで参照されているLDAPサーバーへの接続を取得します。LDAPサーバーが明示的に参照されていない場合は、クライアントが選択したLDAPサーバーへの接続を取得します。この接続は、特にURLを解決する目的で開かれる場合があります。そうでない場合、クライアントはすでに開いている接続を再利用できます（MAY）。接続は、機密性、完全性、またはTLSを使用するなどの他のサービスを提供する場合があります。 URLで指定されていない場合、セキュリティサービスの使用はクライアントの裁量に任されます。
Next, the client authenticates itself to the LDAP server. This step is optional, unless the URL contains a critical bindname extension with a non-NULL value. If a bindname extension is given, the client proceeds according to the section above.
次に、クライアントはLDAPサーバーに対して自身を認証します。 URLに非NULL値の重要なバインド名拡張が含まれていない限り、この手順はオプションです。 bindname拡張が指定されている場合、クライアントは上記のセクションに従って進みます。
If a bindname extension is not specified, the client MAY bind to the directory using a appropriate dn and authentication method of its own choosing (including NULL authentication).
bindname拡張子が指定されていない場合、クライアントは、適切なdnおよび独自に選択した認証方法（NULL認証を含む）を使用してディレクトリにバインドできます（MAY）。
Next, the client performs the LDAP search operation specified in the URL. Additional fields in the LDAP protocol search request, such as sizelimit, timelimit, deref, and anything else not specified or defaulted in the URL specification, MAY be set at the client's discretion.
次に、クライアントはURLで指定されたLDAP検索操作を実行します。 sizelimit、timelimit、deref、およびURL仕様で指定またはデフォルト設定されていないその他のものなど、LDAPプロトコル検索要求の追加フィールドは、クライアントの裁量で設定できます（MAY）。
Once the search has completed, the client MAY close the connection to the LDAP server, or the client MAY keep the connection open for future use.
検索が完了すると、クライアントはLDAPサーバーへの接続を閉じることができます。または、クライアントは将来の使用のために接続を開いたままにすることができます。
The following are some example LDAP URLs using 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://ldap.itd.umich.edu/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は両方とも、「（objectclass = *）」のフィルターを使用した「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://ldap.itd.umich.edu/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サーバーにクエリを実行し、ミシガン大学のサブツリー検索を実行して、「Babs Jensen」という一般名のエントリをすべて検索し、すべての属性を取得することで見つかったエントリのセットを参照するLDAP URLです。
ldap://host.com: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://ldap.itd.umich.edu/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" is given below, illustrating the use of the escaping mechanism on the reserved character '?'.
次の例は、「o = Question？、c = US」という名前のLDAPエントリのメール属性を取得するLDAP URLです。次に、予約文字「？」でのエスケープメカニズムの使用法を示します。
ldap://ldap.question.com/o=Question%3f,c=US?mail
The next example illustrates the interaction between LDAP and URL quoting mechanisms.
次の例は、LDAPとURLの引用メカニズム間の相互作用を示しています。
ldap://ldap.netscape.com/o=Babsco,c=US??(int=%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 (int=\00\00\00\04). Because the \ character must be escaped in a URL, the \'s are escaped as %5c in the URL encoding.
この例のフィルターは、\のLDAPエスケープメカニズムを使用して、値に3つのゼロまたはnullバイトをエンコードします。 LDAPでは、フィルターは（int = \ 00 \ 00 \ 00 \ 04）と記述されます。 \文字はURLでエスケープする必要があるため、\はURLエンコーディングでは％5cとしてエスケープされます。
The final example shows the use of the bindname extension to specify the dn a client should use for authentication when resolving the URL.
最後の例では、bindname拡張を使用して、URLを解決するときにクライアントが認証に使用する必要があるdnを指定しています。
ldap:///??sub??bindname=cn=Manager%2co=Foo
ldap:///??sub??!bindname=cn=Manager%2co=Foo
The two URLs are the same, except that the second one marks the bindname extension as critical. Notice the use of the % encoding method to encode the comma in the distinguished name value in the bindname extension.
2つのURLは同じですが、2番目のURLはbindname拡張をクリティカルとしてマークしています。 ％エンコード方式を使用して、bindname拡張機能の識別名の値にコンマをエンコードしていることに注意してください。
General URL security considerations discussed in [5] are relevant for LDAP URLs.
[5]で説明されている一般的な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 about which servers to connect to using which security mechanisms, and SHOULD NOT make connections that are inconsistent with this policy.
クライアントがURLを介して多くの異なるサーバーに遭遇する可能性があるため、およびURLはユーザーの介入なしに自動的に処理される可能性が高いため、LDAP URLを処理する際のセキュリティメカニズムの使用には特に注意が必要です。クライアントは、どのセキュリティメカニズムを使用してどのサーバーに接続するかに関するユーザー設定可能なポリシーを持ち、このポリシーと矛盾する接続を行うべきではありません（SHOULD）。
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 connection. (Note that clients conforming to previous LDAP URL specifications, where all connections are anonymous and unprotected, are consistent with this specification; they simply have the default security policy.)
メカニズムに関係なく、認証情報を送信すると、ユーザーのプライバシー要件に違反する可能性があります。認証情報をサーバーに送信することを許可する特定のポリシーがない場合、クライアントは匿名接続を使用する必要があります。 （すべての接続が匿名で保護されていない以前のLDAP 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 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.
一部の認証方法、特にサーバーに送信される再利用可能なパスワードは、悪用されやすい情報をリモートサーバーまたは送信中に盗聴する可能性があるため、ポリシーで明示的に許可されていない限り、URL処理で使用しないでください。人間のユーザーによる認証情報の使用の確認は、多くの状況で適切です。機密情報を公開しない強力な認証方法を使用することをお勧めします。
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, the initiation of a long-lived search, etc. 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をたどると、大量のデータの取得、長期間有効な検索の開始など、予期しない結果が生じる可能性があります。LDAPURLを解決することによるセキュリティ上の影響は、LDAP検索クエリを解決することと同じです。 。
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に基づいて全米科学財団が支援する研究に基づいています。ミシガン大学と全米科学財団の両方の支援に感謝します。
Several people have made valuable comments on this document. In particular RL "Bob" Morgan and Mark Wahl deserve special thanks for their contributions.
何人かの人々がこの文書に貴重なコメントをしました。特にRL "Bob" MorganとMark Wahlは、彼らの貢献に特に感謝するに値します。
[1] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997.
[1] Wahl、M.、Kille、S。、およびT. Howes、「Lightweight Directory Access Protocol（v3）：UTF-8 String Representation of Distinguished Names」、RFC 2253、1997年12月。
[2] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[2] Wahl、M.、Howes、T。、およびS. Kille、「Lightweight Directory Access Protocol（v3）」、RFC 2251、1997年12月。
[3] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997.
[3] Wahl、M.、Coulbeck、A.、Howes、T。およびS. Kille、「Lightweight Directory Access Protocol（v3）：Attribute Syntax Definitions」、RFC 2252、1997年12月。
[4] Howes, T., "A String Representation of LDAP Search Filters", RFC 2254, December 1997.
[4] ハウズT。、「LDAP検索フィルターの文字列表現」、RFC 2254、1997年12月。
[5] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)," RFC 1738, December 1994.
[5] Berners-Lee、T.、Masinter、L。およびM. McCahill、「Uniform Resource Locators（URL）」、RFC 1738、1994年12月。
[6] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels," RFC 2119, March 1997.
[6] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、RFC 2119、1997年3月。
Authors' Addresses
著者のアドレス
Tim Howes Netscape Communications Corp. 501 E. Middlefield Rd. Mountain View, CA 94043 USA
Tim Howes Netscape Communications Corp. 501 E. Middlefield Rd。 Mountain View、CA 94043 USA
Phone: +1 415 937-3419
EMail: howes@netscape.com
Mark Smith Netscape Communications Corp. 501 E. Middlefield Rd. Mountain View, CA 94043 USA
Mark Smith Netscape Communications Corp. 501 E. Middlefield Rd。 Mountain View、CA 94043 USA
Phone: +1 415 937-3477
EMail: mcs@netscape.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright（C）The Internet Society（1997）。全著作権所有。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。