Network Working Group J. Sermersheim, Ed.
Request for Comments: 4511 Novell, Inc.
Obsoletes: 2251, 2830, 3771 June 2006
Category: Standards Track
Lightweight Directory Access Protocol (LDAP): The Protocol
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 the protocol elements, along with their semantics and encodings, of the Lightweight Directory Access Protocol (LDAP). LDAP provides access to distributed directory services that act in accordance with X.500 data and service models. These protocol elements are based on those described in the X.500 Directory Access Protocol (DAP).
この文書では、Lightweight Directory Access Protocol（LDAP）のその意味とエンコーディングとともに、プロトコルの要素について説明します。 LDAPは、X.500データとサービスモデルに従って行動分散ディレクトリサービスへのアクセスを提供します。これらのプロトコル要素は、X.500ディレクトリアクセスプロトコル（DAP）に記載されたものに基づいています。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Relationship to Other LDAP Specifications ..................3
2. Conventions .....................................................3
3. Protocol Model ..................................................4
3.1. Operation and LDAP Message Layer Relationship ..............5
4. Elements of Protocol ............................................5
4.1. Common Elements ............................................5
4.1.1. Message Envelope ....................................6
4.1.2. String Types ........................................7
4.1.3. Distinguished Name and Relative Distinguished Name ..8
4.1.4. Attribute Descriptions ..............................8
4.1.5. Attribute Value .....................................8
4.1.6. Attribute Value Assertion ...........................9
4.1.7. Attribute and PartialAttribute ......................9
4.1.8. Matching Rule Identifier ...........................10
4.1.9. Result Message .....................................10
4.1.10. Referral ..........................................12
4.1.11. Controls ..........................................14
4.2. Bind Operation ............................................16
4.2.1. Processing of the Bind Request .....................17
4.2.2. Bind Response ......................................18
4.3. Unbind Operation ..........................................18
4.4. Unsolicited Notification ..................................19
4.4.1. Notice of Disconnection ............................19
4.5. Search Operation ..........................................20
4.5.1. Search Request .....................................20
4.5.2. Search Result ......................................27
4.5.3. Continuation References in the Search Result .......28
4.6. Modify Operation ..........................................31
4.7. Add Operation .............................................33
4.8. Delete Operation ..........................................34
4.9. Modify DN Operation .......................................34
4.10. Compare Operation ........................................36
4.11. Abandon Operation ........................................36
4.12. Extended Operation .......................................37
4.13. IntermediateResponse Message .............................39
4.13.1. Usage with LDAP ExtendedRequest and
ExtendedResponse ..................................40
4.13.2. Usage with LDAP Request Controls ..................40
4.14. StartTLS Operation .......................................40
4.14.1. StartTLS Request ..................................40
4.14.2. StartTLS Response .................................41
4.14.3. Removal of the TLS Layer ..........................41
5. Protocol Encoding, Connection, and Transfer ....................42
5.1. Protocol Encoding .........................................42
5.2. Transmission Control Protocol (TCP) .......................43
5.3. Termination of the LDAP session ...........................43
6. Security Considerations ........................................43
7. Acknowledgements ...............................................45
8. Normative References ...........................................46
9. Informative References .........................................48
10. IANA Considerations ...........................................48
Appendix A. LDAP Result Codes .....................................49
A.1. Non-Error Result Codes ....................................49
A.2. Result Codes ..............................................49
Appendix B. Complete ASN.1 Definition .............................54
Appendix C. Changes ...............................................60
C.1. Changes Made to RFC 2251 ..................................60
C.2. Changes Made to RFC 2830 ..................................66
C.3. Changes Made to RFC 3771 ..................................66
The Directory is "a collection of open systems cooperating to provide directory services" [X.500]. A directory user, which may be a human or other entity, accesses the Directory through a client (or Directory User Agent (DUA)). The client, on behalf of the directory user, interacts with one or more servers (or Directory System Agents (DSA)). Clients interact with servers using a directory access protocol.
ディレクトリは、[X.500]「ディレクトリサービスを提供するために協力し、オープンシステムの集合」です。ヒトまたは他のエンティティであってもよいディレクトリ・ユーザーは、クライアント（またはディレクトリユーザーエージェント（DUA））を介してディレクトリにアクセスします。クライアントは、ディレクトリユーザーの代わりに、1つ以上のサーバ（またはディレクトリシステムエージェント（DSA））と対話します。クライアントは、ディレクトリアクセスプロトコルを使用してサーバーと対話します。
This document details the protocol elements of the Lightweight Directory Access Protocol (LDAP), along with their semantics. Following the description of protocol elements, it describes the way in which the protocol elements are encoded and transferred.
この文書では、その意味と一緒に、ライトウェイトディレクトリアクセスプロトコル（LDAP）のプロトコル要素を詳しく説明しています。プロトコル要素の説明以下は、プロトコル要素を符号化して転送される方法を記載しています。
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, together with [RFC4510], [RFC4513], and [RFC4512], obsoletes RFC 2251 in its entirety. Section 3.3 is obsoleted by [RFC4510]. Sections 4.2.1 (portions) and 4.2.2 are obsoleted by [RFC4513]. Sections 3.2, 3.4, 4.1.3 (last paragraph), 4.1.4, 4.1.5, 4.1.5.1, 4.1.9 (last paragraph), 5.1, 6.1, and 6.2 (last paragraph) are obsoleted by [RFC4512]. The remainder of RFC 2251 is obsoleted by this document. Appendix C.1 summarizes substantive changes in the remainder.
この、一緒に[RFC4513]、[RFC4510]と文書、および[RFC4512]は、その全体がRFC 2251を時代遅れ。セクション3.3は、[RFC4510]によって廃止されています。セクション4.2.1（部分）および4.2.2は、[RFC4513]によって廃止されています。セクション3.2、3.4、4.1.3（最後の段落）、4.1.4、4.1.5、4.1.5.1、4.1.9（最後の段落）、5.1、6.1、および6.2（最後の段落）は[RFC4512]によって廃止されています。 RFC 2251の残りの部分は、この文書により廃止されます。付録C.1は残りにおける実質的な変化をまとめたもの。
This document obsoletes RFC 2830, Sections 2 and 4. The remainder of RFC 2830 is obsoleted by [RFC4513]. Appendix C.2 summarizes substantive changes to the remaining sections.
この文書は、RFC 2830を時代遅れセクション2,4 RFC 2830の残りの部分は、[RFC4513]によって廃止されます。付録C.2は、残りのセクションへの実質的な変更をまとめました。
This document also obsoletes RFC 3771 in entirety.
この文書はまた、全体的にRFC 3771を廃止します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in [RFC2119].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHOULD"、 "ないもの"、 "推奨" "ない（SHOULD NOT）"、および本文書にように解釈されるべきであり、 "MAY" [RFC2119]で説明。
Character names in this document use the notation for code points and names from the Unicode Standard [Unicode]. For example, the letter "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
この文書における文字の名前は、Unicode標準[UNICODE]のコードポイントと名の表記を使用します。例えば、文字 "は" <LATIN SMALL LETTER A> <U + 0061>のいずれかとして表されてもよいです。
Note: a glossary of terms used in Unicode can be found in [Glossary]. Information on the Unicode character encoding model can be found in [CharModel].
注：Unicodeで使用される用語の用語集は、[用語]に見出すことができます。 Unicode文字エンコーディングモデルに関する情報は、[CharModel]で見つけることができます。
The term "transport connection" refers to the underlying transport services used to carry the protocol exchange, as well as associations established by these services.
用語「トランスポート接続」は、基礎となるトランスポートプロトコル交換を運ぶために使用されるサービス、ならびにこれらのサービスによって確立されたアソシエーションを指します。
The term "TLS layer" refers to Transport Layer Security (TLS) services used in providing security services, as well as associations established by these services.
用語「TLS層は、」層セキュリティ（TLS）のセキュリティサービスを提供する際に使用サービス、ならびにこれらのサービスによって確立された関連付けを輸送するために参照します。
The term "SASL layer" refers to Simply Authentication and Security Layer (SASL) services used in providing security services, as well as associations established by these services.
用語「SASL層は」単純認証とセキュリティ層（SASL）セキュリティサービスの提供に使用されるサービス、ならびにこれらのサービスによって確立された団体を指します。
The term "LDAP message layer" refers to the LDAP Message Protocol Data Unit (PDU) services used in providing directory services, as well as associations established by these services.
用語「LDAPメッセージ層」は、LDAPメッセージプロトコルデータユニット（PDU）のディレクトリ・サービスを提供する際に使用されるサービス、ならびにこれらのサービスによって確立されたアソシエーションを指します。
The term "LDAP session" refers to combined services (transport connection, TLS layer, SASL layer, LDAP message layer) and their associations.
用語「LDAPセッションは、」複合サービス（トランスポート接続、TLS層、SASL層、LDAPメッセージ層）とその関連付けを指します。
See the table in Section 5 for an illustration of these four terms.
これら四つの用語の説明のために第5節の表を参照してください。
The general model adopted by this protocol is one of clients performing protocol operations against servers. In this model, a client transmits a protocol request describing the operation to be performed to a server. The server is then responsible for performing the necessary operation(s) in the Directory. Upon completion of an operation, the server typically returns a response containing appropriate data to the requesting client.
このプロトコルによって採用された一般的なモデルは、サーバに対するプロトコル操作を実行するクライアントの一つです。このモデルでは、クライアントは、サーバに実行される動作を説明するプロトコル要求を送信します。次に、サーバはディレクトリに必要な操作を実行する責任があります。操作が完了すると、サーバは、典型的には、要求元のクライアントに適切なデータを含む応答を返します。
Protocol operations are generally independent of one another. Each operation is processed as an atomic action, leaving the directory in a consistent state.
プロトコル動作は、互いに概ね独立しています。各操作は、一貫した状態にディレクトリを残して、アトミック動作として処理されます。
Although servers are required to return responses whenever such responses are defined in the protocol, there is no requirement for synchronous behavior on the part of either clients or servers. Requests and responses for multiple operations generally may be exchanged between a client and server in any order. If required, synchronous behavior may be controlled by client applications.
サーバがそのような応答は、プロトコルで定義されるたびに応答を返すために必要とされていますが、クライアントまたはサーバのいずれかの一部の同期動作のための必要はありません。複数の操作のための要求と応答は、一般的にどのような順序で、クライアントとサーバ間で交換することができます。必要であれば、同期動作は、クライアントアプリケーションによって制御することができます。
The core protocol operations defined in this document can be mapped to a subset of the X.500 (1993) Directory Abstract Service [X.511]. However, there is not a one-to-one mapping between LDAP operations and X.500 Directory Access Protocol (DAP) operations. Server implementations acting as a gateway to X.500 directories may need to make multiple DAP requests to service a single LDAP request.
この文書で定義されたコアプロトコル操作はX.500（1993）ディレクトリ抽象サービス[X.511]のサブセットにマッピングすることができます。ただし、LDAP操作とX.500ディレクトリアクセスプロトコル（DAP）の操作の間に1対1のマッピングがありません。 X.500ディレクトリへのゲートウェイとして動作するサーバ実装は、単一のLDAP要求にサービスを提供するために、複数のDAP要求を作成する必要があるかもしれません。
Protocol operations are exchanged at the LDAP message layer. When the transport connection is closed, any uncompleted operations at the LDAP message layer are abandoned (when possible) or are completed without transmission of the response (when abandoning them is not possible). Also, when the transport connection is closed, the client MUST NOT assume that any uncompleted update operations have succeeded or failed.
プロトコル操作は、LDAPメッセージ層で交換されています。輸送接続が閉じられるとき、LDAPメッセージ層での未完了の操作は、（それらを放棄する場合は不可能である）放棄される（可能な場合）または応答を送信せずに終了します。トランスポート接続が閉じているときにも、クライアントが未完了の更新操作が成功したか失敗したと仮定してはいけません。
The protocol is described using Abstract Syntax Notation One ([ASN.1]) and is transferred using a subset of ASN.1 Basic Encoding Rules ([BER]). Section 5 specifies how the protocol elements are encoded and transferred.
プロトコルは、抽象構文記法1（[ASN.1]）を用いて説明するとASN.1基本符号化規則（[BER]）のサブセットを使用して転送されます。セクション5は、プロトコル要素は、符号化され、転送される方法を指定します。
In order to support future extensions to this protocol, extensibility is implied where it is allowed per ASN.1 (i.e., sequence, set, choice, and enumerated types are extensible). In addition, ellipses (...) have been supplied in ASN.1 types that are explicitly extensible as discussed in [RFC4520]. Because of the implied extensibility, clients and servers MUST (unless otherwise specified) ignore trailing SEQUENCE components whose tags they do not recognize.
このプロトコルの将来の拡張をサポートするために、それはASN.1ごとに許可される拡張性を暗示される（即ち、シーケンス、設定、選択、および列挙型は拡張可能です）。また、省略記号（...）は[RFC4520]で議論するように明示的に拡張可能であるASN.1タイプで供給されてきました。 （特に指定のない限り）ので、暗黙の拡張性、クライアントとサーバのそのタグが、彼らが認識しないSEQUENCEコンポーネントを末尾無視しなければなりません。
Changes to the protocol other than through the extension mechanisms described here require a different version number. A client indicates the version it is using as part of the BindRequest, described in Section 4.2. If a client has not sent a Bind, the server MUST assume the client is using version 3 or later.
ここで説明する拡張メカニズムを介して以外のプロトコルへの変更は、異なるバージョン番号を必要とします。クライアントは、セクション4.2に記載BindRequestの一部として使用されているバージョンを示しています。クライアントがバインドを送信していない場合は、サーバーは、クライアントがバージョン3以降を使用している仮定しなければなりません。
Clients may attempt to determine the protocol versions a server supports by reading the 'supportedLDAPVersion' attribute from the root DSE (DSA-Specific Entry) [RFC4512].
クライアントは、ルートDSE（DSA固有のエントリ）から「supportedLDAPVersion」属性[RFC4512]を読み取ることによって、サーバがサポートするプロトコルバージョンを決定しようと試みることができます。
This section describes the LDAPMessage envelope Protocol Data Unit (PDU) format, as well as data type definitions, which are used in the protocol operations.
このセクションでは、プロトコル操作に使用されたLDAPMessageエンベローププロトコルデータユニット（PDU）フォーマット、ならびにデータ型定義を記載しています。
For the purposes of protocol exchanges, all protocol operations are encapsulated in a common envelope, the LDAPMessage, which is defined as follows:
プロトコル交換の目的のために、すべてのプロトコル操作は、共通のエンベロープ中に封入されている、として定義されたLDAPMessageは、以下：
LDAPMessage ::= SEQUENCE {
messageID MessageID,
protocolOp CHOICE {
bindRequest BindRequest,
bindResponse BindResponse,
unbindRequest UnbindRequest,
searchRequest SearchRequest,
searchResEntry SearchResultEntry,
searchResDone SearchResultDone,
searchResRef SearchResultReference,
modifyRequest ModifyRequest,
modifyResponse ModifyResponse,
addRequest AddRequest,
addResponse AddResponse,
delRequest DelRequest,
delResponse DelResponse,
modDNRequest ModifyDNRequest,
modDNResponse ModifyDNResponse,
compareRequest CompareRequest,
compareResponse CompareResponse,
abandonRequest AbandonRequest,
extendedReq ExtendedRequest,
extendedResp ExtendedResponse,
...,
intermediateResponse IntermediateResponse },
controls [0] Controls OPTIONAL }
MessageID ::= INTEGER (0 .. maxInt)
maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
The ASN.1 type Controls is defined in Section 4.1.11.
ASN.1型のコントロールセクション4.1.11で定義されています。
The function of the LDAPMessage is to provide an envelope containing common fields required in all protocol exchanges. At this time, the only common fields are the messageID and the controls.
たLDAPMessageの機能は、すべてのプロトコル交換に必要な共通のフィールドを含むエンベロープを提供することです。この時点では、唯一の共通のフィールドは、メッセージIDとコントロールされています。
If the server receives an LDAPMessage from the client in which the LDAPMessage SEQUENCE tag cannot be recognized, the messageID cannot be parsed, the tag of the protocolOp is not recognized as a request, or the encoding structures or lengths of data fields are found to be incorrect, then the server SHOULD return the Notice of Disconnection described in Section 4.4.1, with the resultCode set to protocolError, and MUST immediately terminate the LDAP session as described in Section 5.3.
サーバがたLDAPMessage配列タグを認識できないクライアントからたLDAPMessageを受信した場合、メッセージIDが解析できない、protocolOpのタグが要求として認識されない、またはデータフィールドの符号化構造または長さがあることが見出されています間違って、その後、サーバは切断の通知を返すべきではProtocolErrorに設定にresultCodeと、セクション4.4.1で説明し、5.3節で説明したように、すぐにLDAPセッションを終えなければなりません。
In other cases where the client or server cannot parse an LDAP PDU, it SHOULD abruptly terminate the LDAP session (Section 5.3) where further communication (including providing notice) would be pernicious. Otherwise, server implementations MUST return an appropriate response to the request, with the resultCode set to protocolError.
クライアントまたはサーバがLDAP PDUを解析することができない他の場合には、急激に（通知を提供することを含む）、さらに通信は有害であろうLDAPセッション（第5.3節）を終了すべきです。そうでない場合は、サーバ実装がはProtocolErrorに設定のresultCodeと、要求に適切な応答を返さなければなりません。
All LDAPMessage envelopes encapsulating responses contain the messageID value of the corresponding request LDAPMessage.
回答をカプセル化するすべてのたLDAPMessage封筒が対応する要求たLDAPMessageのmessageIDの値が含まれています。
The messageID of a request MUST have a non-zero value different from the messageID of any other request in progress in the same LDAP session. The zero value is reserved for the unsolicited notification message.
要求のメッセージIDは、同じLDAPセッションで進行中の任意の他の要求のメッセージIDとは異なる非ゼロ値を有しなければなりません。ゼロ値は、未承諾の通知メッセージのために予約されています。
Typical clients increment a counter for each request.
典型的なクライアントは、要求ごとにカウンタをインクリメント。
A client MUST NOT send a request with the same messageID as an earlier request in the same LDAP session unless it can be determined that the server is no longer servicing the earlier request (e.g., after the final response is received, or a subsequent Bind completes). Otherwise, the behavior is undefined. For this purpose, note that Abandon and successfully abandoned operations do not send responses.
最終的な応答を受信した後、サーバがもはや以前の要求（例えばにサービスを提供していると判断できない、またはそれ以降のバインドが完了しない限り、クライアントが同じLDAPセッションで以前の要求と同じメッセージIDとリクエストを送ってはいけません）。そうでなければ、動作は未定義です。この目的のために、放棄され、正常操作を放棄したメモが応答を送信しません。
The LDAPString is a notational convenience to indicate that, although strings of LDAPString type encode as ASN.1 OCTET STRING types, the [ISO10646] character set (a superset of [Unicode]) is used, encoded following the UTF-8 [RFC3629] algorithm. Note that Unicode characters U+0000 through U+007F are the same as ASCII 0 through 127, respectively, and have the same single octet UTF-8 encoding. Other Unicode characters have a multiple octet UTF-8 encoding.
ASN.1オクテット文字列型、[ISO10646]文字セット（[UNICODE]のスーパーセット）としてLDAPString型エンコードの文字列はUTF-8 [RFC3629]以下の符号化され、使用されているがLDAPStringは、それを示すために表記上の便宜でありますアルゴリズム。 U + 007Fを介して、ユニコード文字U + 0000は、それぞれ、127を介してASCII 0と同じであり、同一の単一オクテットUTF-8エンコーディングを有することに留意されたいです。その他のUnicode文字には、複数のオクテットUTF-8エンコーディングを持っています。
LDAPString ::= OCTET STRING -- UTF-8 encoded,
-- [ISO10646] characters
The LDAPOID is a notational convenience to indicate that the permitted value of this string is a (UTF-8 encoded) dotted-decimal representation of an OBJECT IDENTIFIER. Although an LDAPOID is encoded as an OCTET STRING, values are limited to the definition of <numericoid> given in Section 1.4 of [RFC4512].
LDAPOIDは、この文字列の許容値は、オブジェクト識別子（UTF-8でエンコードされた）ドット付き10進表記であることを示す表記上の便宜です。 LDAPOIDはOCTET STRINGとして符号化されるが、値は[RFC4512]のセクション1.4で与えられた<numericoid>の定義に限定されます。
LDAPOID ::= OCTET STRING -- Constrained to <numericoid>
-- [RFC4512]
For example,
例えば、
An LDAPDN is defined to be the representation of a Distinguished Name (DN) after encoding according to the specification in [RFC4514].
LDAPDNは[RFC4514]の指定に応じて符号化した後、識別名（DN）の表現であると定義されます。
LDAPDN ::= LDAPString
-- Constrained to <distinguishedName> [RFC4514]
A RelativeLDAPDN is defined to be the representation of a Relative Distinguished Name (RDN) after encoding according to the specification in [RFC4514].
RelativeLDAPDNは[RFC4514]の指定に応じて符号化した後、相対識別名（RDN）の表現であると定義されます。
RelativeLDAPDN ::= LDAPString
-- Constrained to <name-component> [RFC4514]
The definition and encoding rules for attribute descriptions are defined in Section 2.5 of [RFC4512]. Briefly, an attribute description is an attribute type and zero or more options.
属性記述の定義と符号化規則は、[RFC4512]のセクション2.5で定義されています。簡単に言えば、属性記述は、属性タイプと、ゼロ以上のオプションです。
AttributeDescription ::= LDAPString
-- Constrained to <attributedescription>
-- [RFC4512]
A field of type AttributeValue is an OCTET STRING containing an encoded attribute value. The attribute value is encoded according to the LDAP-specific encoding definition of its corresponding syntax. The LDAP-specific encoding definitions for different syntaxes and attribute types may be found in other documents and in particular [RFC4517].
AttributeValueのタイプのフィールドは、符号化された属性値を含むオクテット文字列です。属性値は、その対応する構文のLDAP固有のエンコーディング定義に従って符号化されます。異なる構文と属性タイプのLDAP固有の符号化の定義は、他の文献に、特に[RFC4517]に見出すことができます。
AttributeValue ::= OCTET STRING
Note that there is no defined limit on the size of this encoding; thus, protocol values may include multi-megabyte attribute values (e.g., photographs).
このエンコーディングのサイズに定義された制限がないことに注意してください。従って、プロトコル値は、マルチメガバイトの属性値（例えば、写真）を含んでもよいです。
Attribute values may be defined that have arbitrary and non-printable syntax. Implementations MUST NOT display or attempt to decode an attribute value if its syntax is not known. The implementation may attempt to discover the subschema of the source entry and to retrieve the descriptions of 'attributeTypes' from it [RFC4512].
属性値は任意と非印刷可能な構文を持つように定義することができます。実装は、表示したり、その構文が知られていない場合は、属性値をデコードするのを試みてはいけません。実装は、[RFC4512]ソースエントリのサブスキーマを発見し、それから「attributeTypes属性」の記述を取得するために試みることができます。
Clients MUST only send attribute values in a request that are valid according to the syntax defined for the attributes.
クライアントは、属性のみのために定義された構文に応じて有効な要求に属性値を送らなければなりません。
The AttributeValueAssertion (AVA) type definition is similar to the one in the X.500 Directory standards. It contains an attribute description and a matching rule ([RFC4512], Section 4.1.3) assertion value suitable for that type. Elements of this type are typically used to assert that the value in assertionValue matches a value of an attribute.
AttributeValueAssertion（AVA）の定義を入力するには、X.500ディレクトリ規格のものと類似しています。そのタイプに適した属性記述とマッチングルール（[RFC4512]、セクション4.1.3）アサーション値を含みます。このタイプの要素は、典型的AssertionValueの中に値が属性の値と一致していることを主張するために使用されています。
AttributeValueAssertion ::= SEQUENCE {
attributeDesc AttributeDescription,
assertionValue AssertionValue }
AssertionValue ::= OCTET STRING
The syntax of the AssertionValue depends on the context of the LDAP operation being performed. For example, the syntax of the EQUALITY matching rule for an attribute is used when performing a Compare operation. Often this is the same syntax used for values of the attribute type, but in some cases the assertion syntax differs from the value syntax. See objectIdentiferFirstComponentMatch in [RFC4517] for an example.
AssertionValueのの構文は、実行されるLDAP操作のコンテキストに依存します。比較動作を行う場合、例えば、属性の等価マッチングルールの構文が使用されています。多くの場合、これは、属性タイプの値のために使用されるのと同じ構文ですが、いくつかのケースでは、アサーション構文は値の構文とは異なります。例えば、[RFC4517]でobjectIdentiferFirstComponentMatch参照してください。
Attributes and partial attributes consist of an attribute description and attribute values. A PartialAttribute allows zero values, while Attribute requires at least one value.
属性と部分的な属性は属性記述と属性値で構成されています。属性が少なくとも1つの値を必要とするPartialAttributeは、ゼロ値を可能にします。
PartialAttribute ::= SEQUENCE {
type AttributeDescription,
vals SET OF value AttributeValue }
Attribute ::= PartialAttribute(WITH COMPONENTS {
...,
vals (SIZE(1..MAX))})
No two of the attribute values may be equivalent as described by Section 2.2 of [RFC4512]. The set of attribute values is unordered. Implementations MUST NOT rely upon the ordering being repeatable.
[RFC4512]のセクション2.2により記載されたように、属性値のどの2つは等価でなくてもよいです。属性値の集合は順不同です。実装は順序が再現可能であることに依存してはなりません。
Matching rules are defined in Section 4.1.3 of [RFC4512]. A matching rule is identified in the protocol by the printable representation of either its <numericoid> or one of its short name descriptors [RFC4512], e.g., 'caseIgnoreMatch' or '2.5.13.2'.
マッチングルールは、[RFC4512]のセクション4.1.3で定義されています。マッチングルールは、いずれかの<numericoid>またはその短い名前記述子の一つ[RFC4512]、例えば、「caseIgnoreMatch」または「2.5.13.2」の印刷可能な表現によってプロトコルで識別されます。
MatchingRuleId ::= LDAPString
The LDAPResult is the construct used in this protocol to return success or failure indications from servers to clients. To various requests, servers will return responses containing the elements found in LDAPResult to indicate the final status of the protocol operation request.
LDAPResultはサーバからクライアントに成功または失敗の表示を戻すには、このプロトコルで使用される構造です。様々な要求に、サーバは、プロトコル操作要求の最終ステータスを示すために、LDAPResultで見つかった要素を含む応答を返します。
LDAPResult ::= SEQUENCE {
resultCode ENUMERATED {
success (0),
operationsError (1),
protocolError (2),
timeLimitExceeded (3),
sizeLimitExceeded (4),
compareFalse (5),
compareTrue (6),
authMethodNotSupported (7),
strongerAuthRequired (8),
-- 9 reserved --
referral (10),
adminLimitExceeded (11),
unavailableCriticalExtension (12),
confidentialityRequired (13),
saslBindInProgress (14),
noSuchAttribute (16),
undefinedAttributeType (17),
inappropriateMatching (18),
constraintViolation (19),
attributeOrValueExists (20),
invalidAttributeSyntax (21),
-- 22-31 unused --
noSuchObject (32),
aliasProblem (33),
invalidDNSyntax (34),
-- 35 reserved for undefined isLeaf --
aliasDereferencingProblem (36),
-- 37-47 unused --
inappropriateAuthentication (48),
invalidCredentials (49),
insufficientAccessRights (50),
busy (51),
unavailable (52),
unwillingToPerform (53),
loopDetect (54),
-- 55-63 unused --
namingViolation (64),
objectClassViolation (65),
notAllowedOnNonLeaf (66),
notAllowedOnRDN (67),
entryAlreadyExists (68),
objectClassModsProhibited (69),
-- 70 reserved for CLDAP --
affectsMultipleDSAs (71),
-- 72-79 unused --
other (80),
... },
matchedDN LDAPDN,
diagnosticMessage LDAPString,
referral [3] Referral OPTIONAL }
The resultCode enumeration is extensible as defined in Section 3.8 of [RFC4520]. The meanings of the listed result codes are given in Appendix A. If a server detects multiple errors for an operation, only one result code is returned. The server should return the result code that best indicates the nature of the error encountered. Servers may return substituted result codes to prevent unauthorized disclosures.
[RFC4520]のセクション3.8で定義されている結果コード列挙は拡張可能です。サーバは、操作のための複数のエラーを検出すると記載されている結果コードの意味は、付録Aに記載されている、唯一の結果コードが返されます。サーバーは、最高発生したエラーの性質を示す結果コードを返す必要があります。サーバーは、不正な開示を防ぐために、置換結果コードを返すことがあります。
The diagnosticMessage field of this construct may, at the server's option, be used to return a string containing a textual, human-readable diagnostic message (terminal control and page formatting characters should be avoided). As this diagnostic message is not standardized, implementations MUST NOT rely on the values returned. Diagnostic messages typically supplement the resultCode with additional information. If the server chooses not to return a textual diagnostic, the diagnosticMessage field MUST be empty.
この構築物のdiagnosticMessageフィールドは、サーバーのオプションで、原文を含む文字列を返すために使用することができる、人間が読み取り可能な診断メッセージ（書式文字端末制御とページは避けるべきです）。この診断メッセージが標準化されていないため、実装が返された値に依存してはなりません。診断メッセージは、通常、追加情報のresultCodeを補足します。サーバが診断のテキストを返すことがないことを選択した場合、diagnosticMessageフィールドが空である必要があります。
For certain result codes (typically, but not restricted to noSuchObject, aliasProblem, invalidDNSyntax, and aliasDereferencingProblem), the matchedDN field is set (subject to access controls) to the name of the last entry (object or alias) used in finding the target (or base) object. This will be a truncated form of the provided name or, if an alias was dereferenced while attempting to locate the entry, of the resulting name. Otherwise, the matchedDN field is empty.
特定の結果コード（典型的には、しかしnoSuchObject、aliasProblem、invalidDNSyntax、及びaliasDereferencingProblemに限定されない）ため、matchedDNフィールドは（ターゲットを見つけるために使用される最後のエントリ（オブジェクトまたはエイリアス）の名前に（アクセス制御の対象）に設定されていますまたはベース）オブジェクト。これは、得られた名前のエントリを検索しようとした際に別名を間接参照している場合、提供された名前の短縮形であるかであろう。それ以外の場合は、matchedDNフィールドは空です。
The referral result code indicates that the contacted server cannot or will not perform the operation and that one or more other servers may be able to. Reasons for this include:
照会結果コードは、連絡サーバーがまたは操作を実行すると1つまたは複数の他のサーバーのことができるようにことがないであろうことはできないことを示しています。この理由は、次のとおりです。
- The target entry of the request is not held locally, but the server has knowledge of its possible existence elsewhere.
- 要求のターゲットエントリは、ローカルに保持されていないが、サーバーは他の場所でその存在の可能性についての知識を持っています。
- The operation is restricted on this server -- perhaps due to a read-only copy of an entry to be modified.
- 操作は、このサーバー上で制限されている - 修正するエントリの読み取り専用コピーにおそらく。
The referral field is present in an LDAPResult if the resultCode is set to referral, and it is absent with all other result codes. It contains one or more references to one or more servers or services that may be accessed via LDAP or other protocols. Referrals can be returned in response to any operation request (except Unbind and Abandon, which do not have responses). At least one URI MUST be present in the Referral.
resultCodeが照会に設定されている場合、照会フィールドはLDAPResultに存在し、それは、他のすべての結果コードで存在しません。これは、LDAPまたは他のプロトコルを介してアクセスすることができる1つまたは複数のサーバーやサービスへの1つまたは複数の参照が含まれています。紹介は、任意の操作要求（バインド解除を除くと応答を持たない、放棄）に対応して返すことができます。少なくとも1つのURIは、紹介中に存在しなければなりません。
During a Search operation, after the baseObject is located, and entries are being evaluated, the referral is not returned. Instead, continuation references, described in Section 4.5.3, are returned when other servers would need to be contacted to complete the operation.
baseObjectが配置され、かつエントリが評価された後に検索動作時には、紹介は返されません。他のサーバーは、操作を完了するために連絡する必要があるだろうというとき代わりに、4.5.3項で説明した継続参照は、返されます。
Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
URI ::= LDAPString -- limited to characters permitted in
-- URIs
If the client wishes to progress the operation, it contacts one of the supported services found in the referral. If multiple URIs are present, the client assumes that any supported URI may be used to progress the operation.
クライアントが操作を進行することを希望する場合は、その連絡先の紹介で見つかったサポートされているサービスの一つ。複数のURIが存在する場合、クライアントはサポートされている任意のURIが操作を進行するために使用することができることを前提としています。
Clients that follow referrals MUST ensure that they do not loop between servers. They MUST NOT repeatedly contact the same server for the same request with the same parameters. Some clients use a counter that is incremented each time referral handling occurs for an operation, and these kinds of clients MUST be able to handle at least ten nested referrals while progressing the operation.
紹介に従うクライアントは、サーバー間でループしないことを保証しなければなりません。彼らは、繰り返し同じパラメータで同じ要求のために、同じサーバに問い合わせてはなりません。一部のクライアントは、紹介取り扱いが操作のために発生するたびにインクリメントされるカウンタを使用して、クライアントのこれらの種類は、操作を進めながら、少なくとも10のネストされた照会を処理できなければなりません。
A URI for a server implementing LDAP and accessible via TCP/IP (v4 or v6) [RFC793][RFC791] is written as an LDAP URL according to [RFC4516].
サーバ実装LDAP用URIおよびTCP / IP（V4またはV6）[RFC793] [RFC791] [RFC4516]に従ってLDAP URLとして書かれているを介してアクセス可能。
Referral values that are LDAP URLs follow these rules:
LDAPのURLです紹介値は、これらの規則に従います。
- If an alias was dereferenced, the <dn> part of the LDAP URL MUST be present, with the new target object name.
- エイリアスが実名参照された場合は、LDAPのURLの<DN>の部分は、新しいターゲットオブジェクト名で、存在しなければなりません。
- It is RECOMMENDED that the <dn> part be present to avoid ambiguity.
- <DN>の部分はあいまいさを避けるために存在することをお勧めします。
- If the <dn> part is present, the client uses this name in its next request to progress the operation, and if it is not present the client uses the same name as in the original request.
- <DN>の部分が存在する場合、クライアントは操作を進行するという次の要求でこの名前を使用し、それが存在しない場合、クライアントは、元の要求と同じ名前を使用しています。
- Some servers (e.g., participating in distributed indexing) may provide a different filter in a URL of a referral for a Search operation.
- いくつかのサーバ（例えば、分散インデックスに参加して）検索操作のための紹介のURLに異なるフィルタを提供することができます。
- If the <filter> part of the LDAP URL is present, the client uses this filter in its next request to progress this Search, and if it is not present the client uses the same filter as it used for that Search.
- LDAPのURLの<フィルタ>部分が存在する場合、クライアントは、この検索を進行するという次の要求で、このフィルタを使用し、それが存在しない場合、それはその検索に使用すると、クライアントは同じフィルタを使用しています。
- For Search, it is RECOMMENDED that the <scope> part be present to avoid ambiguity.
- 検索のために、<スコープ>の部分はあいまいさを避けるために存在することをお勧めします。
- If the <scope> part is missing, the scope of the original Search is used by the client to progress the operation.
- <スコープ>の部分が欠落している場合は、元の検索の範囲は、操作を進めるために、クライアントによって使用されます。
- Other aspects of the new request may be the same as or different from the request that generated the referral.
- 新しいリクエストの他の態様は、照会を生成した要求と同じでも異なっていてもよいです。
Other kinds of URIs may be returned. The syntax and semantics of such URIs is left to future specifications. Clients may ignore URIs that they do not support.
URIの他の種類が返されることがあります。そのようなURIの構文とセマンティクスは将来の仕様に任されています。クライアントは、彼らがサポートしていないURIを無視してもよいです。
UTF-8 encoded characters appearing in the string representation of a DN, search filter, or other fields of the referral value may not be legal for URIs (e.g., spaces) and MUST be escaped using the % method in [RFC3986].
DN、検索フィルタ、または照会の値の他のフィールドの文字列表現に現れるUTF-8でエンコードされた文字は、URIを（例えば、スペース）の法的ではないかもしれないと[RFC3986]で％メソッドを使用してエスケープする必要があります。
Controls provide a mechanism whereby the semantics and arguments of existing LDAP operations may be extended. One or more controls may be attached to a single LDAP message. A control only affects the semantics of the message it is attached to.
コントロールは、既存のLDAP操作の意味や引数を拡張することができる機構を提供します。一つ以上のコントロールが単一のLDAPメッセージに添付されてもよいです。コントロールは、それが接続されているメッセージの意味論に影響を与えます。
Controls sent by clients are termed 'request controls', and those sent by servers are termed 'response controls'.
クライアントによって送信されたコントロールは、「要求コントロール」と呼ばれており、サーバによって送信されたものを「応答コントロール」と呼ばれています。
Controls ::= SEQUENCE OF control Control
Control ::= SEQUENCE {
controlType LDAPOID,
criticality BOOLEAN DEFAULT FALSE,
controlValue OCTET STRING OPTIONAL }
The controlType field is the dotted-decimal representation of an OBJECT IDENTIFIER that uniquely identifies the control. This provides unambiguous naming of controls. Often, response control(s) solicited by a request control share controlType values with the request control.
controlTypeフィールドは、一意にコントロールを識別するオブジェクト識別子のドット付き10進表現です。これは、コントロールの明確なネーミングを提供します。多くの場合、応答制御（単数または複数）は、リクエスト制御と要求制御シェアcontrolType値によって要請します。
The criticality field only has meaning in controls attached to request messages (except UnbindRequest). For controls attached to response messages and the UnbindRequest, the criticality field SHOULD be FALSE, and MUST be ignored by the receiving protocol peer. A value of TRUE indicates that it is unacceptable to perform the operation without applying the semantics of the control. Specifically, the criticality field is applied as follows:
臨界フィールドは（UnbindRequestを除く）のメッセージを要求するために添付のコントロールに意味を持ちます。応答メッセージとUnbindRequestをに取り付けられた制御のために、臨界フィールドがFALSEであるべきであり、受信プロトコルピアによって無視されなければなりません。 TRUEの値は、コントロールの意味論を適用せずに操作を実行するために受け入れられないことを示しています。次のように具体的には、臨界電界が印加されます。
- If the server does not recognize the control type, determines that it is not appropriate for the operation, or is otherwise unwilling to perform the operation with the control, and if the criticality field is TRUE, the server MUST NOT perform the operation, and for operations that have a response message, it MUST return with the resultCode set to unavailableCriticalExtension.
- サーバがコントロールタイプを認識しない場合、それは操作のために適切でないと判断し、またはコントロールを使用して操作を実行するためにそれ以外の場合は不本意であり、臨界分野がTRUEの場合、サーバーは、操作を実行する、とはならない（MUST NOT）応答メッセージを持っている操作のために、それはunavailableCriticalExtensionに設定のresultCodeを返さなければなりません。
- If the server does not recognize the control type, determines that it is not appropriate for the operation, or is otherwise unwilling to perform the operation with the control, and if the criticality field is FALSE, the server MUST ignore the control.
- サーバは、制御タイプを認識しない場合、それは動作のために適切ではないと判断し、または制御して操作を実行するためにそうでなければ不本意であり、臨界フィールドがFALSEである場合、サーバはコントロールを無視しなければなりません。
- Regardless of criticality, if a control is applied to an operation, it is applied consistently and impartially to the entire operation.
- 制御動作に適用された場合にかかわらず、臨界の、それが全体の動作に一貫して公平に適用されます。
The controlValue may contain information associated with the controlType. Its format is defined by the specification of the control. Implementations MUST be prepared to handle arbitrary contents of the controlValue octet string, including zero bytes. It is absent only if there is no value information that is associated with a control of its type. When a controlValue is defined in terms of ASN.1, and BER-encoded according to Section 5.1, it also follows the extensibility rules in Section 4.
controlValueはcontrolTypeに関連する情報を含むことができます。そのフォーマットは、制御の仕様によって定義されます。実装は、ゼロバイトを含むcontrolValueオクテットストリングの任意のコンテンツを処理するために準備しなければなりません。そのタイプのコントロールに関連付けられているいかなる値情報が存在しない場合にのみ、それは存在しません。 controlValueはASN.1の用語で定義され、セクション5.1に従ってBERエンコードされている場合、それはまた、セクション4で拡張ルールに従います。
Servers list the controlType of request controls they recognize in the 'supportedControl' attribute in the root DSE (Section 5.1 of [RFC4512]).
サーバーは、ルートDSE（[RFC4512]の5.1節）の「のsupportedControl」属性で認識要求コントロールのcontrolTypeをリストアップ。
Controls SHOULD NOT be combined unless the semantics of the combination has been specified. The semantics of control combinations, if specified, are generally found in the control specification most recently published. When a combination of controls is encountered whose semantics are invalid, not specified (or not known), the message is considered not well-formed; thus, the operation fails with protocolError. Controls with a criticality of FALSE may be ignored in order to arrive at a valid combination. Additionally, unless order-dependent semantics are given in a specification, the order of a combination of controls in the SEQUENCE is ignored. Where the order is to be ignored but cannot be ignored by the server, the message is considered not well-formed, and the operation fails with protocolError. Again, controls with a criticality of FALSE may be ignored in order to arrive at a valid combination.
組み合わせのセマンティクスが指定されていない限り、コントロールを組み合わせることではない（SHOULD NOT）。制御の組み合わせの意味は、指定された場合、一般的に最も最近発表された制御仕様に記載されています。コントロールの組み合わせは、そのセマンティクス（既知かどうか）を指定しない、無効で遭遇したときに、メッセージが十分に形成されていないと考えられます。このように、操作ははProtocolErrorで失敗します。 FALSEの重要性とコントロールが有効な組み合わせに到達するために無視することができます。順序依存性セマンティクスが明細書に与えられていない限り、さらに、配列内のコントロールの組み合わせの順序は無視されます。順序を無視するが、サーバによって無視することができない場合は、メッセージが整形式ではないと考えられ、そして操作がProtocolErrorのに失敗しています。再び、FALSEの臨界とコントロールが有効な組み合わせに到達するために無視することができます。
This document does not specify any controls. Controls may be specified in other documents. Documents detailing control extensions are to provide for each control:
このドキュメントは、任意のコントロールを指定していません。コントロールは、他の文書で指定することができます。コントロールの拡張を詳述したドキュメントは、各コントロールを提供するために、次のとおりです。
- the OBJECT IDENTIFIER assigned to the control,
- コントロールに割り当てられたオブジェクト識別子、
- direction as to what value the sender should provide for the criticality field (note: the semantics of the criticality field are defined above should not be altered by the control's specification),
- 送信者が臨界場を提供するべき値として方向（注：上記で定義されている臨界フィールドのセマンティクスは、コントロールの仕様によって変更されるべきではありません）、
- whether the controlValue field is present, and if so, the format of its contents,
- controlValueフィールドが存在するかどうか、そしてもしそうであれば、その内容のフォーマット、
- the semantics of the control, and
- コントロールの意味論、および
- optionally, semantics regarding the combination of the control with other controls.
- 必要に応じて、他のコントロールとコントロールの組み合わせに関する意味論。
The function of the Bind operation is to allow authentication information to be exchanged between the client and server. The Bind operation should be thought of as the "authenticate" operation. Operational, authentication, and security-related semantics of this operation are given in [RFC4513].
バインド操作の機能は、認証情報がクライアントとサーバ間で交換できるようにすることです。バインド操作は、「認証」の操作と考えるべきです。運用、認証、及びこの操作のセキュリティ関連の意味は[RFC4513]に記載されています。
The Bind request is defined as follows:
次のようにバインド要求が定義されています。
BindRequest ::= [APPLICATION 0] SEQUENCE {
version INTEGER (1 .. 127),
name LDAPDN,
authentication AuthenticationChoice }
AuthenticationChoice ::= CHOICE {
simple [0] OCTET STRING,
-- 1 and 2 reserved
sasl [3] SaslCredentials,
... }
SaslCredentials ::= SEQUENCE {
mechanism LDAPString,
credentials OCTET STRING OPTIONAL }
Fields of the BindRequest are:
BindRequestのフィールドは、次のとおりです。
- version: A version number indicating the version of the protocol to be used at the LDAP message layer. This document describes version 3 of the protocol. There is no version negotiation. The client sets this field to the version it desires. If the server does not support the specified version, it MUST respond with a BindResponse where the resultCode is set to protocolError.
- バージョン：LDAPメッセージ層で使用されるプロトコルのバージョンを示すバージョン番号。このドキュメントでは、プロトコルのバージョン3を説明します。何のバージョン交渉はありません。クライアントは、それが希望するバージョンにこのフィールドを設定します。サーバは指定されたバージョンをサポートしていない場合、それはresultCodeががはProtocolErrorに設定されているBindResponseで応じなければなりません。
- name: If not empty, the name of the Directory object that the client wishes to bind as. This field may take on a null value (a zero-length string) for the purposes of anonymous binds ([RFC4513], Section 5.1) or when using SASL [RFC4422] authentication ([RFC4513], Section 5.2). Where the server attempts to locate the named object, it SHALL NOT perform alias dereferencing.
- 名前：空でない場合は、クライアントが希望するディレクトリオブジェクトの名前としてバインドします。このフィールドはSASL [RFC4422]認証（[RFC4513]、セクション5.2）を使用して匿名バインド（[RFC4513]、セクション5.1）、または場合の目的のためにヌル値（長さゼロの文字列）をとることができます。サーバは指定されたオブジェクトの位置を特定しようとする場合、これは別名間接参照を実行しないものとします。
- authentication: Information used in authentication. This type is extensible as defined in Section 3.7 of [RFC4520]. Servers that do not support a choice supplied by a client return a BindResponse with the resultCode set to authMethodNotSupported.
- 認証：認証に使用される情報。 [RFC4520]のセクション3.7で定義されるように、このタイプは拡張可能です。クライアントによって提供される選択をサポートしていないサーバーはauthMethodNotSupportedに設定にresultCodeとBindResponseを返します。
Textual passwords (consisting of a character sequence with a known character set and encoding) transferred to the server using the simple AuthenticationChoice SHALL be transferred as UTF-8 [RFC3629] encoded [Unicode]. Prior to transfer, clients SHOULD prepare text passwords as "query" strings by applying the SASLprep [RFC4013] profile of the stringprep [RFC3454] algorithm. Passwords consisting of other data (such as random octets) MUST NOT be altered. The determination of whether a password is textual is a local client matter.
簡単AuthenticationChoiceを使用してサーバーに転送し（既知の文字セットとエンコーディングの文字列からなる）テキスト形式のパスワードは[UNICODE]はUTF-8 [RFC3629]としてエンコード移転します。転送する前に、クライアントは、文字列前のSASLprep [RFC4013]プロフィール[RFC3454]アルゴリズムを適用することにより、「クエリ」の文字列などのテキストのパスワードを準備する必要があります。 （例えばランダムオクテットのような）他のデータからなるパスワードが変更されてはいけません。パスワードがテキストであるかどうかの決意は、ローカルクライアントの問題です。
Before processing a BindRequest, all uncompleted operations MUST either complete or be abandoned. The server may either wait for the uncompleted operations to complete, or abandon them. The server then proceeds to authenticate the client in either a single-step or multi-step Bind process. Each step requires the server to return a BindResponse to indicate the status of authentication.
BindRequestを処理する前に、すべての未完了の操作が完了するかのいずれかを放棄しなければなりません。サーバーは、いずれかの完了するために、未完了の操作を待つ、またはそれらを放棄することができます。その後、サーバは、シングルステップまたは多段階のバインドプロセスのいずれかでクライアントを認証するように進みます。各ステップは、認証のステータスを示すBindResponseを返すようにサーバが必要です。
After sending a BindRequest, clients MUST NOT send further LDAP PDUs until receiving the BindResponse. Similarly, servers SHOULD NOT process or respond to requests received while processing a BindRequest.
BindRequestを送信した後、クライアントはBindResponseを受信するまで、さらにLDAP PDUを送ってはいけません。同様に、サーバが処理したりBindRequestを処理中に受信した要求に応答すべきでありません。
If the client did not bind before sending a request and receives an operationsError to that request, it may then send a BindRequest. If this also fails or the client chooses not to bind on the existing LDAP session, it may terminate the LDAP session, re-establish it, and begin again by first sending a BindRequest. This will aid in interoperating with servers implementing other versions of LDAP.
クライアントが要求を送信する前に結合して、その要求にoperationsErrorを受信しなかった場合、それは、BindRequestを送ることができます。これも失敗した場合や、クライアントが既存のLDAPセッションにバインドしないことを選択した場合、それを再確立し、LDAPセッションを終了し、第1 BindRequestを送ることによって再び始めることができます。これは、LDAPの他のバージョンを実装したサーバとの相互運用を支援します。
Clients may send multiple Bind requests to change the authentication and/or security associations or to complete a multi-stage Bind process. Authentication from earlier binds is subsequently ignored.
クライアントは、認証および/またはセキュリティ関連付けを変更したり、マルチステージバインド処理を完了するために、複数のバインド要求を送信することができます。以前のバインドからの認証は、その後無視されます。
For some SASL authentication mechanisms, it may be necessary for the client to invoke the BindRequest multiple times ([RFC4513], Section 5.2). Clients MUST NOT invoke operations between two Bind requests made as part of a multi-stage Bind.
クライアントはBindRequest複数回（[RFC4513]、セクション5.2）を起動するいくつかのSASL認証メカニズムのために、それが必要であってもよいです。クライアントは、多段バインドの一部として作られた2つのバインド要求との間の操作を呼び出してはいけません。
A client may abort a SASL bind negotiation by sending a BindRequest with a different value in the mechanism field of SaslCredentials, or an AuthenticationChoice other than sasl.
クライアントはSaslCredentialsのメカニズムのフィールドに別の値、またはSASL以外のAuthenticationChoiceでBindRequestを送ることによって、SASLバインドネゴシエーションを中止することがあります。
If the client sends a BindRequest with the sasl mechanism field as an empty string, the server MUST return a BindResponse with the resultCode set to authMethodNotSupported. This will allow the client to abort a negotiation if it wishes to try again with the same SASL mechanism.
クライアントは空の文字列としてSASL機構フィールドでBindRequestを送信すると、サーバーはauthMethodNotSupportedに設定にresultCodeとBindResponseを返さなければなりません。これは、同じSASL機構に再度お試ししたい場合、クライアントは交渉を中止することができます。
The Bind response is defined as follows.
次のようにバインド応答が定義されています。
BindResponse ::= [APPLICATION 1] SEQUENCE {
COMPONENTS OF LDAPResult,
serverSaslCreds [7] OCTET STRING OPTIONAL }
BindResponse consists simply of an indication from the server of the status of the client's request for authentication.
BindResponseは、単に認証のためのクライアントの要求の状況のサーバーからの指示で構成されています。
A successful Bind operation is indicated by a BindResponse with a resultCode set to success. Otherwise, an appropriate result code is set in the BindResponse. For BindResponse, the protocolError result code may be used to indicate that the version number supplied by the client is unsupported.
成功したバインド操作は成功に設定のresultCodeとBindResponseで示されています。そうでない場合、適切な結果コードがBindResponseに設定されています。 BindResponseため、はProtocolError結果コードは、クライアントによって供給されたバージョン番号がサポートされていないことを示すために使用されてもよいです。
If the client receives a BindResponse where the resultCode is set to protocolError, it is to assume that the server does not support this version of LDAP. While the client may be able proceed with another version of this protocol (which may or may not require closing and re-establishing the transport connection), how to proceed with another version of this protocol is beyond the scope of this document. Clients that are unable or unwilling to proceed SHOULD terminate the LDAP session.
クライアントがresultCodeががはProtocolErrorに設定されているBindResponseを受信した場合には、サーバはLDAPのこのバージョンをサポートしていないと仮定することです。クライアント（または閉鎖を必要と再確立輸送接続をしてもしなくてもよい）このプロトコルの他のバージョンを進めることができるかもしれないが、このプロトコルの他のバージョンを続行する方法を、この文書の範囲外です。続行たがっていないクライアントは、LDAPセッションを終了する必要があります。
The serverSaslCreds field is used as part of a SASL-defined bind mechanism to allow the client to authenticate the server to which it is communicating, or to perform "challenge-response" authentication. If the client bound with the simple choice, or the SASL mechanism does not require the server to return information to the client, then this field SHALL NOT be included in the BindResponse.
serverSaslCredsフィールドは、クライアントが通信しているサーバを認証するために、または「チャレンジレスポンス」認証を実行できるようにするSASL定義バインド機構の一部として使用されています。簡単な選択、またはSASLメカニズムでバインドされたクライアントがクライアントに情報を返すためにサーバーを必要としない場合、このフィールドはBindResponseに含まれないものとします。
The function of the Unbind operation is to terminate an LDAP session. The Unbind operation is not the antithesis of the Bind operation as the name implies. The naming of these operations are historical. The Unbind operation should be thought of as the "quit" operation.
バインド解除操作の機能は、LDAPセッションを終了することです。名前が示すようにunbindは、バインド操作のアンチテーゼではありません。これらの操作の命名は歴史があります。 unbindは、「終了」操作と考えるべきです。
The Unbind operation is defined as follows:
次のようにバインド解除操作が定義されています。
UnbindRequest ::= [APPLICATION 2] NULL
The client, upon transmission of the UnbindRequest, and the server, upon receipt of the UnbindRequest, are to gracefully terminate the LDAP session as described in Section 5.3. Uncompleted operations are handled as specified in Section 3.1.
クライアントは、UnbindRequestを、サーバの送信時に、UnbindRequestをを受け取ると、5.3節で説明したように優雅にLDAPセッションを終了することがあります。 3.1節で指定された未完了の操作が処理されます。
An unsolicited notification is an LDAPMessage sent from the server to the client that is not in response to any LDAPMessage received by the server. It is used to signal an extraordinary condition in the server or in the LDAP session between the client and the server. The notification is of an advisory nature, and the server will not expect any response to be returned from the client.
未承諾の通知は、サーバーが受信したすべてのたLDAPMessageに対応していないサーバからクライアントに送られたLDAPMessageです。サーバやクライアントとサーバーの間のLDAPセッションにおける異常な状態を知らせるために使用されています。通知は顧問性質のものであり、サーバは、応答がクライアントから返されることを期待しないであろう。
The unsolicited notification is structured as an LDAPMessage in which the messageID is zero and protocolOp is set to the extendedResp choice using the ExtendedResponse type (See Section 4.12). The responseName field of the ExtendedResponse always contains an LDAPOID that is unique for this notification.
未承諾の通知はメッセージIDがゼロでprotocolOpがExtendedResponseタイプ（セクション4.12を参照）を使用してextendedResp選択に設定されたたLDAPMessageとして構成されています。 ExtendedResponseのresponseNameフィールドは、常にこの通知のためのユニークなLDAPOIDが含まれています。
One unsolicited notification (Notice of Disconnection) is defined in this document. The specification of an unsolicited notification consists of:
ワン迷惑通知（切断のお知らせ）は、この文書で定義されています。迷惑通知の指定はで構成されています。
- the OBJECT IDENTIFIER assigned to the notification (to be specified in the responseName,
- responseNameで指定する通知に割り当てられたオブジェクト識別子（、
- the format of the contents of the responseValue (if any),
- responseValueのコンテンツのフォーマット（もしあれば）、
- the circumstances which will cause the notification to be sent, and
- 通知が送信されます状況、および
- the semantics of the message.
- メッセージの意味論。
This notification may be used by the server to advise the client that the server is about to terminate the LDAP session on its own initiative. This notification is intended to assist clients in distinguishing between an exceptional server condition and a transient network failure. Note that this notification is not a response to an Unbind requested by the client. Uncompleted operations are handled as specified in Section 3.1.
この通知は、サーバーは、自身の主導でLDAPセッションを終了しようとしているクライアントに助言するためにサーバーが使用することができます。この通知は、例外のサーバ条件と一時的なネットワーク障害を区別してクライアントを支援することを意図しています。この通知は、クライアントから要求されたバインド解除に応じないことに注意してください。 3.1節で指定された未完了の操作が処理されます。
The responseName is 1.3.6.1.4.1.1466.20036, the responseValue field is absent, and the resultCode is used to indicate the reason for the disconnection. When the strongerAuthRequired resultCode is returned with this message, it indicates that the server has detected that an established security association between the client and server has unexpectedly failed or been compromised.
responseNameはresponseValueフィールドが存在しない、1.3.6.1.4.1.1466.20036であり、そしてresultCodeが断線した理由を示すために使用されます。 strongerAuthRequiredのresultCodeは、このメッセージに返された場合は、サーバーがクライアントとサーバの間で確立されたセキュリティアソシエーションが予期せずに失敗したか、危険にさらされていることを検出したことを示します。
Upon transmission of the Notice of Disconnection, the server gracefully terminates the LDAP session as described in Section 5.3.
5.3節で説明したように切断の通知を送信すると、サーバーは、優雅にLDAPセッションを終了します。
The Search operation is used to request a server to return, subject to access controls and other restrictions, a set of entries matching a complex search criterion. This can be used to read attributes from a single entry, from entries immediately subordinate to a particular entry, or from a whole subtree of entries.
検索操作は、アクセス制御やその他の制限の対象と返すようにサーバー、複雑な検索条件に一致するエントリのセットを要求するために使用されます。これは、特定のエントリに、またはエントリのサブツリー全体からすぐ下位のエントリーから、単一のエントリから属性を読み取るために使用することができます。
The Search request is defined as follows:
次のように検索要求が定義されています。
SearchRequest ::= [APPLICATION 3] SEQUENCE {
baseObject LDAPDN,
scope ENUMERATED {
baseObject (0),
singleLevel (1),
wholeSubtree (2),
... },
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3) },
sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt),
typesOnly BOOLEAN,
filter Filter,
attributes AttributeSelection }
AttributeSelection ::= SEQUENCE OF selector LDAPString
-- The LDAPString is constrained to
-- <attributeSelector> in Section 4.5.1.8
Filter ::= CHOICE {
and [0] SET SIZE (1..MAX) OF filter Filter,
or [1] SET SIZE (1..MAX) OF filter Filter,
not [2] Filter, equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion,
present [7] AttributeDescription,
approxMatch [8] AttributeValueAssertion,
extensibleMatch [9] MatchingRuleAssertion,
... }
SubstringFilter ::= SEQUENCE {
type AttributeDescription,
substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
initial [0] AssertionValue, -- can occur at most once
any [1] AssertionValue,
final [2] AssertionValue } -- can occur at most once
}
MatchingRuleAssertion ::= SEQUENCE {
matchingRule [1] MatchingRuleId OPTIONAL,
type [2] AttributeDescription OPTIONAL,
matchValue [3] AssertionValue,
dnAttributes [4] BOOLEAN DEFAULT FALSE }
Note that an X.500 "list"-like operation can be emulated by the client requesting a singleLevel Search operation with a filter checking for the presence of the 'objectClass' attribute, and that an X.500 "read"-like operation can be emulated by a baseObject Search operation with the same filter. A server that provides a gateway to X.500 is not required to use the Read or List operations, although it may choose to do so, and if it does, it must provide the same semantics as the X.500 Search operation.
様の操作が「オブジェクトクラス」属性の存在をチェックするフィルター付きsingleLevel検索操作を要求しているクライアントによってエミュレート、およびX.500の様操作を「読み」ができることをすることができますX.500「リスト」ことに注意してください同じフィルタでbaseObject検索操作によってエミュレートします。 X.500へのゲートウェイを提供するサーバは、それがそうすることを選択するかもしれないが、読むか、リスト操作を使用する必要はありません、それがない場合は、X.500検索の動作と同じセマンティクスを提供しなければなりません。
The name of the base object entry (or possibly the root) relative to which the Search is to be performed.
ベースオブジェクトのエントリ（又はおそらくルート）、検索が実行されるべき相対の名前。
Specifies the scope of the Search to be performed. The semantics (as described in [X.511]) of the defined values of this field are:
実行される検索の範囲を指定します。このフィールドの定義された値の意味は（[X.511]に記載されている）です。
baseObject: The scope is constrained to the entry named by baseObject.
baseObject：範囲はbaseObjectによって指定されたエントリに制限されます。
singleLevel: The scope is constrained to the immediate subordinates of the entry named by baseObject.
singleLevel：範囲はbaseObjectによって指定されたエントリーの直接の部下に拘束されています。
wholeSubtree: The scope is constrained to the entry named by baseObject and to all its subordinates.
wholeSubtree：範囲はbaseObjectによって指定されたエントリに、そのすべての部下に拘束されています。
An indicator as to whether or not alias entries (as defined in [RFC4512]) are to be dereferenced during stages of the Search operation.
（[RFC4512]で定義されている）か否か別名エントリについてのインジケータは、検索操作の段階で逆参照されるべきです。
The act of dereferencing an alias includes recursively dereferencing aliases that refer to aliases.
別名を参照解除の行為は、再帰的にエイリアスを参照する別名を間接参照しています。
Servers MUST detect looping while dereferencing aliases in order to prevent denial-of-service attacks of this nature.
サーバーは、この種のサービス拒否攻撃を防ぐために別名を逆参照しながら、ループを検出する必要があります。
The semantics of the defined values of this field are:
このフィールドの定義された値の意味は以下のとおりです。
neverDerefAliases: Do not dereference aliases in searching or in locating the base object of the Search.
neverDerefAliases：検索または検索のベースオブジェクトを見つけるにはない別名を間接参照しています。
derefInSearching: While searching subordinates of the base object, dereference any alias within the search scope. Dereferenced objects become the vertices of further search scopes where the Search operation is also applied. If the search scope is wholeSubtree, the Search continues in the subtree(s) of any dereferenced object. If the search scope is singleLevel, the search is applied to any dereferenced objects and is not applied to their subordinates. Servers SHOULD eliminate duplicate entries that arise due to alias dereferencing while searching.
derefInSearching：検索範囲内の任意の別名間接参照、ベースオブジェクトの部下を探索しながら。間接参照オブジェクトは、検索操作にも適用され、さらに検索範囲の頂点になります。検索範囲がwholeSubtreeである場合、検索は、任意の参照解除オブジェクトのサブツリー（S）で継続します。検索範囲がsingleLevelある場合、検索は任意の間接参照オブジェクトに適用され、部下には適用されません。サーバーは、検索中に別名参照解除のために発生する重複したエントリを排除する必要があります。
derefFindingBaseObj: Dereference aliases in locating the base object of the Search, but not when searching subordinates of the base object.
derefFindingBaseObj：検索のベースオブジェクトを配置するが、ベースオブジェクトの部下を検索しない場合に別名逆参照。
derefAlways: Dereference aliases both in searching and in locating the base object of the Search.
derefAlways：検索および検索のベースオブジェクトを配置で両方の間接参照エイリアス。
A size limit that restricts the maximum number of entries to be returned as a result of the Search. A value of zero in this field indicates that no client-requested size limit restrictions are in effect for the Search. Servers may also enforce a maximum number of entries to return.
検索の結果として返されるエントリの最大数を制限するサイズの制限。この分野のゼロの値は、クライアントが要求したサイズの上限制限が検索のために有効にされていないことを示しています。サーバはまた、返されるエントリの最大数を強制することがあります。
A time limit that restricts the maximum time (in seconds) allowed for a Search. A value of zero in this field indicates that no client-requested time limit restrictions are in effect for the Search. Servers may also enforce a maximum time limit for the Search.
最大時間（秒単位）を制限時間制限は、検索を可能にしました。この分野のゼロの値は、クライアントが要求した時間制限の制限が検索のために有効にされていないことを示しています。サーバはまた、検索の最大時間制限を強制することがあります。
An indicator as to whether Search results are to contain both attribute descriptions and values, or just attribute descriptions. Setting this field to TRUE causes only attribute descriptions (and not values) to be returned. Setting this field to FALSE causes both attribute descriptions and values to be returned.
検索結果は、属性の説明と値の両方を含むようにしている、または単に属性の説明かどうかの指標。 TRUEの原因にこのフィールドを設定するだけで返される記述（とない値）を属性。返されるFALSE原因属性の説明と値の両方にこのフィールドを設定します。
A filter that defines the conditions that must be fulfilled in order for the Search to match a given entry.
所与のエントリと一致する検索用のために満たされなければならない条件を定義するフィルタ。
The 'and', 'or', and 'not' choices can be used to form combinations of filters. At least one filter element MUST be present in an 'and' or 'or' choice. The others match against individual attribute values of entries in the scope of the Search. (Implementor's note: the 'not' filter is an example of a tagged choice in an implicitly-tagged module. In BER this is treated as if the tag were explicit.)
「と」、「または」、および選択は、フィルタの組み合わせを形成するために使用することができる「ではありません」。少なくとも1つのフィルタエレメントは、「と」または「または」選択中に存在しなければなりません。他の人が検索範囲内のエントリの個々の属性値に対して一致します。 （開発者のための注記：「しない」フィルタは、暗黙的にタグモジュールでタグ付けされた選択肢の例であるBERでタグが明示的であるかのように、これが扱われます。）。
A server MUST evaluate filters according to the three-valued logic of [X.511] (1993), Clause 7.8.1. In summary, a filter is evaluated to "TRUE", "FALSE", or "Undefined". If the filter evaluates to TRUE for a particular entry, then the attributes of that entry are returned as part of the Search result (subject to any applicable access control restrictions). If the filter evaluates to FALSE or Undefined, then the entry is ignored for the Search.
サーバは、[X.511]（1993）、節7.8.1の三値論理に応じてフィルタを評価しなければなりません。要約すると、フィルタは、「TRUE」「FALSE」、または「未定義」に評価されます。フィルタは、特定のエントリについてTRUEと評価された場合、そのエントリの属性は、検索結果（該当するアクセス制御制限を受ける）の一部として返されます。フィルタがFALSEまたは未定義と評価された場合、エントリは検索では無視されます。
A filter of the "and" choice is TRUE if all the filters in the SET OF evaluate to TRUE, FALSE if at least one filter is FALSE, and Undefined otherwise. A filter of the "or" choice is FALSE if all the filters in the SET OF evaluate to FALSE, TRUE if at least one filter is TRUE, and Undefined otherwise. A filter of the 'not' choice is TRUE if the filter being negated is FALSE, FALSE if it is TRUE, and Undefined if it is Undefined.
少なくとも1つのフィルタが、そうでなければFALSEと定義されていない場合のセット内のすべてのフィルタは、TRUE FALSEと評価された場合「と」選択のフィルタはTRUEです。少なくとも1つのフィルタが、そうでない場合はTRUE、と定義されていない場合のセット内のすべてのフィルタは、FALSEにTRUE評価された場合「または」選択のフィルタはFALSEです。否定されたフィルタは、それがTRUEの場合、FALSE FALSEであり、それが定義されていない場合は定義されていない場合「ではない」選択のフィルタはTRUEです。
A filter item evaluates to Undefined when the server would not be able to determine whether the assertion value matches an entry. Examples include:
サーバはアサーション値がエントリと一致するかどうかを決定することができない場合、フィルタ項目は、未定義と評価します。例としては、
- An attribute description in an equalityMatch, substrings, greaterOrEqual, lessOrEqual, approxMatch, or extensibleMatch filter is not recognized by the server.
- equalityMatch、ストリング、greaterOrEqual、lessOrEqual、approxMatch、またはextensibleMatchフィルターの属性記述は、サーバーによって認識されません。
- The attribute type does not define the appropriate matching rule.
- 属性タイプは、適切なマッチングルールを定義していません。
- A MatchingRuleId in the extensibleMatch is not recognized by the server or is not valid for the attribute type.
- extensibleMatchでMatchingRuleIdはサーバによって認識されないか、属性タイプに対して有効ではありません。
- The type of filtering requested is not implemented.
- 要求されたフィルタリングの種類が実装されていません。
- The assertion value is invalid.
- アサーションの値が無効です。
For example, if a server did not recognize the attribute type shoeSize, the filters (shoeSize=*), (shoeSize=12), (shoeSize>=12), and (shoeSize<=12) would each evaluate to Undefined.
例えば、サーバは、（SHOESIZE = *）、フィルターを属性タイプSHOESIZEを認識しなかった場合（SHOESIZE = 12）、（SHOESIZE> = 12）、及び（SHOESIZE <= 12）はそれぞれ、未定義と評価されてしまうからです。
Servers MUST NOT return errors if attribute descriptions or matching rule ids are not recognized, assertion values are invalid, or the assertion syntax is not supported. More details of filter processing are given in Clause 7.8 of [X.511].
属性の説明やマッチングルールIDが認識されない場合、サーバーがエラーを返してはならない、アサーションの値が無効である、またはアサーションの構文はサポートされていません。フィルタ処理の詳細は[X.511]の節7.8に記載されています。
The matching rule for an equalityMatch filter is defined by the EQUALITY matching rule for the attribute type or subtype. The filter is TRUE when the EQUALITY rule returns TRUE as applied to the attribute or subtype and the asserted value.
equalityMatchフィルタのマッチング規則は、属性タイプまたはサブタイプの等価マッチング規則によって定義されます。フィルタは、属性またはサブタイプとアサート値に適用される平等規則がTRUEを返す場合TRUEです。
There SHALL be at most one 'initial' and at most one 'final' in the 'substrings' of a SubstringFilter. If 'initial' is present, it SHALL be the first element of 'substrings'. If 'final' is present, it SHALL be the last element of 'substrings'.
高々1 SubstringFilterの「ストリング」の「初期」と最大1つの「最終」がなければなりません。 「初期」は存在している場合、それは「ストリング」の最初の要素でなければなら。 「最終的には」存在している場合、それは「ストリング」の最後の要素であるものとします。
The matching rule for an AssertionValue in a substrings filter item is defined by the SUBSTR matching rule for the attribute type or subtype. The filter is TRUE when the SUBSTR rule returns TRUE as applied to the attribute or subtype and the asserted value.
サブストリングフィルタ項目でAssertionValueのためのマッチング規則は、属性タイプまたはサブタイプのSUBSTRマッチング規則によって定義されます。属性またはサブタイプとアサート値に適用されるSUBSTR規則がTRUEを返すとき、フィルタはTRUEです。
Note that the AssertionValue in a substrings filter item conforms to the assertion syntax of the EQUALITY matching rule for the attribute type rather than to the assertion syntax of the SUBSTR matching rule for the attribute type. Conceptually, the entire SubstringFilter is converted into an assertion value of the substrings matching rule prior to applying the rule.
サブストリングフィルタ項目でAssertionValueの属性タイプの等価マッチング規則のアサーション構文にではなく、属性タイプのSUBSTRマッチング規則のアサーション構文に準拠していることに注意してください。概念的に、全体SubstringFilterルールを適用する前に、ストリングマッチング規則のアサーション値に変換されます。
The matching rule for a greaterOrEqual filter is defined by the ORDERING matching rule for the attribute type or subtype. The filter is TRUE when the ORDERING rule returns FALSE as applied to the attribute or subtype and the asserted value.
greaterOrEqualフィルタのマッチング規則は、属性タイプまたはサブタイプのオーダーマッチング規則によって定義されます。属性またはサブタイプとアサート値に適用されるORDERING規則がFALSEを返したときにフィルタがTRUEです。
The matching rules for a lessOrEqual filter are defined by the ORDERING and EQUALITY matching rules for the attribute type or subtype. The filter is TRUE when either the ORDERING or EQUALITY rule returns TRUE as applied to the attribute or subtype and the asserted value.
lessOrEqualフィルタのマッチング規則は、属性タイプまたはサブタイプの発注と平等マッチングルールによって定義されています。属性またはサブタイプとアサート値に適用されるORDERING又は平等のルールのいずれかがTRUEを返す場合、フィルタはTRUEです。
A present filter is TRUE when there is an attribute or subtype of the specified attribute description present in an entry, FALSE when no attribute or subtype of the specified attribute description is present in an entry, and Undefined otherwise.
エントリ中に存在する指定された属性記述の属性またはサブタイプがある場合、指定された属性記述のない属性またはサブタイプが他のエントリに存在する、および未定義ではない場合、本フィルタは、FALSE TRUEです。
An approxMatch filter is TRUE when there is a value of the attribute type or subtype for which some locally-defined approximate matching algorithm (e.g., spelling variations, phonetic match, etc.) returns TRUE. If a value matches for equality, it also satisfies an approximate match. If approximate matching is not supported for the attribute, this filter item should be treated as an equalityMatch.
以下のためのいくつかの局所的に定義された近似マッチングアルゴリズム（例えば、スペルのバリエーション、表音一致など）属性タイプまたはサブタイプの値があるときapproxMatchフィルタがTRUEであるTRUEを返します。値が平等のために一致した場合、それはまた、おおよその試合を満たしています。近似マッチング属性に対してサポートされていない場合、このフィルタ項目はequalityMatchとして扱われるべきです。
The fields of the extensibleMatch filter item are evaluated as follows:
次のようにextensibleMatchフィルタ項目のフィールドが評価されます。
- If the matchingRule field is absent, the type field MUST be present, and an equality match is performed for that type.
- matchingRuleフィールドが存在しない場合は、タイプ・フィールドが存在しなければならない、と等価の一致は、そのタイプに対して実行されます。
- If the type field is absent and the matchingRule is present, the matchValue is compared against all attributes in an entry that support that matchingRule.
- タイプフィールドが存在せず、matchingRuleが存在する場合、matchValueはmatchingRuleことをサポートするエントリ内のすべての属性と比較されます。
- If the type field is present and the matchingRule is present, the matchValue is compared against the specified attribute type and its subtypes.
- タイプフィールドが存在し、matchingRuleが存在する場合、matchValueは、指定された属性タイプとそのサブタイプと比較されます。
- If the dnAttributes field is set to TRUE, the match is additionally applied against all the AttributeValueAssertions in an entry's distinguished name, and it evaluates to TRUE if there is at least one attribute or subtype in the distinguished name for which the filter item evaluates to TRUE. The dnAttributes field is present to alleviate the need for multiple versions of generic matching rules (such as word matching), where one applies to entries and another applies to entries and DN attributes as well.
- dnAttributesフィールドがTRUEに設定されている場合、試合はさらに、エントリの識別名内のすべてのAttributeValueAssertionsに対して適用され、フィルタ項目は、と評価される識別名で少なくとも1つの属性またはサブタイプがある場合には、TRUEと評価しますTRUE。 dnAttributesフィールドは、1つのエントリに適用され、別のエントリに適用され、DNは、同様の属性（例えばワード・マッチングのような）一般的なマッチングルールの複数のバージョンの必要性を軽減するために存在しています。
The matchingRule used for evaluation determines the syntax for the assertion value. Once the matchingRule and attribute(s) have been determined, the filter item evaluates to TRUE if it matches at least one attribute type or subtype in the entry, FALSE if it does not match any attribute type or subtype in the entry, and Undefined if the matchingRule is not recognized, the matchingRule is unsuitable for use with the specified type, or the assertionValue is invalid.
評価に使用matchingRuleはアサーション値の構文を決定します。 matchingRuleと属性（複数可）が決定されたら、フィルタ項目は、エントリ内の任意の属性タイプまたはサブタイプと一致しない場合、それは、虚偽の内の少なくとも1つの属性タイプまたはサブタイプと一致する場合、TRUEと評価され、もし未定義matchingRuleが認識されない、matchingRuleは、指定されたタイプで使用するには不向きである、またはAssertionValueのは無効です。
A selection list of the attributes to be returned from each entry that matches the search filter. Attributes that are subtypes of listed attributes are implicitly included. LDAPString values of this field are constrained to the following Augmented Backus-Naur Form (ABNF) [RFC4234]:
検索フィルタに一致する各エントリから返される属性の選択リスト。リストされている属性のサブタイプです属性は暗黙のうちに含まれています。このフィールドのLDAPString値は、以下の増補バッカス - ナウアフォーム（ABNF）[RFC4234]に制限されます。
attributeSelector = attributedescription / selectorspecial
attributeSelector =のAttributeDescription / selectorspecial
selectorspecial = noattrs / alluserattrs
selectorspecial = noattrs / alluserattrs
noattrs = %x31.2E.31 ; "1.1"
noattrs =％x31.2E.31。 "1.1"
alluserattrs = %x2A ; asterisk ("*")
alluserattrs =％X2A。アスタリスク（ "*"）
The <attributedescription> production is defined in Section 2.5 of [RFC4512].
<のAttributeDescription>生産は[RFC4512]のセクション2.5で定義されています。
There are three special cases that may appear in the attributes selection list:
属性の選択リストに表示されることがあります3つの特別なケースがあります。
1. An empty list with no attributes requests the return of all user attributes.
1.属性を持たない空のリストには、すべてのユーザ属性の復帰を要求します。
2. A list containing "*" (with zero or more attribute descriptions) requests the return of all user attributes in addition to other listed (operational) attributes.
2.（ゼロ個以上の属性の説明で）「*」を含むリストは、すべてのユーザーのリターンが記載されている（運用）他の属性に加えて、属性を要求します。
3. A list containing only the OID "1.1" indicates that no attributes are to be returned. If "1.1" is provided with other attributeSelector values, the "1.1" attributeSelector is ignored. This OID was chosen because it does not (and can not) correspond to any attribute in use.
3.だけOID「1.1」を含むリストには属性が返されないことを示しています。 「1.1」は、他のattributeSelector値で提供されている場合は、「1.1」attributeSelectorは無視されます。このOIDはそうでないので、選ばれた（とすることはできません）使用中の任意の属性に対応しています。
Client implementors should note that even if all user attributes are requested, some attributes and/or attribute values of the entry may not be included in Search results due to access controls or other restrictions. Furthermore, servers will not return operational attributes, such as objectClasses or attributeTypes, unless they are listed by name. Operational attributes are described in [RFC4512].
クライアントの実装は、すべてのユーザ属性が要求されている場合でも、エントリのいくつかの属性および/または属性値は、アクセス制御やその他の制限のための検索結果に含まれていない可能性があることに注意すべきです。彼らは名前でリストされていない限り、サーバは、そのようなのobjectClassesやattributeTypes属性などの運用属性は、戻りません。オペレーショナル属性は、[RFC4512]に記載されています。
Attributes are returned at most once in an entry. If an attribute description is named more than once in the list, the subsequent names are ignored. If an attribute description in the list is not recognized, it is ignored by the server.
属性は、エントリで、最高1回返されます。属性の説明が一度リストよりも指定されている場合、それ以降の名前は無視されます。リスト内の属性の記述が認識されない場合、それはサーバによって無視されます。
The results of the Search operation are returned as zero or more SearchResultEntry and/or SearchResultReference messages, followed by a single SearchResultDone message.
検索操作の結果は、単一のSearchResultDoneメッセージに続くゼロ以上のSearchResultEntry及び/又はのSearchResultReferenceメッセージとして返されます。
SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
objectName LDAPDN,
attributes PartialAttributeList }
PartialAttributeList ::= SEQUENCE OF
partialAttribute PartialAttribute
SearchResultReference ::= [APPLICATION 19] SEQUENCE
SIZE (1..MAX) OF uri URI
SearchResultDone ::= [APPLICATION 5] LDAPResult
Each SearchResultEntry represents an entry found during the Search. Each SearchResultReference represents an area not yet explored during the Search. The SearchResultEntry and SearchResultReference messages may come in any order. Following all the SearchResultReference and SearchResultEntry responses, the server returns a SearchResultDone response, which contains an indication of success or details any errors that have occurred.
各のSearchResultEntryは、検索中に発見されたエントリを表します。各のSearchResultReferenceはまだ検索中に探求していない領域を表します。 SearchResultEntryとのSearchResultReferenceメッセージは、任意の順序で来るかもしれません。すべてのSearchResultReferenceとのSearchResultEntry応答の後、サーバーは、成功の表示を含むか、発生したエラーの詳細をSearchResultDoneレスポンスを返します。
Each entry returned in a SearchResultEntry will contain all appropriate attributes as specified in the attributes field of the Search Request, subject to access control and other administrative policy. Note that the PartialAttributeList may hold zero elements.
、検索要求の属性フィールドで指定されたコントロールやその他の管理ポリシーにアクセスする対象としてのSearchResultEntryで返される各エントリには、すべての適切な属性が含まれます。 PartialAttributeListはゼロ要素を保持することができることに留意されたいです。
This may happen when none of the attributes of an entry were requested or could be returned. Note also that the partialAttribute vals set may hold zero elements. This may happen when typesOnly is requested, access controls prevent the return of values, or other reasons.
エントリの属性のいずれも要求されなかったか、返却することができたときにこれが発生する可能性があります。 partialAttributeのヴァルスセットがゼロの要素を保持することができることにも留意されたいです。 typesOnlyが要求されたときにこれが発生する可能性があり、アクセス制御は、値、またはその他の理由のリターンを防ぎます。
Some attributes may be constructed by the server and appear in a SearchResultEntry attribute list, although they are not stored attributes of an entry. Clients SHOULD NOT assume that all attributes can be modified, even if this is permitted by access control.
彼らは、エントリの属性を格納していませんが、一部の属性は、サーバーによって構築とのSearchResultEntry属性リストに表示されていてもよいです。クライアントは、これは、アクセス制御によって許可されている場合でも、すべての属性を変更することができることを仮定するべきではありません。
If the server's schema defines short names [RFC4512] for an attribute type, then the server SHOULD use one of those names in attribute descriptions for that attribute type (in preference to using the <numericoid> [RFC4512] format of the attribute type's object identifier). The server SHOULD NOT use the short name if that name is known by the server to be ambiguous, or if it is otherwise likely to cause interoperability problems.
サーバーのスキーマは、属性タイプの短縮名[RFC4512]を定義している場合、サーバは、属性タイプのオブジェクト識別子の<numericoid> [RFC4512]形式を使用することに優先して（その属性タイプの属性の記述におけるこれらの名前のいずれかを使用すべきです）。その名前があいまいにするためにサーバによって知られている場合、または相互運用性の問題を引き起こしそうでない可能性がある場合、サーバーは、短い名前を使用しないでください。
If the server was able to locate the entry referred to by the baseObject but was unable or unwilling to search one or more non-local entries, the server may return one or more SearchResultReference messages, each containing a reference to another set of servers for continuing the operation. A server MUST NOT return any SearchResultReference messages if it has not located the baseObject and thus has not searched any entries. In this case, it would return a SearchResultDone containing either a referral or noSuchObject result code (depending on the server's knowledge of the entry named in the baseObject).
サーバがbaseObjectによって参照されるエントリを見つけることができましたが、1つまたは複数の非ローカルのエントリを検索することができませんでしまたは不本意だった場合、サーバは、それぞれが継続するためのサーバーの別のセットへの参照を含む、一の以上のSearchResultReferenceメッセージを返すことがあります。操作。それはbaseObjectの場所に位置していないので、すべてのエントリを検索していない場合、サーバーは任意ののSearchResultReferenceメッセージを返してはなりません。この場合、それは（baseObjectで指定されたエントリのサーバの知識に依存する）の紹介やnoSuchObject結果コードのいずれかを含むSearchResultDoneを返します。
If a server holds a copy or partial copy of the subordinate naming context (Section 5 of [RFC4512]), it may use the search filter to determine whether or not to return a SearchResultReference response. Otherwise, SearchResultReference responses are always returned when in scope.
サーバは従属名前付けコンテキスト（[RFC4512]のセクション5）のコピーまたは部分コピーを保持している場合、それはのSearchResultReference応答を返すするか否かを決定するために検索フィルタを使用することができます。それ以外の場合は、のSearchResultReference応答は常にスコープにしたときに返されています。
The SearchResultReference is of the same data type as the Referral.
SearchResultReferenceは紹介と同じデータ型です。
If the client wishes to progress the Search, it issues a new Search operation for each SearchResultReference that is returned. If multiple URIs are present, the client assumes that any supported URI may be used to progress the operation.
クライアントが検索を進行したい場合は、返される各のSearchResultReferenceのための新たな検索操作を発行します。複数のURIが存在する場合、クライアントはサポートされている任意のURIが操作を進行するために使用することができることを前提としています。
Clients that follow search continuation references MUST ensure that they do not loop between servers. They MUST NOT repeatedly contact the same server for the same request with the same parameters. Some clients use a counter that is incremented each time search result reference handling occurs for an operation, and these kinds of clients MUST be able to handle at least ten nested referrals while progressing the operation.
検索継続参照をたどるクライアントは、サーバー間でループしないことを保証しなければなりません。彼らは、繰り返し同じパラメータで同じ要求のために、同じサーバに問い合わせてはなりません。一部のクライアントは、検索結果の参照処理が動作のために発生するたびにインクリメントされるカウンタを使用し、クライアントのこれらの種類は、操作を進行しながら少なくとも10のネストされた照会を処理できなければなりません。
Note that the Abandon operation described in Section 4.11 applies only to a particular operation sent at the LDAP message layer between a client and server. The client must individually abandon subsequent Search operations it wishes to.
4.11項で説明放棄操作は、クライアントとサーバー間のLDAPメッセージ層で送信され、特定の操作にのみ適用されることに注意してください。クライアントは、個別にそれがしたい、後続の検索操作を放棄しなければなりません。
A URI for a server implementing LDAP and accessible via TCP/IP (v4 or v6) [RFC793][RFC791] is written as an LDAP URL according to [RFC4516].
サーバ実装LDAP用URIおよびTCP / IP（V4またはV6）[RFC793] [RFC791] [RFC4516]に従ってLDAP URLとして書かれているを介してアクセス可能。
SearchResultReference values that are LDAP URLs follow these rules:
LDAP URLがあるのSearchResultReference値は、これらの規則に従います。
- The <dn> part of the LDAP URL MUST be present, with the new target object name. The client uses this name when following the reference.
- LDAPのURLの<DN>の部分は、新しいターゲットオブジェクト名で、存在しなければなりません。参照を以下のときに、クライアントは、この名前を使用しています。
- Some servers (e.g., participating in distributed indexing) may provide a different filter in the LDAP URL.
- いくつかのサーバ（例えば、分散インデックスに参加して）LDAPのURLで異なるフィルタを提供することができます。
- If the <filter> part of the LDAP URL is present, the client uses this filter in its next request to progress this Search, and if it is not present the client uses the same filter as it used for that Search.
- LDAPのURLの<フィルタ>部分が存在する場合、クライアントは、この検索を進行するという次の要求で、このフィルタを使用し、それが存在しない場合、それはその検索に使用すると、クライアントは同じフィルタを使用しています。
- If the originating search scope was singleLevel, the <scope> part of the LDAP URL will be "base".
- 元の検索範囲がsingleLevel、<スコープ>だった場合はLDAPのURLの一部には、「ベース」になります。
- It is RECOMMENDED that the <scope> part be present to avoid ambiguity. In the absence of a <scope> part, the scope of the original Search request is assumed.
- <スコープ>の部分はあいまいさを避けるために存在することをお勧めします。 <スコープ>一部の非存在下で、元の検索要求の範囲が想定されます。
- Other aspects of the new Search request may be the same as or different from the Search request that generated the SearchResultReference.
- 新しい検索要求の他の態様は、のSearchResultReferenceを生成した検索要求と同じでも異なっていてもよいです。
- The name of an unexplored subtree in a SearchResultReference need not be subordinate to the base object.
- のSearchResultReferenceにおける未開拓サブツリーの名前は、ベースオブジェクトの下位である必要はありません。
Other kinds of URIs may be returned. The syntax and semantics of such URIs is left to future specifications. Clients may ignore URIs that they do not support.
URIの他の種類が返されることがあります。そのようなURIの構文とセマンティクスは将来の仕様に任されています。クライアントは、彼らがサポートしていないURIを無視してもよいです。
UTF-8-encoded characters appearing in the string representation of a DN, search filter, or other fields of the referral value may not be legal for URIs (e.g., spaces) and MUST be escaped using the % method in [RFC3986].
DN、検索フィルタ、または照会の値の他のフィールドの文字列表現に現れるUTF-8でエンコードされた文字は、URIを（例えば、スペース）の法的ではないかもしれないと[RFC3986]の％メソッドを使用してエスケープする必要があります。
For example, suppose the contacted server (hosta) holds the entry <DC=Example,DC=NET> and the entry <CN=Manager,DC=Example,DC=NET>. It knows that both LDAP servers (hostb) and (hostc) hold <OU=People,DC=Example,DC=NET> (one is the master and the other server a shadow), and that LDAP-capable server (hostd) holds the subtree <OU=Roles,DC=Example,DC=NET>. If a wholeSubtree Search of <DC=Example,DC=NET> is requested to the contacted server, it may return the following:
例えば、接触サーバ（ギボウシ）は、エントリ<DC =例、DC = NET>エントリ<CN =マネージャ、DC =例、DC = NET>を保持していると仮定する。これは、両方のLDAPサーバ（HOSTB）及び（HOSTC）は（1がマスターと他のサーバーのシャドウである）<OU =人、DC =例、DC = NET>を保持し、そのLDAP対応のサーバー（hostdの）が保持していることを知っていますサブツリー<OU =役割、DC =例、DC = NET>。連絡サーバーに要求されているのwholeSubtree検索した場合、<NET DC =例、DC =>が、それは次のように返すことがあります。
SearchResultEntry for DC=Example,DC=NET SearchResultEntry for CN=Manager,DC=Example,DC=NET SearchResultReference { ldap://hostb/OU=People,DC=Example,DC=NET??sub ldap://hostc/OU=People,DC=Example,DC=NET??sub } SearchResultReference { ldap://hostd/OU=Roles,DC=Example,DC=NET??sub } SearchResultDone (success)
DC =例、CN =マネージャのDC = NETのSearchResultEntry、DC =例、DC = NETのSearchResultReferenceためのSearchResultEntry {LDAP：// HOSTB / OU =人物、DC =例、DC = NET ??サブLDAP：// HOSTC / OU =人物、DC =例、DC = NET ??サブ}のSearchResultReference {LDAP：// hostdを/ OU =ロール、DC =例、DC = NET ??サブ} SearchResultDone（成功）
Client implementors should note that when following a SearchResultReference, additional SearchResultReference may be generated. Continuing the example, if the client contacted the server (hostb) and issued the Search request for the subtree <OU=People,DC=Example,DC=NET>, the server might respond as follows:
クライアントの実装はのSearchResultReferenceをたどるとき、追加のSearchResultReferenceが生成される可能性があることに注意すべきです。次のようにクライアントがサーバ（HOSTB）に接触し、サブツリーの検索要求発行した場合、例を続ける<OU =人、DCを=例、DC = NET>、サーバーが応答かもしれません：
SearchResultEntry for OU=People,DC=Example,DC=NET SearchResultReference { ldap://hoste/OU=Managers,OU=People,DC=Example,DC=NET??sub } SearchResultReference { ldap://hostf/OU=Consultants,OU=People,DC=Example,DC=NET??sub } SearchResultDone (success)
SearchResultReference {LDAP：// hostf / OU = OU =人物、DC =例、DC = NETのSearchResultReference {// hoste / OU =マネージャ、OU =人物、DC =例、DC = NET ??サブLDAP}ためのSearchResultEntryコンサルタント、OU =人物、DC =例、DC = NET ??サブ} SearchResultDone（成功）
Similarly, if a singleLevel Search of <DC=Example,DC=NET> is requested to the contacted server, it may return the following:
同様に、singleLevelの検索<DC =例、DC = NET>連絡サーバーに要求された場合、それは以下を返すことがあります。
SearchResultEntry for CN=Manager,DC=Example,DC=NET SearchResultReference { ldap://hostb/OU=People,DC=Example,DC=NET??base ldap://hostc/OU=People,DC=Example,DC=NET??base } SearchResultReference { ldap://hostd/OU=Roles,DC=Example,DC=NET??base } SearchResultDone (success)
// HOSTB / OU =人物、DC =例、DC = NET ??ベースLDAP：// HOSTC / OU =人物、DC =例、DC CN =マネージャ、DC =例、DC = NETのSearchResultReference {LDAP用のSearchResultEntry NET = ??基地}のSearchResultReference {LDAP：// hostdを/ OU =ロール、DC =例、DC = NET ??基地} SearchResultDone（成功）
If the contacted server does not hold the base object for the Search, but has knowledge of its possible location, then it may return a referral to the client. In this case, if the client requests a subtree Search of <DC=Example,DC=ORG> to hosta, the server returns a SearchResultDone containing a referral.
連絡サーバーは、検索のベースオブジェクトを保持しますが、その可能場所の知識を持っていない場合、それはクライアントへの紹介を返すことがあります。クライアントは、ギボウシに<DC =例、DC = ORG>のサブツリー検索を要求した場合この場合、サーバーは紹介を含むSearchResultDoneを返します。
SearchResultDone (referral) { ldap://hostg/DC=Example,DC=ORG??sub }
SearchResultDone（照会）{LDAP：// hostg / DC =例、DC = ORG ??副}
The Modify operation allows a client to request that a modification of an entry be performed on its behalf by a server. The Modify Request is defined as follows:
変更操作は、クライアントがエントリの修正がサーバーによって、その代わりに実行することを要求することができます。次のように修正要求が定義されています。
ModifyRequest ::= [APPLICATION 6] SEQUENCE {
object LDAPDN,
changes SEQUENCE OF change SEQUENCE {
operation ENUMERATED {
add (0),
delete (1),
replace (2),
... },
modification PartialAttribute } }
Fields of the Modify Request are:
変更要求のフィールドは、次のとおりです。
- object: The value of this field contains the name of the entry to be modified. The server SHALL NOT perform any alias dereferencing in determining the object to be modified.
- 対象：このフィールドの値を変更するエントリの名前が含まれています。サーバーは、変更するオブジェクトを決定する際にデリファレンス任意のエイリアスを実行しないものとします。
- changes: A list of modifications to be performed on the entry. The entire list of modifications MUST be performed in the order they are listed as a single atomic operation. While individual modifications may violate certain aspects of the directory schema (such as the object class definition and Directory Information Tree (DIT) content rule), the resulting entry after the entire list of modifications is performed MUST conform to the requirements of the directory model and controlling schema [RFC4512].
- 変更：エントリに対して実行される変更のリスト。変更のリスト全体は、それらが単一のアトミック動作として記載されている順序で実行されなければなりません。個々の修飾は（そのようなオブジェクトのクラス定義およびディレクトリ情報ツリー（DIT）コンテンツルールのような）ディレクトリスキーマの特定の局面に違反するかもしれないが、修正のリスト全体が実行された後、得られたエントリがディレクトリ・モデルの要件に適合しなければならないと制御スキーマ[RFC4512]。
- operation: Used to specify the type of modification being performed. Each operation type acts on the following modification. The values of this field have the following semantics, respectively:
- 操作：実行されている変更の種類を指定するために使用します。各操作の種類は次のように変更に作用します。このフィールドの値は、それぞれ、以下の意味を持っています：
add: add values listed to the modification attribute,
creating the attribute if necessary.
delete: delete values listed from the modification attribute. If no values are listed, or if all current values of the attribute are listed, the entire attribute is removed.
削除：変更属性から記載されている値を削除します。何の値がリストされていない場合、または属性のすべての現在の値がリストされている場合、全体の属性が削除されます。
replace: replace all existing values of the modification attribute with the new values listed, creating the attribute if it did not already exist. A replace with no value will delete the entire attribute if it exists, and it is ignored if the attribute does not exist.
置き換える：それはまだ存在していなかった場合、属性を作成し、リストされた新しい値で修正属性のすべての既存の値を置き換えます。 Aいいえ値と置き換えて、それが存在する場合、全体の属性を削除し、属性が存在しない場合、それは無視されます。
- modification: A PartialAttribute (which may have an empty SET of vals) used to hold the attribute type or attribute type and values being modified.
- 変形例：（ヴァルスの空のセットを有していてもよい）PartialAttributeは、属性タイプまたは属性タイプを保持するために使用され、値が変更されます。
Upon receipt of a Modify Request, the server attempts to perform the necessary modifications to the DIT and returns the result in a Modify Response, defined as follows:
変更要求を受信すると、サーバは、DITに必要な変更を実行しようと次のように定義され、変更応答に結果を返します。
ModifyResponse ::= [APPLICATION 7] LDAPResult
The server will return to the client a single Modify Response indicating either the successful completion of the DIT modification, or the reason that the modification failed. Due to the requirement for atomicity in applying the list of modifications in the Modify Request, the client may expect that no modifications of the DIT have been performed if the Modify Response received indicates any sort of error, and that all requested modifications have been performed if the Modify Response indicates successful completion of the Modify operation. Whether or not the modification was applied cannot be determined by the client if the Modify Response was not received (e.g., the LDAP session was terminated or the Modify operation was abandoned).
サーバーはDITの変更が正常に完了した、または変更が失敗した理由のいずれかを示すクライアントの単一の変更レスポンスに戻ります。変更要求における変更のリストを適用する際の最小単位の要件に、クライアントが変更レスポンスがエラーの任意の並べ替えを示しており、要求されたすべての変更があれば実行されたことを受けた場合にはDITのない変更が行われていないことを期待することがあり修正レスポンスは変更操作が正常に完了したことを示します。変更応答が受信されなかった場合は変更が適用されたかどうかは（例えば、LDAPセッションが終了したか、変更操作が放棄された）クライアントによって決定することができません。
Servers MUST ensure that entries conform to user and system schema rules or other data model constraints. The Modify operation cannot be used to remove from an entry any of its distinguished values, i.e., those values which form the entry's relative distinguished name. An attempt to do so will result in the server returning the notAllowedOnRDN result code. The Modify DN operation described in Section 4.9 is used to rename an entry.
サーバは、エントリは、ユーザとシステムスキーマルールやその他のデータモデルの制約に準拠していることを保証しなければなりません。変更操作は、エントリの相対識別名を形成する、すなわち、これらの値は、エントリからその識別値のいずれかを除去するために使用することができません。そうしようとする試みは、notAllowedOnRDN結果コードを返すサーバーになります。セクション4.9で説明したDNの変更操作は、エントリの名前を変更するために使用されます。
For attribute types that specify no equality matching, the rules in Section 2.5.1 of [RFC4512] are followed.
何の平等マッチングを指定していない属性タイプの場合は、[RFC4512]のセクション2.5.1の規則に従います。
Note that due to the simplifications made in LDAP, there is not a direct mapping of the changes in an LDAP ModifyRequest onto the changes of a DAP ModifyEntry operation, and different implementations of LDAP-DAP gateways may use different means of representing the change. If successful, the final effect of the operations on the entry MUST be identical.
LDAPで行われた単純化のために、変化を表す別の手段を使用することができるDAP ModifyEntry動作の変化、およびLDAP-DAPゲートウェイの異なる実装上LDAP ModifyRequestの変化の直接的なマッピングが存在しないためことに留意されたいです。成功した場合は、エントリに対する操作の最終的な効果は同じでなければなりません。
The Add operation allows a client to request the addition of an entry into the Directory. The Add Request is defined as follows:
Add操作は、クライアントがディレクトリへのエントリの追加を要求することができます。次のように追加要求が定義されています。
AddRequest ::= [APPLICATION 8] SEQUENCE {
entry LDAPDN,
attributes AttributeList }
AttributeList ::= SEQUENCE OF attribute Attribute
Fields of the Add Request are:
追加要求のフィールドは、次のとおりです。
- entry: the name of the entry to be added. The server SHALL NOT dereference any aliases in locating the entry to be added.
- エントリー：エントリーの名前が追加されます。サーバーは、追加する項目を見つけるのいずれかの別名間接参照してはなりません。
- attributes: the list of attributes that, along with those from the RDN, make up the content of the entry being added. Clients MAY or MAY NOT include the RDN attribute(s) in this list. Clients MUST NOT supply NO-USER-MODIFICATION attributes such as the createTimestamp or creatorsName attributes, since the server maintains these automatically.
- 属性：RDNからのものと一緒に、追加されたエントリの内容を構成して、属性のリストを。クライアントは、またはこのリスト内のRDN属性（複数可）を含んでも含まなくてもよいです。クライアントは、サーバが自動的にこれらを維持するのでcreateTimestampかcreatorsNameは、属性としてNO-USER-MODIFICATIONは、このような属性を供給してはなりません。
Servers MUST ensure that entries conform to user and system schema rules or other data model constraints. For attribute types that specify no equality matching, the rules in Section 2.5.1 of [RFC4512] are followed (this applies to the naming attribute in addition to any multi-valued attributes being added).
サーバは、エントリは、ユーザとシステムスキーマルールやその他のデータモデルの制約に準拠していることを保証しなければなりません。いかなる等価マッチングを指定しない属性タイプは、[RFC4512]のセクション2.5.1にルールが（これが追加される任意の多値属性に加えて、ネーミング属性に適用される）続きます。
The entry named in the entry field of the AddRequest MUST NOT exist for the AddRequest to succeed. The immediate superior (parent) of an object or alias entry to be added MUST exist. For example, if the client attempted to add <CN=JS,DC=Example,DC=NET>, the <DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did exist, then the server would return the noSuchObject result code with the matchedDN field containing <DC=NET>.
AddRequestが成功するためにAddRequestのエントリフィールドで指定されたエントリが存在してはいけません。追加するオブジェクトまたはエイリアスエントリの即時優れた（親）が存在しなければなりません。例えば、クライアントは、<CN = JS、DC =例、DC = NET>、<DC =例、DC = NET>エントリが存在し、かつなかった<DC = NET>エントリが存在しなかった追加しようとした場合サーバーは、<DC = NET>を含むmatchedDNフィールドとnoSuchObject結果コードを返します。
Upon receipt of an Add Request, a server will attempt to add the requested entry. The result of the Add attempt will be returned to the client in the Add Response, defined as follows:
追加要求を受信すると、サーバは要求されたエントリを追加しようとします。追加しようとした結果は以下のように定義され、追加のレスポンスでクライアントに返されます。
AddResponse ::= [APPLICATION 9] LDAPResult
A response of success indicates that the new entry has been added to the Directory.
成功の応答は、新しいエントリがディレクトリに追加されたことを示しています。
The Delete operation allows a client to request the removal of an entry from the Directory. The Delete Request is defined as follows:
削除操作は、クライアントがディレクトリからのエントリの削除を要求することができます。次のように削除要求が定義されています。
DelRequest ::= [APPLICATION 10] LDAPDN
The Delete Request consists of the name of the entry to be deleted. The server SHALL NOT dereference aliases while resolving the name of the target entry to be removed.
削除要求は、削除するエントリの名前で構成されています。サーバは、削除する対象のエントリの名前を解決しませ別名間接参照ものとしながら。
Only leaf entries (those with no subordinate entries) can be deleted with this operation.
唯一の葉のエントリ（無従属エントリを持つもの）は、この操作で削除することができます。
Upon receipt of a Delete Request, a server will attempt to perform the entry removal requested and return the result in the Delete Response defined as follows:
削除要求を受信すると、サーバは要求されたエントリの削除を行うと、以下のように定義された削除応答で結果を返そうとします：
DelResponse ::= [APPLICATION 11] LDAPResult
The Modify DN operation allows a client to change the Relative Distinguished Name (RDN) of an entry in the Directory and/or to move a subtree of entries to a new location in the Directory. The Modify DN Request is defined as follows:
DNの変更操作は、クライアントがディレクトリ内のエントリの相対識別名（RDN）を変更する及び/又はディレクトリ内の新しい場所にエントリのサブツリーを移動することを可能にします。次のようにDNの変更要求が定義されています。
ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
entry LDAPDN,
newrdn RelativeLDAPDN,
deleteoldrdn BOOLEAN,
newSuperior [0] LDAPDN OPTIONAL }
Fields of the Modify DN Request are:
DNの変更要求のフィールドは、次のとおりです。
- entry: the name of the entry to be changed. This entry may or may not have subordinate entries.
- エントリ：エントリの名前を変更します。このエントリは、または下位のエントリがあってもなくてもよいです。
- newrdn: the new RDN of the entry. The value of the old RDN is supplied when moving the entry to a new superior without changing its RDN. Attribute values of the new RDN not matching any attribute value of the entry are added to the entry, and an appropriate error is returned if this fails.
- newrdn：エントリの新しいRDN。そのRDNを変更することなく、新しい優れたにエントリを移動するときに、古いRDNの値が供給されています。新しいRDNは、エントリの任意の属性値と一致しないの属性値がエントリに追加され、これが失敗した場合に適切なエラーが返されます。
- deleteoldrdn: a boolean field that controls whether the old RDN attribute values are to be retained as attributes of the entry or deleted from the entry.
- のdeleteoldrdn：古いRDN属性値かどうかを制御するブール型フィールドは、エントリからのエントリまたは削除の属性として保持されることになります。
- newSuperior: if present, this is the name of an existing object entry that becomes the immediate superior (parent) of the existing entry.
- newSuperior：存在する場合、これは既存のエントリーの直接の優れた（親）になり、既存のオブジェクトエントリの名前です。
The server SHALL NOT dereference any aliases in locating the objects named in entry or newSuperior.
サーバは、エントリまたはnewSuperiorで指定されたオブジェクトを見つけるのいずれかの別名間接参照してはなりません。
Upon receipt of a ModifyDNRequest, a server will attempt to perform the name change and return the result in the Modify DN Response, defined as follows:
ModifyDNRequestを受信すると、サーバは次のように定義され、名前の変更を行い、変更DN応答で結果を返そうとします：
ModifyDNResponse ::= [APPLICATION 13] LDAPResult
For example, if the entry named in the entry field was <cn=John Smith,c=US>, the newrdn field was <cn=John Cougar Smith>, and the newSuperior field was absent, then this operation would attempt to rename the entry as <cn=John Cougar Smith,c=US>. If there was already an entry with that name, the operation would fail with the entryAlreadyExists result code.
例えば、入力フィールドで指定されたエントリが<CN =ジョン・スミス、C = US>だった場合、newrdnフィールドが<CN =ジョン・クーガー・スミス>だった、とnewSuperiorフィールドが存在しない場合、この操作は、名前を変更しようとしていました<CN =ジョン・クーガー・スミス、C = US>としてエントリー。その名前のエントリがすでにあった場合、操作はentryAlreadyExists結果コードで失敗します。
Servers MUST ensure that entries conform to user and system schema rules or other data model constraints. For attribute types that specify no equality matching, the rules in Section 2.5.1 of [RFC4512] are followed (this pertains to newrdn and deleteoldrdn).
サーバは、エントリは、ユーザとシステムスキーマルールやその他のデータモデルの制約に準拠していることを保証しなければなりません。いかなる等価マッチングを指定しない属性タイプは、[RFC4512]のセクション2.5.1にルールが（これはnewrdnとのdeleteoldrdnに関する）続いています。
The object named in newSuperior MUST exist. For example, if the client attempted to add <CN=JS,DC=Example,DC=NET>, the <DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did exist, then the server would return the noSuchObject result code with the matchedDN field containing <DC=NET>.
newSuperiorに指定されたオブジェクトが存在しなければなりません。例えば、クライアントは、<CN = JS、DC =例、DC = NET>、<DC =例、DC = NET>エントリが存在し、かつなかった<DC = NET>エントリが存在しなかった追加しようとした場合サーバーは、<DC = NET>を含むmatchedDNフィールドとnoSuchObject結果コードを返します。
If the deleteoldrdn field is TRUE, the attribute values forming the old RDN (but not the new RDN) are deleted from the entry. If the deleteoldrdn field is FALSE, the attribute values forming the old RDN will be retained as non-distinguished attribute values of the entry.
deleteoldrdn分野がTRUEの場合、古いRDN（ただし、新しいRDN）を形成する属性値がエントリから削除されます。 deleteoldrdn分野がFALSEの場合、古いRDNを形成する属性値がエントリの非区別属性値として保持されます。
Note that X.500 restricts the ModifyDN operation to affect only entries that are contained within a single server. If the LDAP server is mapped onto DAP, then this restriction will apply, and the affectsMultipleDSAs result code will be returned if this error occurred. In general, clients MUST NOT expect to be able to perform arbitrary movements of entries and subtrees between servers or between naming contexts.
X.500は、単一のサーバーの中に含まれているエントリのみに影響するように識別名の変更操作を制限することに注意してください。 LDAPサーバがDAPにマッピングされている場合、この制限が適用され、このエラーが発生した場合affectsMultipleDSAs結果コードが返されます。一般的には、クライアントは、サーバ間、または名前付けコンテキストの間のエントリやサブツリーの任意の運動を行うことができるように予想してはいけません。
The Compare operation allows a client to compare an assertion value with the values of a particular attribute in a particular entry in the Directory. The Compare Request is defined as follows:
比較操作は、クライアントがディレクトリ内の特定のエントリの特定の属性の値を持つアサーション値を比較することができます。次のように比較要求が定義されています。
CompareRequest ::= [APPLICATION 14] SEQUENCE {
entry LDAPDN,
ava AttributeValueAssertion }
Fields of the Compare Request are:
比較リクエストのフィールドは、次のとおりです。
- entry: the name of the entry to be compared. The server SHALL NOT dereference any aliases in locating the entry to be compared.
- エントリ：エントリの名前を比較します。サーバーを比較するエントリを見つけるのいずれかの別名間接参照してはなりません。
- ava: holds the attribute value assertion to be compared.
- AVA：比較する属性値のアサーションを保持しています。
Upon receipt of a Compare Request, a server will attempt to perform the requested comparison and return the result in the Compare Response, defined as follows:
比較のリクエストを受信すると、サーバは要求された比較を実行し、次のように定義され、比較応答で結果を返そうとします：
CompareResponse ::= [APPLICATION 15] LDAPResult
The resultCode is set to compareTrue, compareFalse, or an appropriate error. compareTrue indicates that the assertion value in the ava field matches a value of the attribute or subtype according to the attribute's EQUALITY matching rule. compareFalse indicates that the assertion value in the ava field and the values of the attribute or subtype did not match. Other result codes indicate either that the result of the comparison was Undefined (Section 4.5.1.7), or that some error occurred.
resultCodeはcompareTrue、compareFalse、または適切なエラーに設定されています。 compareTrueはAVAフィールドの主張値が属性の平等マッチングルールに従って属性またはサブタイプの値と一致することを示しています。 compareFalseはAVAフィールドの主張値と属性またはサブタイプの値が一致しなかったことを示しています。他の結果コードは、いずれかの比較結果が不定（セクション4.5.1.7）で、またはいくつかのエラーが発生したことを示しています。
Note that some directory systems may establish access controls that permit the values of certain attributes (such as userPassword) to be compared but not interrogated by other means.
いくつかのディレクトリシステムは、比較が、他の手段によって問い合わせないように（例えばのuserPasswordのような）特定の属性の値を許可するアクセス制御を確立することができることに留意されたいです。
The function of the Abandon operation is to allow a client to request that the server abandon an uncompleted operation. The Abandon Request is defined as follows:
放棄操作の機能は、クライアントは、サーバが未完了の操作を放棄することを要求することができるようにすることです。次のように放棄要求が定義されています。
AbandonRequest ::= [APPLICATION 16] MessageID
The MessageID is that of an operation that was requested earlier at this LDAP message layer. The Abandon request itself has its own MessageID. This is distinct from the MessageID of the earlier operation being abandoned.
メッセージIDは、このLDAPメッセージ層で先に要求された操作のことです。放棄要求自体は独自のメッセージIDを持っています。これは、放棄される以前の操作のメッセージIDとは区別されます。
There is no response defined in the Abandon operation. Upon receipt of an AbandonRequest, the server MAY abandon the operation identified by the MessageID. Since the client cannot tell the difference between a successfully abandoned operation and an uncompleted operation, the application of the Abandon operation is limited to uses where the client does not require an indication of its outcome.
放棄操作で定義された応答はありません。 AbandonRequestを受信すると、サーバーは、メッセージIDによって特定された操作を放棄することができます。クライアントが正常に捨てられた操作と未完了の操作の違いを言うことができないので、放棄操作のアプリケーションは、クライアントがその結果の表示を必要としない用途に限定されています。
Abandon, Bind, Unbind, and StartTLS operations cannot be abandoned.
放棄、バインド、バインド解除、およびStartTLSを操作は放棄することはできません。
In the event that a server receives an Abandon Request on a Search operation in the midst of transmitting responses to the Search, that server MUST cease transmitting entry responses to the abandoned request immediately, and it MUST NOT send the SearchResultDone. Of course, the server MUST ensure that only properly encoded LDAPMessage PDUs are transmitted.
サーバーが検索に応答を送信するの真っ只中に検索操作に放棄要求を受けた場合には、そのサーバーはすぐに捨てられたリクエストにエントリー応答を送信停止する必要があり、それはSearchResultDoneを送ってはいけません。もちろん、サーバは適切にエンコードされたLDAPMessageのPDUが送信されることを保証しなければなりません。
The ability to abandon other (particularly update) operations is at the discretion of the server.
他の（特に更新）動作を放棄する機能は、サーバの裁量です。
Clients should not send Abandon requests for the same operation multiple times, and they MUST also be prepared to receive results from operations they have abandoned (since these might have been in transit when the Abandon was requested or might not be able to be abandoned).
クライアントは、同じ操作を複数回の要求を放棄送るべきではない、と彼らはまた、（これらは、要求された中止または放棄さすることができない場合があります輸送中にあったかもしれないので）、彼らが放棄した操作の結果を受け取る準備が必要です。
Servers MUST discard Abandon requests for messageIDs they do not recognize, for operations that cannot be abandoned, and for operations that have already been abandoned.
サーバーは、彼らが放棄されることができない操作について、認識し、既に放棄されている業務用はありませんmessageIDsに対する要求を放棄捨てなければなりません。
The Extended operation allows additional operations to be defined for services not already available in the protocol; for example, to Add operations to install transport layer security (see Section 4.14).
拡張操作は、追加操作がプロトコルで既に利用可能ではないサービスのために定義されることを可能にします。例えば、トランスポート層セキュリティをインストールする操作を追加する（4.14節を参照してください）。
The Extended operation allows clients to make requests and receive responses with predefined syntaxes and semantics. These may be defined in RFCs or be private to particular implementations.
Extendedオペレーションは、クライアントが要求を行うと、あらかじめ定義された構文とセマンティクスを持つ応答を受け取ることができます。これらはRFCで定義されるか、または特定の実装にプライベートですることができます。
Each Extended operation consists of an Extended request and an Extended response.
各拡張操作が拡張要求と拡張応答から成ります。
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING OPTIONAL }
The requestName is a dotted-decimal representation of the unique OBJECT IDENTIFIER corresponding to the request. The requestValue is information in a form defined by that request, encapsulated inside an OCTET STRING.
requestNameは、要求に対応する一意のオブジェクト識別子のドット付き10進表現です。 requestValueはOCTET STRINGの内部に封入され、その要求によって定義された形式の情報です。
The server will respond to this with an LDAPMessage containing an ExtendedResponse.
サーバーは、ExtendedResponseを含むたLDAPMessageでこれに対応させていただきます。
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS OF LDAPResult,
responseName [10] LDAPOID OPTIONAL,
responseValue [11] OCTET STRING OPTIONAL }
The responseName field, when present, contains an LDAPOID that is unique for this extended operation or response. This field is optional (even when the extension specification defines an LDAPOID for use in this field). The field will be absent whenever the server is unable or unwilling to determine the appropriate LDAPOID to return, for instance, when the requestName cannot be parsed or its value is not recognized.
responseNameフィールドは、存在する場合、この拡張操作または反応のために一意であるLDAPOIDを含んでいます。このフィールドは、（拡張仕様は、この分野で使用するためLDAPOIDを定義した場合であっても）、任意です。サーバはrequestNameが解析できないか、その値が認識されない場合、例えば、返すために適切なLDAPOIDを決定することができない、または不本意であるたびにフィールドが存在しないであろう。
Where the requestName is not recognized, the server returns protocolError. (The server may return protocolError in other cases.)
requestNameが認識されない場合は、サーバーははProtocolErrorを返します。 （サーバは、他の場合にはProtocolErrorを返すことができます。）
The requestValue and responseValue fields contain information associated with the operation. The format of these fields is defined by the specification of the Extended operation. Implementations MUST be prepared to handle arbitrary contents of these fields, including zero bytes. Values that are defined in terms of ASN.1 and BER-encoded according to Section 5.1 also follow the extensibility rules in Section 4.
requestValueとresponseValueのフィールドは、操作に関連する情報が含まれています。これらのフィールドのフォーマットは、拡張操作の仕様によって定義されます。実装は、ゼロバイトを含むこれらのフィールドの任意のコンテンツを処理するために準備しなければなりません。セクション5.1に従ってASN.1とBERエンコードの観点で定義された値はまた、セクション4で拡張ルールに従います。
Servers list the requestName of Extended Requests they recognize in the 'supportedExtension' attribute in the root DSE (Section 5.1 of [RFC4512]).
サーバーは、ルートDSE（[RFC4512]の5.1節）の「supportedExtension」属性に認識し、拡張要求のrequestNameをリストアップ。
Extended operations may be specified in other documents. The specification of an Extended operation consists of:
拡張操作は、他の文書で指定することができます。 Extendedオペレーションの仕様は、から構成されています。
- the OBJECT IDENTIFIER assigned to the requestName,
- requestNameに割り当てられたオブジェクト識別子、
- the OBJECT IDENTIFIER (if any) assigned to the responseName (note that the same OBJECT IDENTIFIER may be used for both the requestName and responseName),
- responseName（同じオブジェクト識別子がrequestNameとresponseNameの両方に使用されてもよいことに留意されたい）に割り当てられたオブジェクト識別子（もしあれば）、
- the format of the contents of the requestValue and responseValue (if any), and
- requestValueとresponseValueのコンテンツのフォーマット（もしあれば）、および
- the semantics of the operation.
- 操作の意味。
While the Search operation provides a mechanism to return multiple response messages for a single Search request, other operations, by nature, do not provide for multiple response messages.
検索操作は、単一の検索要求に対して複数の応答メッセージを返すためにメカニズムを提供しているが、他の操作は、性質上、複数の応答メッセージのために提供されていません。
The IntermediateResponse message provides a general mechanism for defining single-request/multiple-response operations in LDAP. This message is intended to be used in conjunction with the Extended operation to define new single-request/multiple-response operations or in conjunction with a control when extending existing LDAP operations in a way that requires them to return Intermediate response information.
IntermediateResponseメッセージがLDAPでシングルリクエスト/複数の応答動作を定義するための一般的な機構を提供します。このメッセージは、中間応答情報を返すために、それらを必要とするようにして既存のLDAP操作を拡張するときに、新しいシングルリクエスト/複数の応答動作を定義したり、コントロールと一緒にするように拡張操作と連動して使用されることが意図されます。
It is intended that the definitions and descriptions of Extended operations and controls that make use of the IntermediateResponse message will define the circumstances when an IntermediateResponse message can be sent by a server and the associated meaning of an IntermediateResponse message sent in a particular circumstance.
IntermediateResponseメッセージがサーバと特定の状況で送信IntermediateResponseメッセージの関連する意味によって送信することができる場合IntermediateResponseメッセージを利用して拡張操作とコントロールの定義および説明は、状況を定義することが意図されています。
IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
responseName [0] LDAPOID OPTIONAL,
responseValue [1] OCTET STRING OPTIONAL }
IntermediateResponse messages SHALL NOT be returned to the client unless the client issues a request that specifically solicits their return. This document defines two forms of solicitation: Extended operation and request control. IntermediateResponse messages are specified in documents describing the manner in which they are solicited (i.e., in the Extended operation or request control specification that uses them). These specifications include:
クライアントは、特に彼らのリターンを勧誘要求を発行しない限り、IntermediateResponseメッセージがクライアントに返されないものとします。 Extendedオペレーションと要求制御：この文書では、勧誘の二つの形式を定義します。 IntermediateResponseメッセージは、それらが要請される方法を説明する文書に指定されている（すなわち、拡張操作またはそれらを使用して要求制御仕様で）。これらの仕様は以下のとおりです。
- the OBJECT IDENTIFIER (if any) assigned to the responseName,
- responseNameに割り当てられたオブジェクト識別子（もしあれば）、
- the format of the contents of the responseValue (if any), and
- responseValueのコンテンツのフォーマット（もしあれば）、および
- the semantics associated with the IntermediateResponse message.
- IntermediateResponseメッセージに関連付けられた意味論。
Extensions that allow the return of multiple types of IntermediateResponse messages SHALL identify those types using unique responseName values (note that one of these may specify no value).
ユニークresponseName値を使用してこれらのタイプを識別すべきである中間応答メッセージの複数のタイプの復帰を許可する拡張機能は、（これらのいずれかが値を指定しない場合があることに注意します）。
Sections 4.13.1 and 4.13.2 describe additional requirements on the inclusion of responseName and responseValue in IntermediateResponse messages.
セクション4.13.1と4.13.2はIntermediateResponseメッセージでresponseNameとresponseValueを含めることに関する追加要件について説明します。
A single-request/multiple-response operation may be defined using a single ExtendedRequest message to solicit zero or more IntermediateResponse messages of one or more kinds, followed by an ExtendedResponse message.
シングルリクエスト/複数の応答動作ExtendedResponseメッセージに続く一種または二種以上のゼロ以上IntermediateResponseメッセージを勧誘するために単一のExtendedRequestメッセージを使用して定義することができます。
A control's semantics may include the return of zero or more IntermediateResponse messages prior to returning the final result code for the operation. One or more kinds of IntermediateResponse messages may be sent in response to a request control.
コントロールの意味論は、動作のために、最終的な結果コードを返す前に、ゼロ以上IntermediateResponseメッセージのリターンを含むことができます。 IntermediateResponseメッセージの一種以上を要求制御に応答して送信されてもよいです。
All IntermediateResponse messages associated with request controls SHALL include a responseName. This requirement ensures that the client can correctly identify the source of IntermediateResponse messages when:
要求コントロールに関連付けられているすべてのIntermediateResponseメッセージはresponseNameを含むものとします。この要件は、クライアントが正しくときIntermediateResponseメッセージのソースを識別できるようになります：
- two or more controls using IntermediateResponse messages are included in a request for any LDAP operation or
- IntermediateResponseメッセージを使用して2つの以上のコントロールは、任意のLDAP操作の要求に含まれていますか
- one or more controls using IntermediateResponse messages are included in a request with an LDAP Extended operation that uses IntermediateResponse messages.
- IntermediateResponseメッセージを使用して、1つ以上のコントロールがIntermediateResponseメッセージを使用してLDAP拡張操作に要求に含まれています。
The Start Transport Layer Security (StartTLS) operation's purpose is to initiate installation of a TLS layer. The StartTLS operation is defined using the Extended operation mechanism described in Section 4.12.
スタートトランスポート層セキュリティ（StartTLSを）操作の目的は、TLS層のインストールを開始することです。 StartTLSを演算はセクション4.12に記載の拡張作動機構を使用して定義されます。
A client requests TLS establishment by transmitting a StartTLS request message to the server. The StartTLS request is defined in terms of an ExtendedRequest. The requestName is "1.3.6.1.4.1.1466.20037", and the requestValue field is always absent.
クライアントは、サーバにStartTLSを要求メッセージを送信することにより、TLSの確立を要求します。 StartTLSを要求がのExtendedRequestの用語で定義されています。 requestNameは「1.3.6.1.4.1.1466.20037」であり、requestValueフィールドが常に存在しません。
The client MUST NOT send any LDAP PDUs at this LDAP message layer following this request until it receives a StartTLS Extended response and, in the case of a successful response, completes TLS negotiations.
それはStartTLSを拡張応答を受信して、正常な応答の場合には、TLS交渉を完了するまで、クライアントはこの要求以下、このLDAPメッセージ層で任意のLDAP PDUを送ってはいけません。
Detected sequencing problems (particularly those detailed in Section 3.1.1 of [RFC4513]) result in the resultCode being set to operationsError.
検出されたシークエンシングの問題は、（特に、[RFC4513]のセクション3.1.1で詳述したもの）のresultCodeにおける結果はoperationsErrorに設定されています。
If the server does not support TLS (whether by design or by current configuration), it returns with the resultCode set to protocolError as described in Section 4.12.
サーバがTLSをサポートしていない場合（設計により、または現在のコンフィギュレーションによってかどうか）、それはセクション4.12に記載されているようにはProtocolErrorに設定にresultCodeと返します。
When a StartTLS request is received, servers supporting the operation MUST return a StartTLS response message to the requestor. The responseName is "1.3.6.1.4.1.1466.20037" when provided (see Section 4.12). The responseValue is always absent.
StartTLSを要求を受信すると、操作をサポートするサーバは、要求者にStartTLSを応答メッセージを返さなければなりません。 responseNameは、提供時に「1.3.6.1.4.1.1466.20037」（セクション4.12を参照）です。 responseValueは常に存在しません。
If the server is willing and able to negotiate TLS, it returns the StartTLS response with the resultCode set to success. Upon client receipt of a successful StartTLS response, protocol peers may commence with TLS negotiation as discussed in Section 3 of [RFC4513].
サーバがTLSを交渉する意思と能力であれば、それは成功に設定のresultCodeとのStartTLS応答を返します。 [RFC4513]のセクション3で説明したように成功StartTLSを応答のクライアント受信すると、プロトコル・ピアはTLSネゴシエーションで開始することができます。
If the server is otherwise unwilling or unable to perform this operation, the server is to return an appropriate result code indicating the nature of the problem. For example, if the TLS subsystem is not presently available, the server may indicate this by returning with the resultCode set to unavailable. In cases where a non-success result code is returned, the LDAP session is left without a TLS layer.
サーバーが他の不本意またはこの操作を実行できない場合、サーバは、問題の性質を示す適切な結果コードを返すことです。 TLSサブシステムが現在利用できない場合、例えば、サーバが使用不能に設定resultCodeがして返すことによって、これを示すことがあります。非成功の結果コードが返された場合には、LDAPセッションはTLS層なしで残されています。
Either the client or server MAY remove the TLS layer and leave the LDAP message layer intact by sending and receiving a TLS closure alert.
クライアントまたはサーバはTLS層を除去し、TLS閉鎖警戒を送受信することにより、完全なLDAPメッセージ層を残すことができます。
The initiating protocol peer sends the TLS closure alert and MUST wait until it receives a TLS closure alert from the other peer before sending further LDAP PDUs.
開始側プロトコルピアはTLS閉鎖警戒を送信し、それがさらにLDAP PDUを送信する前に他のピアからのTLS閉鎖警戒を受信するまで待たなければなりません。
When a protocol peer receives the initial TLS closure alert, it may choose to allow the LDAP message layer to remain intact. In this case, it MUST immediately transmit a TLS closure alert. Following this, it MAY send and receive LDAP PDUs.
プロトコルピアが初期TLS閉鎖警戒を受信すると、LDAPメッセージ層がそのまま残ることができるように選択できます。この場合、それはすぐに、TLS閉鎖警戒を伝えなければなりません。これに続いて、それはLDAP PDUを送受信し得ます。
Protocol peers MAY terminate the LDAP session after sending or receiving a TLS closure alert.
プロトコルピアはTLS閉鎖警戒を送信または受信した後、LDAPセッションを終了することができます。
This protocol is designed to run over connection-oriented, reliable transports, where the data stream is divided into octets (8-bit units), with each octet and each bit being significant.
このプロトコルは、各オクテット各ビットが有意であると、データストリームは、オクテット（8ビット単位）に分割されている接続指向、信頼性の高いトランスポート上で実行するように設計されています。
One underlying service, LDAP over TCP, is defined in Section 5.2. This service is generally applicable to applications providing or consuming X.500-based directory services on the Internet. This specification was generally written with the TCP mapping in mind. Specifications detailing other mappings may encounter various obstacles.
一つの基本的なサービス、TCP上のLDAPは、セクション5.2で定義されています。このサービスは、インターネット上のX.500ベースのディレクトリサービスを提供するか、消費するアプリケーションに適用可能です。この仕様は、一般的に念頭に置いてTCPマップで書かれていました。他のマッピングを詳細な仕様は、様々な障害が発生することがあります。
Implementations of LDAP over TCP MUST implement the mapping as described in Section 5.2.
5.2節で説明したようにTCP上のLDAPの実装は、マッピングを実装しなければなりません。
This table illustrates the relationship among the different layers involved in an exchange between two protocol peers:
この表は、2つのプロトコルピア間交換に関与する種々の層の関係を示す図です。
+----------------------+
| LDAP message layer |
+----------------------+ > LDAP PDUs
+----------------------+ < data
| SASL layer |
+----------------------+ > SASL-protected data
+----------------------+ < data
| TLS layer |
Application +----------------------+ > TLS-protected data
------------+----------------------+ < data
Transport | transport connection |
+----------------------+
The protocol elements of LDAP SHALL be encoded for exchange using the Basic Encoding Rules [BER] of [ASN.1] with the following restrictions:
LDAPのプロトコル要素は、次の制限付き[ASN.1]の基本符号化規則[BER]を使用して、交換のために符号化されなければなりません。
- Only the definite form of length encoding is used.
- レングス符号化のみ明確な形が使用されます。
- OCTET STRING values are encoded in the primitive form only.
- OCTET STRINGの値のみプリミティブ形式で符号化されます。
- If the value of a BOOLEAN type is true, the encoding of the value octet is set to hex "FF".
- ブール型の値がtrueの場合、値オクテットの符号化は、「FF」をヘクスに設定されています。
- If a value of a type is its default value, it is absent. Only some BOOLEAN and INTEGER types have default values in this protocol definition.
- 型の値がデフォルト値である場合、それは存在しません。唯一のいくつかのBOOLEANとINTEGER型は、このプロトコル定義のデフォルト値を持っています。
These restrictions are meant to ease the overhead of encoding and decoding certain elements in BER.
これらの制限は、BERで符号化及び復号化特定の要素のオーバーヘッドを軽減することを意味します。
These restrictions do not apply to ASN.1 types encapsulated inside of OCTET STRING values, such as attribute values, unless otherwise stated.
特に明記しない限り、これらの制限は、そのような属性値としてオクテット文字列値の内にカプセル化ASN.1タイプには適用されません。
The encoded LDAPMessage PDUs are mapped directly onto the TCP [RFC793] bytestream using the BER-based encoding described in Section 5.1. It is recommended that server implementations running over the TCP provide a protocol listener on the Internet Assigned Numbers Authority (IANA)-assigned LDAP port, 389 [PortReg]. Servers may instead provide a listener on a different port number. Clients MUST support contacting servers on any valid TCP port.
符号化されたLDAPMessage PDUは、セクション5.1に記載BERベースの符号化を使用してバイトストリーム[RFC793] TCPに直接マッピングされます。 TCP上で実行しているサーバーの実装は、IANA（Internet Assigned Numbers Authority）の上のプロトコル・リスナーを提供することをお勧めします[PortReg] LDAPポート、389 -assigned。サーバは代わりに別のポート番号でリスナーを提供することができます。クライアントは、任意の有効なTCPポート上のサーバーに連絡サポートしなければなりません。
Termination of the LDAP session is typically initiated by the client sending an UnbindRequest (Section 4.3), or by the server sending a Notice of Disconnection (Section 4.4.1). In these cases, each protocol peer gracefully terminates the LDAP session by ceasing exchanges at the LDAP message layer, tearing down any SASL layer, tearing down any TLS layer, and closing the transport connection.
LDAPセッションの終了は、通常UnbindRequestを（4.3節）、送信するクライアントまたは切断（4.4.1）のお知らせを送信するサーバによって開始されます。これらのケースでは、各プロトコルピアは正常、任意SASL層を切断任意TLS層を切断、およびトランスポート接続を閉じ、LDAPメッセージ層に交流を停止して、LDAPセッションを終了します。
A protocol peer may determine that the continuation of any communication would be pernicious, and in this case, it may abruptly terminate the session by ceasing communication and closing the transport connection.
プロトコルピアは、任意の通信の継続が悪性であろうと判断してもよいが、この場合には、急激に通信を中止し、移送接続を閉じてセッションを終了することができます。
In either case, when the LDAP session is terminated, uncompleted operations are handled as specified in Section 3.1.
LDAPセッションが終了したときにどちらの場合も、未完了の操作は、セクション3.1で指定されるように処理されます。
This version of the protocol provides facilities for simple authentication using a cleartext password, as well as any SASL [RFC4422] mechanism. Installing SASL and/or TLS layers can provide integrity and other data security services.
プロトコルのこのバージョンでは、単純な平文パスワードを用いた認証、ならびに任意のSASL [RFC4422]メカニズムのための設備を提供します。 SASLおよび/またはTLS層をインストールすると、整合性と、他のデータ・セキュリティ・サービスを提供することができます。
It is also permitted that the server can return its credentials to the client, if it chooses to do so.
また、それがそうすることを選択した場合、サーバーは、クライアントにその資格情報を返すことができることを許可されています。
Use of cleartext password is strongly discouraged where the underlying transport service cannot guarantee confidentiality and may result in disclosure of the password to unauthorized parties.
基礎となるトランスポートサービスは、機密性を保証することはできませんし、権限のない者にパスワードの開示をもたらすことができる場所を平文パスワードの使用を強くお勧めします。
Servers are encouraged to prevent directory modifications by clients that have authenticated anonymously [RFC4513].
サーバーが匿名で[RFC4513]認証されたクライアントによるディレクトリの変更を防ぐために奨励されています。
Security considerations for authentication methods, SASL mechanisms, and TLS are described in [RFC4513].
認証方法、SASLメカニズム、およびTLSのセキュリティの考慮事項は、[RFC4513]に記載されています。
Note that SASL authentication exchanges do not provide data confidentiality or integrity protection for the version or name fields of the BindRequest or the resultCode, diagnosticMessage, or referral fields of the BindResponse, nor for any information contained in controls attached to Bind requests or responses. Thus, information contained in these fields SHOULD NOT be relied on unless it is otherwise protected (such as by establishing protections at the transport layer).
、SASL認証交換はBindRequestかのresultCodeのバージョンや名前のフィールドのデータの機密性や完全性保護を提供しないことに注意してくださいdiagnosticMessage、またはBindResponseの紹介分野、また要求または応答をバインドするために添付のコントロールに含まれるすべての情報について。それはそうでなければ（例えば、トランスポート層で保護を確立することなどによって）保護されていない限り、このように、これらのフィールドに含まれる情報が依拠するべきではありません。
Implementors should note that various security factors (including authentication and authorization information and data security services) may change during the course of the LDAP session or even during the performance of a particular operation. For instance, credentials could expire, authorization identities or access controls could change, or the underlying security layer(s) could be replaced or terminated. Implementations should be robust in the handling of changing security factors.
実装者は、（認証と認可の情報とデータのセキュリティサービスを含む）様々なセキュリティ要因はLDAPセッションの途中で、あるいは特定の操作の実行時に変更される可能性があることに注意してください。例えば、資格証明書は、有効期限が切れる認証アイデンティティやアクセス制御は変更される可能性があり、または基礎となるセキュリティ層（複数可）を交換または終了することができたことができました。実装は、セキュリティの要因を変えるの取り扱いに堅牢でなければなりません。
In some cases, it may be appropriate to continue the operation even in light of security factor changes. For instance, it may be appropriate to continue an Abandon operation regardless of the change, or to continue an operation when the change upgraded (or maintained) the security factor. In other cases, it may be appropriate to fail or alter the processing of the operation. For instance, if confidential protections were removed, it would be appropriate either to fail a request to return sensitive data or, minimally, to exclude the return of sensitive data.
いくつかのケースでは、それもセキュリティ係数変化に照らして動作を継続することが適切であり得ます。例えば、関係なく、変更の操作を中止、または変更がアップグレード（または維持）する際のセキュリティ因子動作を継続し続けることが適切であり得ます。他の場合には、失敗するか、または操作の処理を変更するために適切であり得ます。機密保護が削除された場合例えば、それは機密データの復帰を除外するために機密データや、最小限の、返すように要求を失敗するか適切であろう。
Implementations that cache attributes and entries obtained via LDAP MUST ensure that access controls are maintained if that information is to be provided to multiple clients, since servers may have access control policies that prevent the return of entries or attributes in Search results except to particular authenticated clients. For example, caches could serve result information only to the client whose request caused it to be in the cache.
その情報が複数のクライアントに提供する場合は、サーバは、特定の認証されたクライアントを除いて検索結果のエントリや属性の戻りを防ぐアクセス制御ポリシーを持っている可能性があるため、LDAPを介して取得した属性とエントリをキャッシュ実装は、そのアクセス制御が維持されることを保証しなければなりません。例えば、キャッシュはリクエストのみがキャッシュにあることが原因とクライアントに結果情報を果たすことができました。
Servers may return referrals or Search result references that redirect clients to peer servers. It is possible for a rogue application to inject such referrals into the data stream in an attempt to redirect a client to a rogue server. Clients are advised to be aware of this and possibly reject referrals when confidentiality measures are not in place. Clients are advised to reject referrals from the StartTLS operation.
サーバは、サーバをピアにクライアントをリダイレクト紹介や検索結果の参照を返すことがあります。不正なアプリケーションが不正なサーバーにクライアントをリダイレクトする試みでデータストリームに、このような紹介を注入することが可能です。クライアントはこれを認識し、機密保持の措置が行われていないとき、おそらく紹介を拒否することをお勧めします。クライアントは、StartTLSを操作から紹介を拒否することをお勧めします。
The matchedDN and diagnosticMessage fields, as well as some resultCode values (e.g., attributeOrValueExists and entryAlreadyExists), could disclose the presence or absence of specific data in the directory that is subject to access and other administrative controls. Server implementations should restrict access to protected information equally under both normal and error conditions.
matchedDNとdiagnosticMessageフィールド、ならびにいくつかのresultCode値（例えば、attributeOrValueExistsとentryAlreadyExists）は、アクセスおよび他の管理制御の対象となるディレクトリ内の特定のデータの有無を開示している可能性があります。サーバ実装は、正常と異常の両方の条件の下で平等に保護された情報へのアクセスを制限する必要があります。
Protocol peers MUST be prepared to handle invalid and arbitrary-length protocol encodings. Invalid protocol encodings include: BER encoding exceptions, format string and UTF-8 encoding exceptions, overflow exceptions, integer value exceptions, and binary mode on/off flag exceptions. The LDAPv3 PROTOS [PROTOS-LDAP] test suite provides excellent examples of these exceptions and test cases used to discover flaws.
プロトコルピアは無効と任意の長さのプロトコル符号化を処理するために準備されなければなりません。無効なプロトコルエンコーディングは：BERエンコード例外、書式文字列とUTF-8エンコーディング例外、オーバーフロー例外、整数値例外、および/オフフラグ例外でバイナリモード。 LDAPv3 PROTOS [PROTOS-LDAP]テストスイートは、欠陥を発見するために使用されるこれらの例外とテストケースの優れた例を提供します。
In the event that a protocol peer senses an attack that in its nature could cause damage due to further communication at any layer in the LDAP session, the protocol peer should abruptly terminate the LDAP session as described in Section 5.3.
セクション5.3で説明したようにプロトコルピアがその性質にLDAPセッションにおけるいずれの層に起因する更なる通信に損傷を引き起こす可能性が攻撃を検知した場合に、プロトコルピアは急激LDAPセッションを終了すべきです。
This document is based on RFC 2251 by Mark Wahl, Tim Howes, and Steve Kille. RFC 2251 was a product of the IETF ASID Working Group.
この文書は、マーク・ワール、ティムハウズ、およびスティーブKilleによってRFC 2251に基づいています。 RFC 2251は、IETF ASID作業部会の製品でした。
It is also based on RFC 2830 by Jeff Hodges, RL "Bob" Morgan, and Mark Wahl. RFC 2830 was a product of the IETF LDAPEXT Working Group.
また、ジェフ・ホッジス、RL「ボブ」・モーガン、そしてマーク・ワールによってRFC 2830に基づいています。 RFC 2830は、IETF LDAPEXT作業部会の製品でした。
It is also based on RFC 3771 by Roger Harrison and Kurt Zeilenga. RFC 3771 was an individual submission to the IETF.
またロジャー・ハリソンとクルトZeilengaによってRFC 3771に基づいています。 RFC 3771は、IETFへの個々の提出しました。
This document is a product of the IETF LDAPBIS Working Group. Significant contributors of technical review and content include Kurt Zeilenga, Steven Legg, and Hallvard Furuseth.
この文書は、IETF LDAPBISワーキンググループの製品です。技術的な見直しとコンテンツの重要な貢献者はクルトZeilenga、スティーブンレッグ、およびHallvard Furusethが含まれます。
[ASN.1] ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824- 1:2002 "Information Technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation".
[ASN.1] ITU-T勧告X.680（07/2002）| ISO / IEC 8824- 1：2002 "情報技術 - 抽象構文記法1（ASN.1）：基本的な表記法の仕様"。
[BER] ITU-T Rec. X.690 (07/2002) | ISO/IEC 8825-1:2002, "Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", 2002.
[BER] ITU-T勧告。 X.690（07/2002）| ISO / IEC 8825から1：2002、 "情報技術 - ASN.1エンコーディング規則：基本符号化規則（BER）の仕様、Canonicalの符号化規則（CER）、および顕著な符号化規則（DER）"、2002年。
[ISO10646] Universal Multiple-Octet Coded Character Set (UCS) - Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 : 1993.
[ISO10646]ユニバーサルマルチオクテット符号化文字セット（UCS） - アーキテクチャと基本多言語面、ISO / IEC 10646-1：1993。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[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月。
[RFC3454] Hoffman P. and M. Blanchet, "Preparation of Internationalized Strings ('stringprep')", RFC 3454, December 2002.
[RFC3454]ホフマンP.及びM.ブランシェ、 "国際化された文字列の調製（ '文字列準備'）"、RFC 3454、2002年12月。
[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月。
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[RFC4013] Zeilenga、K.、 "SASLprep：ユーザ名とパスワードのためのstringprepプロフィール"、RFC 4013、2005年2月。
[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月。
[RFC4346] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", RFC 4346, March 2006.
[RFC4346]ダークス、T.およびE.レスコラ、 "TLSプロトコルバージョン1.1"、RFC 4346、2006年3月。
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422]メルニコフ、A.編。そして、K. Zeilenga、エド。、 "簡易認証セキュリティー層（SASL）"、RFC 4422、2006年6月。
[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月。
[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月。
[RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator", RFC 4516, June 2006.
[RFC4516]スミス、M.、エド。そして、T.ハウズ、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：ユニフォームリソースロケータ"、RFC 4516、2006年6月。
[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
[RFC4517]レッグ、S.、エド、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：構文と一致規則"、RFC 4517、2006年6月。
[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月。
[Unicode] The Unicode Consortium, "The Unicode Standard, Version 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201- 61633-5), as amended by the "Unicode Standard Annex #27: Unicode 3.1" (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/).
[UNICODE]ユニコードコンソーシアムは、 "Unicode標準、バージョン3.2.0" は、 "Unicode規格、バージョン3.0"（読書、MA、アディソン・ウェズリー、61633から5 2000. ISBN 0-201-）などによって定義されます改正 "Unicode標準の附属書＃27：ユニコード3.1"（http://www.unicode.org/reports/tr27/）とで "Unicode標準の附属書＃28：Unicodeの3.2"（のhttp：//www.unicode .ORG /レポート/ TR28 /）。
[X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts, Models and Service", 1993.
[X.500] ITU-T勧告。 X.500、「ディレクトリ：概念、モデルとサービスの概要」、1993年。
[X.511] ITU-T Rec. X.511, "The Directory: Abstract Service Definition", 1993.
[X.511] ITU-T勧告。 X.511、 "ディレクトリ：抽象サービス定義"、1993年。
[CharModel] Whistler, K. and M. Davis, "Unicode Technical Report #17, Character Encoding Model", UTR17, <http://www.unicode.org/unicode/reports/tr17/>, August 2000.
[CharModel]ウィスラー、K.とM.デイヴィス、 "Unicodeの技術レポート＃17、文字エンコーディングモデル"、UTR17、<http://www.unicode.org/unicode/reports/tr17/>、2000年8月。
[Glossary] The Unicode Consortium, "Unicode Glossary", <http://www.unicode.org/glossary/>.
[用語]ユニコードコンソーシアム、 "ユニコード用語"、<http://www.unicode.org/glossary/>。
[PortReg] IANA, "Port Numbers", <http://www.iana.org/assignments/port-numbers>.
[PortReg] IANA、 "ポート番号"、<http://www.iana.org/assignments/port-numbers>。
[PROTOS-LDAP] University of Oulu, "PROTOS Test-Suite: c06-ldapv3" <http://www.ee.oulu.fi/research/ouspg/protos/testing/ c06/ldapv3/>.
オウルの[PROTOS-LDAP]大学は、 "PROTOSテストスイート：C06-のLDAPv3" <http://www.ee.oulu.fi/research/ouspg/protos/testing/ C06 /のLDAPv3 />。
The Internet Assigned Numbers Authority (IANA) has updated the LDAP result code registry to indicate that this document provides the definitive technical specification for result codes 0-36, 48-54, 64- 70, 80-90. It is also noted that one resultCode value (strongAuthRequired) has been renamed (to strongerAuthRequired).
IANA（Internet Assigned Numbers Authority）は、この文書は、結果コード0から36まで、48から54、64 70、80〜90のための決定的な技術仕様を提供することを示すために、LDAP結果コードレジストリを更新しました。また、1つのresultCode値（strongAuthRequiredが）（strongerAuthRequiredに）名前が変更されたことに留意されたいです。
The IANA has also updated the LDAP Protocol Mechanism registry to indicate that this document and [RFC4513] provides the definitive technical specification for the StartTLS (1.3.6.1.4.1.1466.20037) Extended operation.
IANAはこのドキュメントと[RFC4513]はStartTLSを（1.3.6.1.4.1.1466.20037）拡張操作のために決定的な技術仕様を提供することを示すために、LDAPプロトコルメカニズムレジストリを更新しました。
IANA has assigned LDAP Object Identifier 18 [RFC4520] to identify the ASN.1 module defined in this document.
IANAは、この文書で定義されたASN.1モジュールを識別するために、LDAPオブジェクト識別子18 [RFC4520]を割り当てています。
Subject: Request for LDAP Object Identifier Registration
Person & email address to contact for further information:
Jim Sermersheim <jimse@novell.com>
Specification: RFC 4511
Author/Change Controller: IESG
Comments:
Identifies the LDAP ASN.1 module
Appendix A. LDAP Result Codes
付録A. LDAPの結果コード
This normative appendix details additional considerations regarding LDAP result codes and provides a brief, general description of each LDAP result code enumerated in Section 4.1.9.
この規範的な付録では、LDAPの結果コードに関する追加の考慮事項を詳述し、第4.1.9項に列挙された各LDAP結果コードの簡潔な、一般的な説明を提供します。
Additional result codes MAY be defined for use with extensions [RFC4520]. Client implementations SHALL treat any result code that they do not recognize as an unknown error condition.
追加の結果コードは、拡張[RFC4520]で使用するために定義されるかもしれません。クライアントの実装は、彼らが不明なエラー状態として認識していない任意の結果コードを処理するものとします。
The descriptions provided here do not fully account for result code substitutions used to prevent unauthorized disclosures (such as substitution of noSuchObject for insufficientAccessRights, or invalidCredentials for insufficientAccessRights).
ここで提供される記述は、完全に（そのようinsufficientAccessRightsのためのnoSuchObjectの置換、またはinsufficientAccessRights用invalidCredentialsなど）の不正開示を防止するために使用される結果コードの置換を考慮していません。
A.1. Non-Error Result Codes
A.1。非エラー結果コード
These result codes (called "non-error" result codes) do not indicate an error condition:
（「非エラー」結果コードと呼ばれる）これらの結果コードは、エラー状態を示すものではありません。
success (0),
compareFalse (5),
compareTrue (6),
referral (10), and
saslBindInProgress (14).
The success, compareTrue, and compareFalse result codes indicate successful completion (and, hence, are referred to as "successful" result codes).
成功は、compareTrue、及びcompareFalse結果コードは、（「成功」結果コードと呼ばれ、したがって、と）正常に完了したことを示しています。
The referral and saslBindInProgress result codes indicate the client needs to take additional action to complete the operation.
紹介とsaslBindInProgress結果コードは、クライアントが操作を完了するために、追加のアクションを実行する必要がありますを示しています。
A.2. Result Codes
A.2。結果コード
Existing LDAP result codes are described as follows:
次のように既存のLDAP結果コードが記述されています。
success (0) Indicates the successful completion of an operation. Note: this code is not used with the Compare operation. See compareFalse (5) and compareTrue (6).
成功（0）操作が正常に完了したことを示します。注：このコードは、比較操作で使用されていません。 compareFalse（5）とcompareTrue（6）を参照してください。
operationsError (1) Indicates that the operation is not properly sequenced with relation to other operations (of same or different type).
operationsErrorは、（1）動作が正常（同じまたは異なるタイプの）他の動作との関係を用いて配列決定されていないことを示します。
For example, this code is returned if the client attempts to StartTLS [RFC4346] while there are other uncompleted operations or if a TLS layer was already installed.
クライアントが他の未完了の操作であるか、またはTLS層が既にインストールされている場合ながらStartTLSを[RFC4346]しようとする場合、例えば、このコードが返されます。
protocolError (2) Indicates the server received data that is not well-formed.
ProtocolError（2）十分に形成されていないサーバ、受信したデータを示します。
For Bind operation only, this code is also used to indicate that the server does not support the requested protocol version.
唯一のバインド操作のために、このコードは、サーバーが要求されたプロトコルのバージョンをサポートしていないことを示すために使用されます。
For Extended operations only, this code is also used to indicate that the server does not support (by design or configuration) the Extended operation associated with the requestName.
のみ拡張操作のために、このコードは、サーバーが（設計または構成によって）requestNameに関連する拡張操作をサポートしていないことを示すために使用されます。
For request operations specifying multiple controls, this may be used to indicate that the server cannot ignore the order of the controls as specified, or that the combination of the specified controls is invalid or unspecified.
複数のコントロールを指定する要求操作の場合、これは、サーバが指定されているコントロールの順序を無視する、または指定されたコントロールの組み合わせが無効であるか、または指定されていないことができないことを示すために使用されてもよいです。
timeLimitExceeded (3) Indicates that the time limit specified by the client was exceeded before the operation could be completed.
timeLimitExceededは（3）操作が完了する前に、クライアントによって指定された時間制限を超えたことを示します。
sizeLimitExceeded (4) Indicates that the size limit specified by the client was exceeded before the operation could be completed.
sizeLimitExceededは（4）の操作が完了する前に、クライアントが指定したサイズ制限を超えたことを示します。
compareFalse (5) Indicates that the Compare operation has successfully completed and the assertion has evaluated to FALSE or Undefined.
compareFalseは（5）の比較操作が正常に完了したと表明がFALSEまたはundefinedに評価されたことを示します。
compareTrue (6) Indicates that the Compare operation has successfully completed and the assertion has evaluated to TRUE.
compareTrueは（6）の比較操作が正常に完了したと主張がTRUEと評価されたことを示します。
authMethodNotSupported (7) Indicates that the authentication method or mechanism is not supported.
authMethodNotSupported（7）認証方法または機構がサポートされていないことを示します。
strongerAuthRequired (8) Indicates the server requires strong(er) authentication in order to complete the operation.
strongerAuthRequiredは（8）サーバは、操作を完了するために強い（ER）の認証を必要とすることを示します。
When used with the Notice of Disconnection operation, this code indicates that the server has detected that an established security association between the client and server has unexpectedly failed or been compromised.
切断操作の通知に使用される場合、このコードは、サーバーが、クライアントとサーバの間で確立されたセキュリティアソシエーションが予期せず失敗したまたは損なわれていることを検出したことを示しています。
referral (10) Indicates that a referral needs to be chased to complete the operation (see Section 4.1.10).
紹介（10）（セクション4.1.10を参照）の紹介、操作を完了するために追われる必要があることを示します。
adminLimitExceeded (11) Indicates that an administrative limit has been exceeded.
adminLimitExceeded（11）が、管理限界を超えたことを示します。
unavailableCriticalExtension (12) Indicates a critical control is unrecognized (see Section 4.1.11).
unavailableCriticalExtension（12）は、重要なコントロールが認識されないことを示します（セクション4.1.11を参照してください）。
confidentialityRequired (13) Indicates that data confidentiality protections are required.
confidentialityRequired（13）は、データの機密性の保護が必要とされていることを示します。
saslBindInProgress (14) Indicates the server requires the client to send a new bind request, with the same SASL mechanism, to continue the authentication process (see Section 4.2).
saslBindInProgress（14）は、サーバが（4.2節を参照）、認証プロセスを継続するために、同じSASL機構が、新しいバインド要求を送信するためにクライアントが必要となることを示します。
noSuchAttribute (16) Indicates that the named entry does not contain the specified attribute or attribute value.
noSuchAttribute（16）という名前のエントリが指定された属性または属性値が含まれていないことを示します。
undefinedAttributeType (17) Indicates that a request field contains an unrecognized attribute description.
undefinedAttributeType（17）は、要求フィールドが認識されていない属性記述が含まれていることを示します。
inappropriateMatching (18) Indicates that an attempt was made (e.g., in an assertion) to use a matching rule not defined for the attribute type concerned.
（18）inappropriateMatchingする試みが（例えば、アサーションでは）当該属性タイプに対して定義されていないマッチング規則を使用するようになされたことを示します。
constraintViolation (19) Indicates that the client supplied an attribute value that does not conform to the constraints placed upon it by the data model.
constraintViolation（19）は、クライアントがデータモデルによって、それの上に置かれた制約に適合しない属性値を供給することを示します。
For example, this code is returned when multiple values are supplied to an attribute that has a SINGLE-VALUE constraint.
複数の値が単一の値の制約を有する属性に供給される場合、例えば、このコードが返されます。
attributeOrValueExists (20) Indicates that the client supplied an attribute or value to be added to an entry, but the attribute or value already exists.
attributeOrValueExists（20）は、クライアントがエントリに追加される属性または値を供給することを示したが、属性または値は既に存在します。
invalidAttributeSyntax (21) Indicates that a purported attribute value does not conform to the syntax of the attribute.
invalidAttributeSyntax（21）は、自称属性値は属性の構文に準拠していないことを示します。
noSuchObject (32) Indicates that the object does not exist in the DIT.
noSuchObject（32）オブジェクトがDITに存在しないことを示します。
aliasProblem (33) Indicates that an alias problem has occurred. For example, the code may used to indicate an alias has been dereferenced that names no object.
aliasProblem（33）は、エイリアス問題が発生したことを示します。例えば、コードは、別名が名前のないオブジェクトことが間接参照されたことを示すために使用することができます。
invalidDNSyntax (34) Indicates that an LDAPDN or RelativeLDAPDN field (e.g., search base, target entry, ModifyDN newrdn, etc.) of a request does not conform to the required syntax or contains attribute values that do not conform to the syntax of the attribute's type.
invalidDNSyntax（34）は、要求のLDAPDNまたはRelativeLDAPDNフィールド（例えば、検索ベース、エントリーをターゲット、識別名の変更newrdn、など）が必要な構文に準拠していないことを示しまたは属性の構文に準拠していない属性値が含まれていますタイプ。
aliasDereferencingProblem (36) Indicates that a problem occurred while dereferencing an alias. Typically, an alias was encountered in a situation where it was not allowed or where access was denied.
aliasDereferencingProblem（36）は別名を参照解除中に問題が発生したことを示します。通常、別名は、それが許されなかった場合やアクセスが拒否された状況に遭遇しました。
inappropriateAuthentication (48) Indicates the server requires the client that had attempted to bind anonymously or without supplying credentials to provide some form of credentials.
inappropriateAuthentication（48）は、サーバが匿名または資格情報のいくつかのフォームを提供するために、資格情報を入力せずにバインドしようとしましたクライアントを必要と示します。
invalidCredentials (49) Indicates that the provided credentials (e.g., the user's name and password) are invalid.
invalidCredentials（49）が提供された資格情報（例えば、ユーザ名とパスワード）が無効であることを示します。
insufficientAccessRights (50) Indicates that the client does not have sufficient access rights to perform the operation.
insufficientAccessRights（50）は、クライアントが操作を実行するのに十分なアクセス権を持っていないことを示します。
busy (51) Indicates that the server is too busy to service the operation.
（51）忙しいが、サーバーが操作にサービスを提供するためにビジー状態であることを示します。
unavailable (52) Indicates that the server is shutting down or a subsystem necessary to complete the operation is offline.
（52）利用できないが、サーバーがシャットダウンしているか、操作を完了するために必要なサブシステムがオフラインであることを示します。
unwillingToPerform (53) Indicates that the server is unwilling to perform the operation.
unwillingToPerform（53）は、サーバーが操作を実行するために不本意であることを示します。
loopDetect (54) Indicates that the server has detected an internal loop (e.g., while dereferencing aliases or chaining an operation).
loopDetect（54）（別名を間接参照や操作を連鎖しながら、例えば）サーバは、内部ループを検出したことを示します。
namingViolation (64) Indicates that the entry's name violates naming restrictions.
namingViolation（64）は、エントリの名前が命名の制限に違反していることを示します。
objectClassViolation (65) Indicates that the entry violates object class restrictions.
objectClassViolation（65）は、エントリは、オブジェクトクラスの制限に違反していることを示します。
notAllowedOnNonLeaf (66) Indicates that the operation is inappropriately acting upon a non-leaf entry.
notAllowedOnNonLeaf（66）は、操作が不適切非リーフエントリに作用していることを示します。
notAllowedOnRDN (67) Indicates that the operation is inappropriately attempting to remove a value that forms the entry's relative distinguished name.
notAllowedOnRDN（67）は、操作が不適切エントリの相対識別名を形成して値を削除しようとしていることを示します。
entryAlreadyExists (68) Indicates that the request cannot be fulfilled (added, moved, or renamed) as the target entry already exists.
entryAlreadyExists（68）は、要求を満たすことができないことを示し、ターゲットエントリがすでに存在しているように（追加、移動、または名前変更）。
objectClassModsProhibited (69) Indicates that an attempt to modify the object class(es) of an entry's 'objectClass' attribute is prohibited.
objectClassModsProhibited（69）は、エントリの「オブジェクトクラス」属性のオブジェクトクラス（ES）を変更しようとする試みが禁止されていることを示します。
For example, this code is returned when a client attempts to modify the structural object class of an entry.
例えば、このコードは、クライアントは、エントリの構造化オブジェクト・クラスを変更しようとしたときに返されます。
affectsMultipleDSAs (71) Indicates that the operation cannot be performed as it would affect multiple servers (DSAs).
affectsMultipleDSAs（71）は、複数のサーバ（のDSA）に影響するなどの操作を行うことができないことを示します。
other (80) Indicates the server has encountered an internal error.
その他（80）は、サーバが内部エラーが発生したことを示します。
Appendix B. Complete ASN.1 Definition
付録B.完全なASN.1定義
This appendix is normative.
この付録は規範的です。
Lightweight-Directory-Access-Protocol-V3 {1 3 6 1 1 18}
-- Copyright (C) The Internet Society (2006). This version of
-- this ASN.1 module is part of RFC 4511; see the RFC itself
-- for full legal notices.
DEFINITIONS
IMPLICIT TAGS
EXTENSIBILITY IMPLIED ::=
BEGIN
ベギン
LDAPMessage ::= SEQUENCE {
messageID MessageID,
protocolOp CHOICE {
bindRequest BindRequest,
bindResponse BindResponse,
unbindRequest UnbindRequest,
searchRequest SearchRequest,
searchResEntry SearchResultEntry,
searchResDone SearchResultDone,
searchResRef SearchResultReference,
modifyRequest ModifyRequest,
modifyResponse ModifyResponse,
addRequest AddRequest,
addResponse AddResponse,
delRequest DelRequest,
delResponse DelResponse,
modDNRequest ModifyDNRequest,
modDNResponse ModifyDNResponse,
compareRequest CompareRequest,
compareResponse CompareResponse,
abandonRequest AbandonRequest,
extendedReq ExtendedRequest,
extendedResp ExtendedResponse,
...,
intermediateResponse IntermediateResponse },
controls [0] Controls OPTIONAL }
MessageID ::= INTEGER (0 .. maxInt)
maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
LDAPString ::= OCTET STRING -- UTF-8 encoded,
-- [ISO10646] characters
LDAPOID ::= OCTET STRING -- Constrained to <numericoid>
-- [RFC4512]
LDAPDN ::= LDAPString -- Constrained to <distinguishedName>
-- [RFC4514]
RelativeLDAPDN ::= LDAPString -- Constrained to <name-component>
-- [RFC4514]
AttributeDescription ::= LDAPString
-- Constrained to <attributedescription>
-- [RFC4512]
AttributeValue ::= OCTET STRING
AttributeValueAssertion ::= SEQUENCE {
attributeDesc AttributeDescription,
assertionValue AssertionValue }
AssertionValue ::= OCTET STRING
PartialAttribute ::= SEQUENCE {
type AttributeDescription,
vals SET OF value AttributeValue }
Attribute ::= PartialAttribute(WITH COMPONENTS {
...,
vals (SIZE(1..MAX))})
MatchingRuleId ::= LDAPString
LDAPResult ::= SEQUENCE {
resultCode ENUMERATED {
success (0),
operationsError (1),
protocolError (2),
timeLimitExceeded (3),
sizeLimitExceeded (4),
compareFalse (5),
compareTrue (6),
authMethodNotSupported (7),
strongerAuthRequired (8),
-- 9 reserved --
referral (10),
adminLimitExceeded (11),
unavailableCriticalExtension (12),
confidentialityRequired (13),
saslBindInProgress (14), noSuchAttribute (16),
undefinedAttributeType (17),
inappropriateMatching (18),
constraintViolation (19),
attributeOrValueExists (20),
invalidAttributeSyntax (21),
-- 22-31 unused --
noSuchObject (32),
aliasProblem (33),
invalidDNSyntax (34),
-- 35 reserved for undefined isLeaf --
aliasDereferencingProblem (36),
-- 37-47 unused --
inappropriateAuthentication (48),
invalidCredentials (49),
insufficientAccessRights (50),
busy (51),
unavailable (52),
unwillingToPerform (53),
loopDetect (54),
-- 55-63 unused --
namingViolation (64),
objectClassViolation (65),
notAllowedOnNonLeaf (66),
notAllowedOnRDN (67),
entryAlreadyExists (68),
objectClassModsProhibited (69),
-- 70 reserved for CLDAP --
affectsMultipleDSAs (71),
-- 72-79 unused --
other (80),
... },
matchedDN LDAPDN,
diagnosticMessage LDAPString,
referral [3] Referral OPTIONAL }
Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
URI ::= LDAPString -- limited to characters permitted in
-- URIs
Controls ::= SEQUENCE OF control Control
Control ::= SEQUENCE {
controlType LDAPOID,
criticality BOOLEAN DEFAULT FALSE,
controlValue OCTET STRING OPTIONAL }
BindRequest ::= [APPLICATION 0] SEQUENCE {
version INTEGER (1 .. 127),
name LDAPDN,
authentication AuthenticationChoice }
AuthenticationChoice ::= CHOICE {
simple [0] OCTET STRING,
-- 1 and 2 reserved
sasl [3] SaslCredentials,
... }
SaslCredentials ::= SEQUENCE {
mechanism LDAPString,
credentials OCTET STRING OPTIONAL }
BindResponse ::= [APPLICATION 1] SEQUENCE {
COMPONENTS OF LDAPResult,
serverSaslCreds [7] OCTET STRING OPTIONAL }
UnbindRequest ::= [APPLICATION 2] NULL
SearchRequest ::= [APPLICATION 3] SEQUENCE {
baseObject LDAPDN,
scope ENUMERATED {
baseObject (0),
singleLevel (1),
wholeSubtree (2),
... },
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3) },
sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt),
typesOnly BOOLEAN,
filter Filter,
attributes AttributeSelection }
AttributeSelection ::= SEQUENCE OF selector LDAPString
-- The LDAPString is constrained to
-- <attributeSelector> in Section 4.5.1.8
Filter ::= CHOICE {
and [0] SET SIZE (1..MAX) OF filter Filter,
or [1] SET SIZE (1..MAX) OF filter Filter,
not [2] Filter,
equalityMatch [3] AttributeValueAssertion, substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion,
present [7] AttributeDescription,
approxMatch [8] AttributeValueAssertion,
extensibleMatch [9] MatchingRuleAssertion,
... }
SubstringFilter ::= SEQUENCE {
type AttributeDescription,
substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
initial [0] AssertionValue, -- can occur at most once
any [1] AssertionValue,
final [2] AssertionValue } -- can occur at most once
}
MatchingRuleAssertion ::= SEQUENCE {
matchingRule [1] MatchingRuleId OPTIONAL,
type [2] AttributeDescription OPTIONAL,
matchValue [3] AssertionValue,
dnAttributes [4] BOOLEAN DEFAULT FALSE }
SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
objectName LDAPDN,
attributes PartialAttributeList }
PartialAttributeList ::= SEQUENCE OF
partialAttribute PartialAttribute
SearchResultReference ::= [APPLICATION 19] SEQUENCE
SIZE (1..MAX) OF uri URI
SearchResultDone ::= [APPLICATION 5] LDAPResult
ModifyRequest ::= [APPLICATION 6] SEQUENCE {
object LDAPDN,
changes SEQUENCE OF change SEQUENCE {
operation ENUMERATED {
add (0),
delete (1),
replace (2),
... },
modification PartialAttribute } }
ModifyResponse ::= [APPLICATION 7] LDAPResult
AddRequest ::= [APPLICATION 8] SEQUENCE {
entry LDAPDN,
attributes AttributeList }
AttributeList ::= SEQUENCE OF attribute Attribute
AddResponse ::= [APPLICATION 9] LDAPResult
DelRequest ::= [APPLICATION 10] LDAPDN
DelResponse ::= [APPLICATION 11] LDAPResult
ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
entry LDAPDN,
newrdn RelativeLDAPDN,
deleteoldrdn BOOLEAN,
newSuperior [0] LDAPDN OPTIONAL }
ModifyDNResponse ::= [APPLICATION 13] LDAPResult
CompareRequest ::= [APPLICATION 14] SEQUENCE {
entry LDAPDN,
ava AttributeValueAssertion }
CompareResponse ::= [APPLICATION 15] LDAPResult
AbandonRequest ::= [APPLICATION 16] MessageID
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING OPTIONAL }
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS OF LDAPResult,
responseName [10] LDAPOID OPTIONAL,
responseValue [11] OCTET STRING OPTIONAL }
IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
responseName [0] LDAPOID OPTIONAL,
responseValue [1] OCTET STRING OPTIONAL }
END
終わり
Appendix C. Changes
付録C.変更
This appendix is non-normative.
この付録は非規範的です。
This appendix summarizes substantive changes made to RFC 2251, RFC 2830, and RFC 3771.
この付録では、RFC 2251、RFC 2830、およびRFC 3771に作られた実質的な変更をまとめたもの。
C.1. Changes Made to
C.1。に加えられた変更
This section summarizes the substantive changes made to Sections 1, 2, 3.1, and 4, and the remainder of RFC 2251. Readers should consult [RFC4512] and [RFC4513] for summaries of changes to other sections.
このセクションでは、実質的なセクション1に加えられた変更、2、3.1、及び4を要約し、そしてRFC 2251読者の残りの部分は他の部分への変更の要約については[RFC4512]及び[RFC4513]を相談してください。
C.1.1. (Status of this Memo)
C.1.1。 （このメモの位置付け）
- Removed IESG note. Post publication of RFC 2251, mandatory LDAP authentication mechanisms have been standardized which are sufficient to remove this note. See [RFC4513] for authentication mechanisms.
- IESGノートを削除しました。 RFC 2251のポスト出版物は、必須LDAP認証メカニズムは、このノートを除去するのに十分である標準化されています。認証メカニズムのための[RFC4513]を参照してください。
C.1.2. (Protocol Model) and others
C.1.2。 （プロトコルモデル）など
- Removed notes giving history between LDAP v1, v2, and v3. Instead, added sufficient language so that this document can stand on its own.
- LDAP v1、v2、v3の間の歴史を与えて削除しましたノート。この文書は、自身の上に立つことができるようにする代わりに、十分な言語を追加しました。
C.1.3. (Elements of Protocol)
C.1.3。 （議定書の要素）
- Clarified where the extensibility features of ASN.1 apply to the protocol. This change affected various ASN.1 types by the inclusion of ellipses (...) to certain elements. - Removed the requirement that servers that implement version 3 or later MUST provide the 'supportedLDAPVersion' attribute. This statement provided no interoperability advantages.
- ASN.1の拡張機能は、プロトコルに適用される場合を明確化。この変更は、特定の要素の省略記号（...）を含めることによって、様々なASN.1タイプに影響を与えました。 - 以降のバージョン3を実装するか、サーバが「supportedLDAPVersion」属性を提供しなければならないという要件を削除しました。この文には相互運用性の利点を提供しません。
C.1.4. (Message Envelope)
C.1.4。 （メッセージエンベロープ）
- There was a mandatory requirement for the server to return a Notice of Disconnection and drop the transport connection when a PDU is malformed in a certain way. This has been updated such that the server SHOULD return the Notice of Disconnection, and it MUST terminate the LDAP Session.
- 切断の通知を返し、PDUが特定の方法で不正な形式されたときにトランスポート接続をドロップするには、サーバーの必須要件がありました。これは、サーバーが切断の通知を返すべきであるように更新されました、そしてそれは、LDAPセッションを終えなければなりません。
C.1.5. (Message ID)
C.1.5。 （メッセージID）
- Required that the messageID of requests MUST be non-zero as the zero is reserved for Notice of Disconnection.
- ゼロが断線のお知らせのために予約されているとして、要求のメッセージIDがゼロでなければならないことは必須。
- Specified when it is and isn't appropriate to return an already used messageID. RFC 2251 accidentally imposed synchronous server behavior in its wording of this.
- それは、すでに使わメッセージIDを返すことは適切ではないときに指定。 RFC 2251は、偶然この、その文言に同期サーバーの動作を課しました。
C.1.6. (String Types)
C.1.6。 （文字列タイプ）
- Stated that LDAPOID is constrained to <numericoid> from [RFC4512].
- LDAPOIDは[RFC4512]から<numericoid>に制約されると述べました。
C.1.7. (Binary Option) and others
C.1.7。 （バイナリーオプション）など
- Removed the Binary Option from the specification. There are numerous interoperability problems associated with this method of alternate attribute type encoding. Work to specify a suitable replacement is ongoing.
- 仕様からのバイナリオプションを削除しました。代替属性タイプエンコーディングのこの方法に関連した数多くの相互運用性の問題があります。適切な代替を指定するための作業が進行中です。
C.1.8. (Attribute)
C.1.8。 （属性）
- Combined the definitions of PartialAttribute and Attribute here, and defined Attribute in terms of PartialAttribute.
- PartialAttributeの定義を組み合わせて、ここでは属性、およびPartialAttributeの面で属性を定義しました。
C.1.9. (Result Message)
C.1.9。 （結果メッセージ）
- Renamed "errorMessage" to "diagnosticMessage" as it is allowed to be sent for non-error results. - Moved some language into Appendix A, and referred the reader there. - Allowed matchedDN to be present for other result codes than those listed in RFC 2251. - Renamed the code "strongAuthRequired" to "strongerAuthRequired" to clarify that this code may often be returned to indicate that a stronger authentication is needed to perform a given operation.
- 非エラー結果を送信することが許可されているように、「diagnosticMessage」「にErrorMessage」に改名。 - 付録Aに、いくつかの言語を移動し、そこに読者を言及しました。 - matchedDNはRFC 2251に記載されたもの以外の結果コードについて存在させる - コード「strongAuthRequired」が「strongerAuthRequired」このコードは、多くの場合、より強力な認証を与えられた操作を実行するために必要であることを示すために戻されてもよいことを明確にするために改名。
C.1.10. (Referral)
C.1.10。 （紹介）
- Defined referrals in terms of URIs rather than URLs. - Removed the requirement that all referral URIs MUST be equally capable of progressing the operation. The statement was ambiguous and provided no instructions on how to carry it out. - Added the requirement that clients MUST NOT loop between servers. - Clarified the instructions for using LDAPURLs in referrals, and in doing so added a recommendation that the scope part be present. - Removed imperatives which required clients to use URLs in specific ways to progress an operation. These did nothing for interoperability.
- URIのではなく、URLの観点から定義紹介。 - すべての紹介URIが操作を進行する等しく可能でなければならないという要件を削除しました。文は曖昧だったし、それを実行する方法について何の指示に設けられていません。 - 要求事項を追加したクライアントは、サーバー間でループしてはなりません。 - 紹介でLDAPURLsを使用するための指示を明らかにし、そうすることで、スコープ部が存在することが推奨を追加しました。 - 操作を進めるために、特定の方法でURLを使用するようにクライアントを必要な要請を削除しました。これらは、相互運用性のために何もしませんでした。
C.1.11. (Controls)
C.1.11。 （コントロール）
- Specified how control values defined in terms of ASN.1 are to be encoded. - Noted that the criticality field is only applied to request messages (except UnbindRequest), and must be ignored when present on response messages and UnbindRequest. - Specified that non-critical controls may be ignored at the server's discretion. There was confusion in the original wording which led some to believe that recognized controls may not be ignored as long as they were associated with a proper request. - Added language regarding combinations of controls and the ordering of controls on a message. - Specified that when the semantics of the combination of controls is undefined or unknown, it results in a protocolError. - Changed "The server MUST be prepared" to "Implementations MUST be prepared" in paragraph 8 to reflect that both client and server implementations must be able to handle this (as both parse controls).
- ASN.1の観点で定義された制御値がエンコードされる方法を指定。 - 臨界フィールドのみ（UnbindRequestを除く）のメッセージを要求するために適用され、応答メッセージとUnbindRequestを上に存在する場合は無視されなければならないと指摘しました。 - 非クリティカルコントロールは、サーバーの裁量で、無視することができることを指定。認識されたコントロールがいる限り、彼らが適切な要求と関連していたとして無視できないことを信じるようにいくつかを導いた、元の言葉遣いでの混乱がありました。 - 追加したコントロールの組み合わせに関する言語およびメッセージのコントロールの順序。 - コントロールの組み合わせのセマンティクスは未定義または未知であるとき、それははProtocolErrorにつながることを指定。 - 変更（両方ともコントロールを解析して）クライアントとサーバーの両方の実装がこれを処理できなければならないことを反映するために、第8項に「実装を準備しなければなりません」に「サーバーを準備しなければなりません」。
C.1.12. (Bind Operation)
C.1.12。 （バインド操作）
- Mandated that servers return protocolError when the version is not supported. - Disambiguated behavior when the simple authentication is used, the name is empty, and the password is non-empty. - Required servers to not dereference aliases for Bind. This was added for consistency with other operations and to help ensure data consistency. - Required that textual passwords be transferred as UTF-8 encoded Unicode, and added recommendations on string preparation. This was to help ensure interoperability of passwords being sent from different clients.
- バージョンがサポートされていない場合、サーバはProtocolErrorのを返すことを義務化。 - シンプルな認証が使用されている明確な同形挙動は、名前が空で、パスワードが非空です。 - バインドの別名を間接参照しないようにサーバーを必要です。これは他の操作との一貫性のために添加し、データの一貫性を確保するために。 - テキストのパスワードはUTF-8エンコードされたUnicodeとして転送する必要があり、文字列の準備に関する推奨事項を追加しました。これは、別のクライアントから送信されているパスワードの相互運用性を確保することでした。
C.1.13. (Sequencing of the Bind Request)
C.1.13。 （バインド要求の配列決定）
- This section was largely reorganized for readability, and language was added to clarify the authentication state of failed and abandoned Bind operations. - Removed: "If a SASL transfer encryption or integrity mechanism has been negotiated, that mechanism does not support the changing of credentials from one identity to another, then the client MUST instead establish a new connection." If there are dependencies between multiple negotiations of a particular SASL mechanism, the technical specification for that SASL mechanism details how applications are to deal with them. LDAP should not require any special handling. - Dropped MUST imperative in paragraph 3 to align with [RFC2119].
- このセクションは、主に、読みやすさのために再編成し、言語が失敗して捨てられたバインド操作の認証状態を明確にするために追加されました。 - 削除：「そのメカニズムは別のアイデンティティからの資格情報の変更をサポートしていないSASL転送暗号化または整合性のメカニズムが交渉されている場合、クライアントは代わりに新しい接続を確立する必要があります。」特定のSASL機構の複数の交渉の間の依存性がある場合は、そのSASLメカニズムのための技術仕様は、アプリケーションがそれらに対処するためにある方法について説明します。 LDAPは、特別な処理を必要とすべきではありません。 - [RFC2119]と整列する第3項に不可欠MUSTを落としました。
- Mandated that clients not send non-Bind operations while a Bind is in progress, and suggested that servers not process them if they are received. This is needed to ensure proper sequencing of the Bind in relationship to other operations.
- バインドが進行している間、クライアントが非バインド操作を送信しないことを義務化し、それらが受信されている場合のサーバーがそれらを処理できないことが示唆されました。これは、他の操作との関係でのバインドの適切な順序付けを確保するために必要とされます。
C.1.14. (Bind Response)
C.1.14。 （バインドレスポンス）
- Moved most error-related text to Appendix A, and added text regarding certain errors used in conjunction with the Bind operation. - Prohibited the server from specifying serverSaslCreds when not appropriate.
- 付録Aに最もエラー関連のテキストを移動し、バインド操作と連動して使用される特定のエラーに関するテキストを追加しました。 - 適切な場合ではないserverSaslCredsを指定してからサーバーを禁止。
C.1.15. (Unbind Operation)
C.1.15。 （バインド解除操作）
- Specified that both peers are to cease transmission and terminate the LDAP session for the Unbind operation.
- 両方のピアが送信を停止し、アンバインド操作のためのLDAPセッションを終了していることを指定。
C.1.16. (Unsolicited Notification)
C.1.16。 （未承諾の通知）
- Added instructions for future specifications of Unsolicited Notifications.
- 任意通知の将来の仕様のための命令を追加しました。
C.1.17. (Search Request)
C.1.17。 （検索要求）
- SearchRequest attributes is now defined as an AttributeSelection type rather than AttributeDescriptionList, and an ABNF is provided. - SearchRequest attributes may contain duplicate attribute descriptions. This was previously prohibited. Now servers are instructed to ignore subsequent names when they are duplicated. This was relaxed in order to allow different short names and also OIDs to be requested for an attribute. - The present search filter now evaluates to Undefined when the specified attribute is not known to the server. It used to evaluate to FALSE, which caused behavior inconsistent with what most would expect, especially when the 'not' operator was used. - The Filter choice SubstringFilter substrings type is now defined with a lower bound of 1. - The SubstringFilter substrings 'initial, 'any', and 'final' types are now AssertionValue rather than LDAPString. Also, added imperatives stating that 'initial' (if present) must be listed first, and 'final' (if present) must be listed last. - Disambiguated the semantics of the derefAliases choices. There was question as to whether derefInSearching applied to the base object in a wholeSubtree Search. - Added instructions for equalityMatch, substrings, greaterOrEqual, lessOrEqual, and approxMatch.
- SearchRequestは現在AttributeSelection型ではなくAttributeDescriptionListとして定義される属性、及びABNFが提供されます。 - SearchRequest属性が重複した属性の記述が含まれていてもよいです。これは、以前に禁止されました。今、サーバはそれらが重複している時に、後続の名前を無視するように指示されています。これは、異なる短い名前と、属性のために要求されるOIDを可能にするためにリラックスしました。 - 指定された属性がサーバーに知られていない存在する場合、検索フィルタは現在未定義と評価されます。それはない '演算子を使用した場合は特に、ほとんどが期待するものと矛盾する行動を起こしている、FALSEに評価するために使用しました。 - フィルタの選択SubstringFilterサブストリングタイプは今低い1の下限で定義されている - SubstringFilterサブストリング「初期、 『任意の』、および 『final』は型が今AssertionValueのではなく、LDAPStringです。また、（存在する場合）（存在する場合）「初期」最初にリストされなければならない、と「最終」が最後にリストされなければならない旨の要請を追加しました。 - derefAliasesの選択肢の意味を張り替え。 derefInSearchingがwholeSubtree検索でベースオブジェクトに適用されるかどうかについての質問がありました。 - equalityMatch、ストリング、greaterOrEqual、lessOrEqual、およびapproxMatchのための命令を追加しました。
C.1.18. (Search Result)
C.1.18。 （検索結果）
- Recommended that servers not use attribute short names when it knows they are ambiguous or may cause interoperability problems. - Removed all mention of ExtendedResponse due to lack of implementation.
- サーバは、それは彼らが曖昧であるか、相互運用性の問題を引き起こす可能性が知っているときに短い属性名を使用しないことを推奨。 - による実装の欠如にExtendedResponseのすべての言及を削除しました。
C.1.19. (Continuation References in the Search Result)
C.1.19。 （検索結果での継続参照）
- Made changes similar to those made to Section 4.1.11.
- セクション4.1.11に行われたものと同様の変更を行いました。
C.1.20. (Example)
C.1.20。 （実施例）
- Fixed examples to adhere to changes made to Section 4.5.3.
- 固定の例は、第4.5.3項に加えられた変更を遵守します。
C.1.21. (Modify Operation)
C.1.21。 （変更操作）
- Replaced AttributeTypeAndValues with Attribute as they are equivalent. - Specified the types of modification changes that might temporarily violate schema. Some readers were under the impression that any temporary schema violation was allowed.
- 彼らは同等であるとして属性を持つているAttributeTypeAndValuesを置き換え。 - 一時的にスキーマに違反する可能性がある変更変更の種類を指定しました。一部の読者には、任意の一時スキーマ違反が許可された印象の下にありました。
C.1.22. (Add Operation)
C.1.22。 （オペレーションを追加）
- Aligned Add operation with X.511 in that the attributes of the RDN are used in conjunction with the listed attributes to create the entry. Previously, Add required that the distinguished values be present in the listed attributes. - Removed requirement that the objectClass attribute MUST be specified as some DSE types do not require this attribute. Instead, generic wording was added, requiring the added entry to adhere to the data model. - Removed recommendation regarding placement of objects. This is covered in the data model document.
- RDNの属性は、エントリを作成するためにリストされている属性と組み合わせて使用されているという点で、同盟はX.511での動作を追加します。以前は、著名な値がリストされている属性で存在することが必要に追加します。 - objectClass属性は、いくつかのDSEタイプとして指定しなければならない削除。要件は、この属性を必要としません。代わりに、一般的な文言は、データモデルに準拠するために追加のエントリを必要とする、追加されました。 - オブジェクトの配置については削除しました勧告。これは、データモデル文書で覆われています。
C.1.23. (Modify DN Operation)
C.1.23。 （DN変更操作）
- Required servers to not dereference aliases for Modify DN. This was added for consistency with other operations and to help ensure data consistency. - Allow Modify DN to fail when moving between naming contexts. - Specified what happens when the attributes of the newrdn are not present on the entry.
- DNの変更のための別名を間接参照しないようにサーバーを必要です。これは他の操作との一貫性のために添加し、データの一貫性を確保するために。 - 名前付けコンテキスト間を移動するときにDNの変更が失敗することを許可します。 - newrdnの属性がエントリに存在しないときに何が起こるかを指定。
C.1.24. (Compare Operation)
C.1.24。 （操作の比較）
- Specified that compareFalse means that the Compare took place and the result is false. There was confusion that led people to believe that an Undefined match resulted in compareFalse. - Required servers to not dereference aliases for Compare. This was added for consistency with other operations and to help ensure data consistency.
- compareFalseは、比較が行われ、結果が偽であることを意味することを指定。未定義マッチがcompareFalseをもたらしたことを信じるように人々を導いた混乱がありました。 - 比較のための別名を参照解除しないようにサーバを必要としていました。これは他の操作との一貫性のために添加し、データの一貫性を確保するために。
C.1.25. (Abandon Operation)
C.1.25。 （操作を放棄）
- Explained that since Abandon returns no response, clients should not use it if they need to know the outcome. - Specified that Abandon and Unbind cannot be abandoned.
- 返します応答を放棄しないため、彼らは結果を知る必要がある場合、クライアントはそれを使用するべきではないと説明しました。 - 放棄とバインド解除が放棄することはできないように指定。
C.1.26. (Extended Operation)
C.1.26。 （拡張オペレーション）
- Specified how values of Extended operations defined in terms of ASN.1 are to be encoded. - Added instructions on what Extended operation specifications consist of. - Added a recommendation that servers advertise supported Extended operations.
- ASN.1に関して定義拡張操作の指定方法値が符号化されるべきです。 - 拡張動作仕様は、で構成されて何の指示を追加しました。 - サーバが拡張操作をサポートアドバタイズ勧告を追加しました。
C.1.27. (Transfer Protocols)
C.1.27。 （転送プロトコル）
- Moved referral-specific instructions into referral-related sections.
- 紹介関連のセクションに紹介固有の命令を移動しました。
C.1.28. (Security Considerations)
C.1.28。 （セキュリティ上の考慮事項）
- Reworded notes regarding SASL not protecting certain aspects of the LDAP Bind messages. - Noted that Servers are encouraged to prevent directory modifications by clients that have authenticated anonymously [RFC4513]. - Added a note regarding the possibility of changes to security factors (authentication, authorization, and data confidentiality). - Warned against following referrals that may have been injected in the data stream. - Noted that servers should protect information equally, whether in an error condition or not, and mentioned matchedDN, diagnosticMessage, and resultCodes specifically. - Added a note regarding malformed and long encodings.
- LDAPバインドメッセージの特定の側面を保護していないSASLに関する注意事項を言い換えました。 - サーバーが匿名で[RFC4513]認証されたクライアントによるディレクトリの変更を防ぐために奨励されていることを指摘しました。 - セキュリティ要素（認証、許可、およびデータの機密性）への変更の可能性についての注記を追加しました。 - データストリームに注入されている可能性があり、次の照会に対して警告しました。 - サーバが均等かどうか、エラー状態かどうかの情報を保護しなければならないことを記述し、具体的matchedDN、diagnosticMessage、およびresultCodesを述べました。 - 不正な形式と長いエンコーディングに関する注記を追加しました。
C.1.29. (Complete ASN.1 Definition)
C.1.29。 （完全なASN.1定義）
- Added "EXTENSIBILITY IMPLIED" to ASN.1 definition. - Removed AttributeType. It is not used.
- 追加されたASN.1定義に「拡張性は黙示」。 - 削除AttributeTypeで。それは使用されません。
C.2. Changes Made to
C.2。に加えられた変更
This section summarizes the substantive changes made to Sections of RFC 2830. Readers should consult [RFC4513] for summaries of changes to other sections.
このセクションでは、RFC 2830読者のセクションに作られた実質的な変更は他のセクションへの変更の概要については[RFC4513]を相談するべきまとめたもの。
C.2.1. (Response other than "success")
C.2.1。 （「成功」以外の応答）
- Removed wording indicating that referrals can be returned from StartTLS. - Removed requirement that only a narrow set of result codes can be returned. Some result codes are required in certain scenarios, but any other may be returned if appropriate. - Removed requirement that the ExtendedResponse.responseName MUST be present. There are circumstances where this is impossible, and requiring this is at odds with language in Section 4.12.
- 紹介はStartTLSをから返される可能性があることを示す削除文言。 - 結果コードの唯一の狭いセットを返すことができ取り除きまし要件。いくつかの結果コードは、特定のシナリオで必要とされるが、適切な場合、他に返されてもよいです。 - ExtendedResponse.responseNameが存在していなければならない削除しまし要件。これは不可能であり、これを必要とすると4.12での言語と対立している状況があります。
C.2.1. (Closing a TLS Connection)
C.2.1。 （TLS接続を閉じます）
- Reworded most of this section to align with definitions of the LDAP protocol layers. - Removed instructions on abrupt closure as this is covered in other areas of the document (specifically, Section 5.3)
- LDAPプロトコル層の定義と整合するように、このセクションの大部分を言い換え。 - このような突然の閉鎖に削除命令が文書の他の領域に覆われている（具体的には、第5.3節）
C.3. Changes Made to
C.3。に加えられた変更
- Rewrote to fit into this document. In general, semantics were preserved. Supporting and background language seen as redundant due to its presence in this document was omitted.
- 本書に収まるように書き直しました。一般的には、意味が保存されていました。サポートとこのドキュメントではその存在のために冗長として見背景言語が省略されました。
- Specified that Intermediate responses to a request may be of different types, and one of the response types may be specified to have no response value.
- 要求に中間応答が異なるタイプのものであってもよいことが指定され、応答タイプの一つは、応答値を持たないように指定してもよいです。
Editor's Address
編集者の住所
Jim Sermersheim Novell, Inc. 1800 South Novell Place Provo, Utah 84606, USA
ジム・Sermersheimノベル株式会社1800南ノベル場所プロボ、ユタ州84606、USA
Phone: +1 801 861-3088 EMail: jimse@novell.com
電話：+1 801 861-3088 Eメール：jimse@novell.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）によって提供されます。