RFC4511 日本語訳
4511 Lightweight Directory Access Protocol (LDAP): The Protocol. J.Sermersheim, Ed.. June 2006. (Format: TXT=150116 bytes) (Obsoletes RFC2251, RFC2830, RFC3771) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Sermersheim, Ed. Request for Comments: 4511 Novell, Inc. Obsoletes: 2251, 2830, 3771 June 2006 Category: Standards Track
ワーキンググループJ.Sermersheim、エドをネットワークでつないでください。コメントのために以下を要求してください。 4511 ノベルInc.は以下を時代遅れにします。 2830、3771 2251、年2006年6月のカテゴリ: 標準化過程
Lightweight Directory Access Protocol (LDAP): The Protocol
ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP): プロトコル
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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).
このドキュメントはそれらの意味論に伴うプロトコル要素とライトウェイト・ディレクトリ・アクセス・プロトコルのencodings(LDAP)について説明します。 X.500データとサービスモデルに応じて、LDAPは分配されたディレクトリサービスへのアクセスにその行為を提供します。 これらのプロトコル要素はX.500ディレクトリAccessプロトコル(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
1. 序論…3 1.1. 他のLDAP仕様との関係…3 2. コンベンション…3 3. モデルについて議定書の中で述べてください…4 3.1. 操作とLDAPメッセージは関係を層にします…5 4. プロトコルのElements…5 4.1. 一般的なElements…5 4.1.1. メッセージ封筒…6 4.1.2. タイプを結んでください…7 4.1.3. 分類名と相対的な分類名。8 4.1.4. 記述を結果と考えてください…8 4.1.5. 値を結果と考えてください…8 4.1.6. 値の主張を結果と考えてください…9 4.1.7. 属性とPartialAttribute…9 4.1.8. マッチングは識別子を統治します…10 4.1.9. 結果メッセージ…10 4.1.10. 紹介…12
Sermersheim Standards Track [Page 1] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[1ページ]RFC4511LDAPv3 June 2006
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
4.1.11. コントロール…14 4.2. 操作を縛ってください…16 4.2.1. ひもの要求の処理…17 4.2.2. 応答を縛ってください…18 4.3. 操作を解いてください…18 4.4. 求められていない通知…19 4.4.1. 断線の通知…19 4.5. 操作を捜してください…20 4.5.1. 要求を捜してください…20 4.5.2. 結果を捜してください…27 4.5.3. 検索における継続参照は結果として生じます…28 4.6. 操作を変更してください…31 4.7. 操作を加えてください…33 4.8. 操作を削除してください…34 4.9. DN操作を変更してください…34 4.10. 操作を比較してください…36 4.11. 操作を捨ててください…36 4.12. 操作を広げています…37 4.13. IntermediateResponseメッセージ…39 4.13.1. LDAP ExtendedRequestとExtendedResponseがある用法…40 4.13.2. LDAP要求がある用法は制御されます…40 4.14. StartTLS操作…40 4.14.1. StartTLS要求…40 4.14.2. StartTLS応答…41 4.14.3. TLS層の取り外し…41 5. コード化、接続、および転送について議定書の中で述べてください…42 5.1. コード化について議定書の中で述べてください…42 5.2. 通信制御プロトコル(TCP)…43 5.3. LDAPセッションの終了…43 6. セキュリティ問題…43 7. 承認…45 8. 標準の参照…46 9. 有益な参照…48 10. IANA問題…48 付録A.LDAP結果コード…49 A.1。 非誤り結果コード…49 A.2。 結果コード…49付録B.はASN.1定義を終了します…54 付録C.は変化します…60 C.1。 RFC2251にされた変更…60 C.2。 RFC2830にされた変更…66 C.3。 RFC3771にされた変更…66
Sermersheim Standards Track [Page 2] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[2ページ]RFC4511LDAPv3 June 2006
1. Introduction
1. 序論
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]です。 ディレクトリユーザ(人間か他の実体であるかもしれない)はクライアント(または、ディレクトリUserエージェント(DUA))を通してディレクトリにアクセスします。 ディレクトリユーザを代表して、クライアントは1つ以上のサーバ(または、ディレクトリSystemエージェント(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)のプロトコル要素について詳述します。 プロトコル要素の記述に続いて、それはプロトコル要素がコード化されて、移される方法を述べます。
1.1. Relationship to Other LDAP Specifications
1.1. 他の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仕様書[RFC4510]の不可欠の部分です。(それは、以前に定義されたLDAP技術仕様書、RFC3377を全体として時代遅れにします)。
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.
[RFC4510]に伴うこのドキュメント[RFC4513]、および[RFC4512]は、RFC2251を全体として時代遅れにします。 セクション3.3は[RFC4510]によって時代遅れにされます。 セクション4.2 .1 (部分)と.2が時代遅れにされる4.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]によって時代遅れにされます。 RFC2251の残りはこのドキュメントによって時代遅れにされます。 付録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.
このドキュメントはRFC2830、セクション2と4を時代遅れにします。 RFC2830の残りは[RFC4513]によって時代遅れにされます。 付録C.2は残っているセクションへの実質的な変化をまとめます。
This document also obsoletes RFC 3771 in entirety.
また、このドキュメントは全体でRFC3771を時代遅れにします。
2. Conventions
2. コンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「」、「推薦された」、およびこのドキュメントの「5月」は[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>.
キャラクター名はコード・ポイントと名前にユニコードStandard[ユニコード]から記法を本書では使用します。 例えば、手紙“a"は<U+0061>か<LATIN SMALL LETTER A>のどちらかとして表されるかもしれません。
Sermersheim Standards Track [Page 3] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[3ページ]RFC4511LDAPv3 June 2006
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].
以下に注意してください。 [用語集]でユニコードで使用される用語の用語集を見つけることができます。 [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層」という用語はセキュリティー・サービスを提供する際に利用されたTransport Layer Security(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層」という用語はセキュリティー・サービスを提供する際に利用されたSimply AuthenticationとSecurity Layer(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 MessageプロトコルData Unit(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でこれらの4つの用語のイラストに関してテーブルを見てください。
3. Protocol Model
3. プロトコルモデル
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.
サーバがそのような応答がプロトコルで定義されるときはいつも、応答を返すのに必要ですが、同期振舞いのための要件が全くクライアントかサーバのどちらか側のありません。 一般に、順不同なクライアントとサーバの間で同時併行処理のための要求と応答を交換するかもしれません。 必要なら、同期振舞いはクライアントアプリケーションで制御されるかもしれません。
Sermersheim Standards Track [Page 4] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[4ページ]RFC4511LDAPv3 June 2006
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)のディレクトリの抽象的なService[X.511]の部分集合に本書では定義されたコアプロトコル操作は写像できます。 しかしながら、LDAP操作とX.500ディレクトリAccessプロトコル(DAP)操作の間には、1〜1つのマッピングがありません。 X.500ディレクトリへのゲートウェイとして機能するサーバ実装は、ただ一つのLDAP要求を修理するという複数のDAP要求をする必要があるかもしれません。
3.1. Operation and LDAP Message Layer Relationship
3.1. 操作とLDAPメッセージ層の関係
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メッセージ層でのどんな未完成の操作も、捨てられるか(可能であるときに)、または応答の送信なしで完了しています(それらを捨てるのが可能でないときに)。 また、輸送接続が閉じられるとき、クライアントは、どんな未完成のアップデート操作も成功するか、または失敗したと仮定してはいけません。
4. Elements of Protocol
4. プロトコルのElements
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.
プロトコルは、抽象的なSyntax Notation One([ASN.1])を使用することで説明されて、ASN.1Basic Encoding Rules([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の一部として使用しているバージョンを示します。 クライアントがBindを送らないなら、サーバは、クライアントがバージョン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特有のEntry)[RFC4512]から'supportedLDAPVersion'属性を読むことによってサポートするプロトコルバージョンを決定するのを試みるかもしれません。
4.1. Common Elements
4.1. 一般的なElements
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封筒プロトコルData Unit(PDU)形式について説明します、データ型定義と同様に。定義はプロトコル操作に使用されます。
Sermersheim Standards Track [Page 5] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[5ページ]RFC4511LDAPv3 June 2006
4.1.1. Message Envelope
4.1.1. メッセージ封筒
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 }
LDAPMessage:、:= 系列{ messageID MessageID; protocolOp選択; { 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; } , コントロール0Controls OPTIONAL; }
MessageID ::= INTEGER (0 .. maxInt)
MessageID:、:= 整数(0maxInt)
maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
maxInt整数:、:= 2147483647 -- (2^^31 - 1) --
The ASN.1 type Controls is defined in Section 4.1.11.
ASN.1タイプControlsはセクション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の機能はすべてのプロトコル交換で必要である共同耕地を含む封筒を提供することです。 このとき、唯一の共同耕地は、messageIDとコントロールです。
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
サーバがLDAPMessage SEQUENCEタグを認識できないクライアントからLDAPMessageを受けるか、messageIDを分析できないか、protocolOpのタグが要求として認められないか、またはデータ・フィールドのコード化構造か長さが不正確であることがわかっているなら、サーバSHOULDはDisconnectionのNoticeを返します。
Sermersheim Standards Track [Page 6] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[6ページ]RFC4511LDAPv3 June 2006
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.
セクション4.4.1で説明されていて、セクション5.3で説明されるLDAPセッションは、resultCodeと共に、protocolErrorにセットして、すぐに、終わっていなければなりません。
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を分析できないで、それがSHOULDである他の場合では、突然に、さらなるコミュニケーション(通知を提供するのを含んでいる)が有害であるLDAPセッション(セクション5.3)を終えてください。 さもなければ、サーバ実装はresultCodeセットによる要求への適切な応答をprotocolErrorに返さなければなりません。
4.1.1.1. MessageID
4.1.1.1. MessageID
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.
要求のmessageIDには、進行中のいかなる他の要求のmessageIDとも同じLDAPセッションにおいて異なった非ゼロ値がなければなりません。 求められていない通知メッセージのために、予約されますゼロが、評価する。
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セッションにおける以前の要求として同じmessageIDとの要求を送ってはいけません。または、(例えば、後に、最終的な応答が受け取られている、その後のBindが完成する、) さもなければ、振舞いは未定義です。 このために、Abandonと首尾よく捨てられた操作が応答を送らないことに注意してください。
4.1.2. String Types
4.1.2. ストリングタイプ
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.
LDAPStringはUTF-8[RFC3629]アルゴリズムに従って、[ISO10646]文字集合([ユニコード]のスーパーセット)がASN.1OCTET STRINGがタイプするようにLDAPStringのストリングがエンコードをタイプしますが、中古で、コード化されているのを示す記号法の便利です。 U+007Fを通したユニコード文字U+0000でASCII0〜127とそれぞれ同じであり、同じただ一つの八重奏UTF-8がコード化することに注意してください。 他のユニコード文字は複数の八重奏UTF-8にコード化させます。
LDAPString ::= OCTET STRING -- UTF-8 encoded,
-- [ISO10646] characters
LDAPString:、:= OCTET STRING--コード化されたUTF-8--[ISO10646]キャラクタ
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
LDAPOIDはこのストリングの受入れられた値がOBJECT IDENTIFIERの(コード化されたUTF-8)ドット付き10進法表現であることを示す記号法の便利です。 LDAPOIDはそうですが
Sermersheim Standards Track [Page 7] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[7ページ]RFC4511LDAPv3 June 2006
encoded as an OCTET STRING, values are limited to the definition of <numericoid> given in Section 1.4 of [RFC4512].
OCTET STRINGとしてコード化されていて、値は[RFC4512]のセクション1.4で与えられている<numericoid>の定義に制限されます。
LDAPOID ::= OCTET STRING -- Constrained to <numericoid>
-- [RFC4512]
LDAPOID:、:= 八重奏ストリング--<numericoid>に抑制されます--[RFC4512]
For example,
例えば
1.3.6.1.4.1.1466.1.2.3
1.3.6.1.4.1.1466.1.2.3
4.1.3. Distinguished Name and Relative Distinguished Name
4.1.3. 分類名と相対的な分類名
An LDAPDN is defined to be the representation of a Distinguished Name (DN) after encoding according to the specification in [RFC4514].
LDAPDNは、[RFC4514]の仕様に従ったコード化の後のDistinguished Name(DN)の表現になるように定義されます。
LDAPDN ::= LDAPString
-- Constrained to <distinguishedName> [RFC4514]
LDAPDN:、:= LDAPString--<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]の仕様に従ったコード化の後のRelative Distinguished Name(RDN)の表現になるように定義されます。
RelativeLDAPDN ::= LDAPString
-- Constrained to <name-component> [RFC4514]
RelativeLDAPDN:、:= LDAPString--<名コンポーネントに>を抑制します。[RFC4514]
4.1.4. Attribute Descriptions
4.1.4. 属性記述
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]
AttributeDescription:、:= LDAPString--<attributedescription>に抑制されます--[RFC4512]
4.1.5. Attribute Value
4.1.5. 属性値
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の分野はコード化された属性値を含むOCTET STRINGです。 対応する構文のLDAP特有のコード化定義に従って、属性値はコード化されます。 異なった構文と属性タイプのためのLDAP特有のコード化定義は他のドキュメントと特に[RFC4517]見つけられるかもしれません。
AttributeValue ::= OCTET STRING
AttributeValue:、:= 八重奏ストリング
Sermersheim Standards Track [Page 8] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[8ページ]RFC4511LDAPv3 June 2006
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.
クライアントは要求における属性のために定義された構文によると、有効な属性値を送るだけでよいです。
4.1.6. Attribute Value Assertion
4.1.6. 属性値主張
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 }
AttributeValueAssertion:、:= 系列attributeDesc AttributeDescription、assertionValue AssertionValue
AssertionValue ::= OCTET STRING
AssertionValue:、:= 八重奏ストリング
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操作の文脈によります。 Compare操作を実行するとき、例えば、属性のためのEQUALITYの合っている規則の構文は使用されています。 しばしば、これは属性タイプの値に使用される同じ構文ですが、いくつかの場合、主張構文は値の構文と異なっています。 [RFC4517]で例に関してobjectIdentiferFirstComponentMatchを見てください。
4.1.7. Attribute and PartialAttribute
4.1.7. 属性とPartialAttribute
Attributes and partial attributes consist of an attribute description and attribute values. A PartialAttribute allows zero values, while Attribute requires at least one value.
属性と部分的な属性は属性記述と属性値から成ります。 PartialAttributeは値を全く許容しませんが、Attributeは少なくとも1つの値を必要とします。
PartialAttribute ::= SEQUENCE {
type AttributeDescription,
vals SET OF value AttributeValue }
PartialAttribute:、:= 系列AttributeDescription、vals SET OF値のAttributeValueをタイプしてください。
Sermersheim Standards Track [Page 9] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[9ページ]RFC4511LDAPv3 June 2006
Attribute ::= PartialAttribute(WITH COMPONENTS {
...,
vals (SIZE(1..MAX))})
以下を結果と考えてください:= 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つの属性値も同等でないかもしれません。 属性値のセットは順不同のです。 実装は、反復可能であるので、注文であることを当てにされてはいけません。
4.1.8. Matching Rule Identifier
4.1.8. 合っている規則識別子
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'.
合っている規則は.3セクション4.1[RFC4512]で定義されます。 合っている規則は<numericoid>か省略名記述子の1つ[RFC4512]のどちらかの印刷可能な表現によってプロトコルで特定されます、例えば、'caseIgnoreMatch。''2.5 .13 .2'。
MatchingRuleId ::= LDAPString
MatchingRuleId:、:= LDAPString
4.1.9. Result Message
4.1.9. 結果メッセージ
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),
LDAPResult:、:= SEQUENCE、resultCode ENUMERATED、成功(0)、operationsError(1)、protocolError(2)、timeLimitExceeded(3)、sizeLimitExceeded(4)、compareFalse(5)、compareTrue(6)、authMethodNotSupported(7)、strongerAuthRequired(8)--9 予約されています; 紹介(10)、adminLimitExceeded(11)、unavailableCriticalExtension(12)、confidentialityRequired(13)、saslBindInProgress(14)、noSuchAttribute(16)、undefinedAttributeType(17)、inappropriateMatching(18)constraintViolation(19)、attributeOrValueExists(20)、invalidAttributeSyntax(21)
Sermersheim Standards Track [Page 10] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[10ページ]RFC4511LDAPv3 June 2006
-- 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 }
-- 22-31 未使用(noSuchObject(32)、aliasProblem(33)、invalidDNSyntax(34))の35は未定義のisLeaf(aliasDereferencingProblem(36))のために未使用で37-47を予約しました--inappropriateAuthentication(48)、invalidCredentials(49)(insufficientAccessRights(50))は(51)、入手できない(52)、unwillingToPerform(53)、loopDetect(54)と忙しくします; 55-63 未使用(namingViolation(64)、objectClassViolation(65)、notAllowedOnNonLeaf(66)、notAllowedOnRDN(67)、entryAlreadyExists(68)、objectClassModsProhibited(69))の70はCLDAP(affectsMultipleDSAs(71))のために未使用で72-79を予約しました--他の(80) matchedDN LDAPDN、diagnosticMessage LDAPString、紹介[3]紹介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.
resultCode列挙は[RFC4520]のセクション3.8で定義されるように広げることができます。 記載された結果コードの意味はAppendix A.Ifで考えて、サーバが操作のための複数の誤りを検出します、コードが返される1つの結果だけということです。 サーバは誤りの本質が遭遇したのを最もよく示す結果コードを返すべきです。 サーバは、不当開示を防ぐために代入された結果コードを返すかもしれません。
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分野は人影がないに違いありません。
Sermersheim Standards Track [Page 11] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[11ページ]RFC4511LDAPv3 June 2006
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分野は人影がありません。
4.1.10. Referral
4.1.10. 紹介
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に存在しています、そして、それは他のすべての結果コードで欠けています。 それは1つ以上のサーバの1つ以上の参照箇所、LDAPを通してアクセスされるかもしれないサービスまたは他のプロトコルを含んでいます。 どんな操作要求(応答を持っていないUnbindとAbandonを除いた)に対応して紹介を返すことができます。 少なくとも1つのURIがReferralに存在していなければなりません。
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
紹介:、:= SEQUENCE SIZE(1..MAX)OF uri URI
URI ::= LDAPString -- limited to characters permitted in
-- URIs
URI:、:= LDAPString(受入れられたキャラクタに制限される)、URI
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.
クライアントが操作を進行したいなら、それは紹介で見つけられたサポートしているサービスの1つに連絡します。 複数の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
紹介の後をつけるクライアントは、サーバの間で輪にしないのを保証しなければなりません。 彼らは同じ要求のために繰り返して同じパラメタで同じサーバに連絡してはいけません。 aを使用するクライアントもいます。
Sermersheim Standards Track [Page 12] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[12ページ]RFC4511LDAPv3 June 2006
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].
[RFC4516]に従って、LDAPとTCP/IPを通してアクセスしやすい(v4かv6)[RFC793][RFC791]を実装するサーバのためのURIは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 MUSTの>部分をdnします。
- It is RECOMMENDED that the <dn> part be present to avoid ambiguity.
- <dn>部分があいまいさを避けるために存在しているのは、RECOMMENDEDです。
- 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.
- いくつかのサーバ(例えば、分配されたインデックスに参加する)が検索操作のための紹介の1つの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.
- 検索のために、<範囲の>一部があいまいさを避けるために存在しているのは、RECOMMENDEDです。
- 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].
UTF-8はDNのストリング表現に現れるキャラクタをコード化しました、検索フィルタ、または、紹介価値の他の野原をURI(例えば、空間)には法的でないかもしれなく、[RFC3986]の%メソッドを使用して、逃げなければなりません。
Sermersheim Standards Track [Page 13] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[13ページ]RFC4511LDAPv3 June 2006
4.1.11. Controls
4.1.11. コントロール
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操作の意味論と議論が敷衍されるかもしれないメカニズムを提供します。 1つ以上のコントロールがただ一つのLDAPメッセージに取り付けられるかもしれません。 コントロールはそれが付けられているメッセージの意味論に影響するだけです。
Controls sent by clients are termed 'request controls', and those sent by servers are termed 'response controls'.
クライアントによって送られたコントロールは'要求コントロール'と呼ばれます、そして、サーバによって送られたものは'応答制御'と呼ばれます。
Controls ::= SEQUENCE OF control Control
コントロール:、:= SEQUENCE OFコントロールControl
Control ::= SEQUENCE {
controlType LDAPOID,
criticality BOOLEAN DEFAULT FALSE,
controlValue OCTET STRING OPTIONAL }
以下を制御してください:= 系列controlType LDAPOID、臨界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分野は唯一コントロールを特定するOBJECT IDENTIFIERのドット付き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に関しては、臨界分野SHOULDを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であるなら、サーバは操作を実行してはいけません、そして、応答メッセージを持っている操作のために、それはresultCodeセットとunavailableCriticalExtensionにともに帰らなければなりません。
- 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.
- 臨界にかかわらず、コントロールが操作に適用されるなら、それは全体の操作に一貫して、そして公平に適用されます。
Sermersheim Standards Track [Page 14] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[14ページ]RFC4511LDAPv3 June 2006
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の臨界があるコントロールは、有効な組み合わせに到達するように無視されるかもしれません。 さらに、仕様でオーダー依存する意味論を与えない場合、SEQUENCEのコントロールの組み合わせの注文を無視します。 オーダーを無視されるためにありますが、サーバで無視できないところでは、メッセージは整形式でないと考えられます、そして、操作は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,
- コントロールに割り当てられたOBJECT IDENTIFIER
- 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.
- 任意に、他があるコントロールの組み合わせに関する意味論は制御されます。
Sermersheim Standards Track [Page 15] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[15ページ]RFC4511LDAPv3 June 2006
4.2. Bind Operation
4.2. ひもの操作
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].
Bind操作の機能は認証情報がクライアントとサーバの間で交換されるのを許容することです。Bind操作は「認証」操作として考えられるべきです。 [RFC4513]でこの操作の操作上の、そして、認証であって、セキュリティ関連の意味論を与えます。
The Bind request is defined as follows:
Bind要求は以下の通り定義されます:
BindRequest ::= [APPLICATION 0] SEQUENCE {
version INTEGER (1 .. 127),
name LDAPDN,
authentication AuthenticationChoice }
BindRequest:、:= [アプリケーション0] 系列バージョンINTEGER、(1 .127) 名前LDAPDN、認証AuthenticationChoice
AuthenticationChoice ::= CHOICE {
simple [0] OCTET STRING,
-- 1 and 2 reserved
sasl [3] SaslCredentials,
... }
AuthenticationChoice:、:= 選択簡単な[0]OCTET STRING(1と2予約されたsasl[3]SaslCredentials)
SaslCredentials ::= SEQUENCE {
mechanism LDAPString,
credentials OCTET STRING OPTIONAL }
SaslCredentials:、:= 系列メカニズムLDAPString、資格証明書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.
- 以下を命名してください。 空でないなら、クライアントが縛りたがっているディレクトリオブジェクトの名前です。 この分野は、匿名のひも([RFC4513]、セクション5.1)かいつに関する目的のために、SASL[RFC4422]認証([RFC4513]、セクション5.2)を使用することでヌル値(ゼロ長ストリング)を呈するかもしれないか。 サーバが、命名されたオブジェクトの場所を見つけるのを試みて、それがSHALL NOTであるところでは、働いてください。別名の「反-参照をつけ」。
- 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で定義されるように広げることができます。 クライアントによって供給された選択をサポートしないサーバがresultCodeセットがあるBindResponseをauthMethodNotSupportedに返します。
Sermersheim Standards Track [Page 16] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[16ページ]RFC4511LDAPv3 June 2006
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 SHALLを使用することでサーバに移されました。UTF-8として移して、[RFC3629]が[ユニコード]をコード化したということになってください。 転送の前に、クライアントSHOULDは、「質問」ストリングとしてstringprep[RFC3454]アルゴリズムのSASLprep[RFC4013]プロフィールを適用することによって、テキストパスワードを準備します。 他のデータ(無作為の八重奏などの)から成るパスワードを変更してはいけません。 パスワードが原文であるかどうかに関する決断はローカルのクライアント問題です。
4.2.1. Processing of the Bind Request
4.2.1. ひもの要求の処理
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を処理する前に、すべての未完成の操作が完全な状態で捨てなければなりませんか、または捨てられてください。 サーバは、完了する未完成の操作を待っているか、またはそれらを捨てるかもしれません。 そして、サーバは中のaが命令を与えるクライアントか多段階Bindプロセスを認証しかけます。 各ステップは、認証の状態を示すために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 PDUsを送ってはいけません。 同様に、サーバSHOULD NOTは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セッションのときに付かないのを選ぶなら、それは、BindRequestを送りながら、最初にでLDAPセッションを終えて、それを復職させて、やり直すかもしれません。 これはサーバが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.
クライアントは認証、そして/または、セキュリティ協会を変えるか、またはマルチステージBindの過程を完了するという複数のBind要求を送るかもしれません。 以前のひもからの認証は次に、無視されます。
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.
いくつかのSASL認証機構に、クライアントが複数の回([RFC4513]、セクション5.2)BindRequestを呼び出すのが必要であるかもしれません。 クライアントはマルチステージBindの一部としてされた2つのBind要求の間の操作を呼び出してはいけません。
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ひもの交渉を中止するかもしれません。
Sermersheim Standards Track [Page 17] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[17ページ]RFC4511LDAPv3 June 2006
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を送るなら、サーバはresultCodeセットがあるBindResponseをauthMethodNotSupportedに返さなければなりません。 これで、同じSASLメカニズムで再試行したいなら、クライアントは交渉を中止できるでしょう。
4.2.2. Bind Response
4.2.2. ひもの応答
The Bind response is defined as follows.
Bind応答は以下の通り定義されます。
BindResponse ::= [APPLICATION 1] SEQUENCE {
COMPONENTS OF LDAPResult,
serverSaslCreds [7] OCTET STRING OPTIONAL }
BindResponse:、:= [アプリケーション1] 系列LDAPResultの部品、serverSaslCreds[7]八重奏ストリング、任意
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.
うまくいっているBind操作は成功に用意ができている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のこのバージョンをサポートしないと仮定することになっています。 クライアントができるかもしれない間、このプロトコル(輸送接続を閉じて、復職させるのを必要とするかもしれない)の別のバージョンを続けてください、このプロトコルの別のバージョンを続けるのはどうこのドキュメントの範囲を超えているか。 SHOULDを続かせたがっていないクライアントが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メカニズムで制限されたクライアントがサーバを必要としないなら、クライアント、次に、この分野SHALL NOTに情報を返すには、BindResponseで含められてください。
4.3. Unbind Operation
4.3. 操作を解いてください。
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.
Unbind操作の機能はLDAPセッションを終えることです。 名前が含意するようにUnbind操作はBind操作の正反対ではありません。 これらの操作の命名は歴史的です。 Unbind操作は「やめてください」という操作として考えられるべきです。
Sermersheim Standards Track [Page 18] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[18ページ]RFC4511LDAPv3 June 2006
The Unbind operation is defined as follows:
Unbind操作は以下の通り定義されます:
UnbindRequest ::= [APPLICATION 2] NULL
UnbindRequest:、:= [アプリケーション2] ヌル
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で指定されるように扱われます。
4.4. Unsolicited Notification
4.4. 求められていない通知
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.
messageIDがゼロとprotocolOpであるLDAPMessageがextendedResp選択に用意ができているとき、求められていない通知は、ExtendedResponseタイプを使用することで構造化されます(セクション4.12を見てください)。 ExtendedResponseのresponseName分野はいつもこの通知に、ユニークなLDAPOIDを含んでいます。
One unsolicited notification (Notice of Disconnection) is defined in this document. The specification of an unsolicited notification consists of:
1つの求められていない通知(Disconnectionの通知)が本書では定義されます。 求められていない通知の仕様は以下から成ります。
- the OBJECT IDENTIFIER assigned to the notification (to be specified
in the responseName,
- OBJECT IDENTIFIERが通知に割り当てた、(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.
- メッセージの意味論。
4.4.1. Notice of Disconnection
4.4.1. 断線の通知
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セッションを終えようとしているとクライアントに忠告するかもしれません。 この通知が例外的なサーバ状態と一時的なネットワーク失敗を見分けるのにクライアントを助けることを意図します。 この通知がクライアントによって要求されたUnbindへの応答でないことに注意してください。 未完成の操作はセクション3.1で指定されるように扱われます。
Sermersheim Standards Track [Page 19] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[19ページ]RFC4511LDAPv3 June 2006
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はそうです。1.3 .6 .1 .4 .1 .1466 .20036 responseValue分野は欠けていて、resultCodeは、断線の理由を示すのに使用されます。 いつ、strongerAuthRequired resultCodeがあるかがこのメッセージとともに帰って、検出されて、それは、サーバがそうしたのを示します。クライアントとサーバとの設立されたセキュリティ仲間は、不意に失敗されるか、または感染されました。
Upon transmission of the Notice of Disconnection, the server gracefully terminates the LDAP session as described in Section 5.3.
DisconnectionのNoticeのトランスミッションのときに、サーバはセクション5.3で説明されるように優雅にLDAPセッションを終えます。
4.5. Search Operation
4.5. 索敵行動
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.
検索操作は、アクセス制御と他の制限(複雑な検索評価基準に合っている1セットのエントリー)を条件として戻るようサーバに要求するのに使用されます。 単一のエントリーから属性を読むのにこれを使用できます、すぐに特定のエントリー、または、エントリーの全体の下位木からの下位のエントリーから。
4.5.1. Search Request
4.5.1. 検索要求
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 }
SearchRequest:、:= [アプリケーション3] 系列baseObject LDAPDN、範囲ENUMERATED、baseObject(0)、singleLevel(1)、wholeSubtree(2)、…、derefAliases ENUMERATED、neverDerefAliases(0)、derefInSearching(1)、derefFindingBaseObj(2)、derefAlways(3)、sizeLimit INTEGER(0maxInt)、typesOnlyブールであるtimeLimit INTEGER(0maxInt)はFilterをフィルターにかけます、属性AttributeSelection
AttributeSelection ::= SEQUENCE OF selector LDAPString
-- The LDAPString is constrained to
-- <attributeSelector> in Section 4.5.1.8
AttributeSelection:、:= SEQUENCE OFセレクタLDAPString--抑制されたLDAPString--<attributeSelector>コネセクション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,
以下をフィルターにかけてください:= CHOICE、[0] SET SIZE(1..MAX)OFは[2]フィルタではなく、Filter、または[1]SET SIZE(1..MAX)OFフィルタFilterをフィルターにかけます。
Sermersheim Standards Track [Page 20] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[20ページ]RFC4511LDAPv3 June 2006
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion,
present [7] AttributeDescription,
approxMatch [8] AttributeValueAssertion,
extensibleMatch [9] MatchingRuleAssertion,
... }
equalityMatch[3]AttributeValueAssertion、サブストリング[4]SubstringFilter、greaterOrEqual[5]AttributeValueAssertion(lessOrEqual[6]AttributeValueAssertion)は[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
}
SubstringFilter:、:= 系列タイプAttributeDescription、サブストリングSEQUENCE SIZE(1..MAX)OFサブストリングCHOICEは[0] AssertionValue--[1] 一度だいたいのいずれもAssertionValueに起こることができる決勝[2]AssertionValueに頭文字をつけます--高々一度起こることができます。
MatchingRuleAssertion ::= SEQUENCE {
matchingRule [1] MatchingRuleId OPTIONAL,
type [2] AttributeDescription OPTIONAL,
matchValue [3] AssertionValue,
dnAttributes [4] BOOLEAN DEFAULT FALSE }
MatchingRuleAssertion:、:= 系列matchingRule[1]MatchingRuleId OPTIONAL、タイプ[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.
フィルタが'objectClass'属性の存在がないかどうかチェックしている状態でsingleLevel検索操作を要求するクライアントがX.500の「リスト」のような操作を見習うことができて、同じフィルタによるbaseObject検索操作でX.500の「読み」のような操作を見習うことができることに注意してください。 X.500へのゲートウェイを提供するサーバはReadかList操作を使用するのに必要ではありません、そうするのを選ぶかもしれません、そして、そうするなら、X.500検索操作と同じ意味論を前提としなければなりませんが。
4.5.1.1. SearchRequest.baseObject
4.5.1.1. SearchRequest.baseObject
The name of the base object entry (or possibly the root) relative to which the Search is to be performed.
ベースオブジェクトエントリー(または、ことによると根)に比例して実行される検索がことである名前。
4.5.1.2. SearchRequest.scope
4.5.1.2. SearchRequest.scope
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によって指定されたエントリーの即座の部下に抑制されます。
Sermersheim Standards Track [Page 21] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[21ページ]RFC4511LDAPv3 June 2006
wholeSubtree: The scope is constrained to the entry named by
baseObject and to all its subordinates.
wholeSubtree: 範囲はbaseObjectによって指定されたエントリーと、そして、そのすべての部下に抑制されます。
4.5.1.3. SearchRequest.derefAliases
4.5.1.3. SearchRequest.derefAliases
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: 探している間、ベースの部下は反対して、反参照は検索範囲の中のあらゆる別名です。 Dereferencedオブジェクトはまた検索操作が適用される一層の検索範囲の頭頂になります。 検索範囲がwholeSubtreeであるなら、検索はどんな「反-参照をつけ」られたオブジェクトの下位木でも続きます。 検索範囲がsingleLevelであるなら、検索は、どんな「反-参照をつけ」られたオブジェクトにも適用されて、彼らの部下に適用されません。 SHOULDが排除するサーバは別名の「反-参照をつけ」のため探している間に起こるエントリーをコピーします。
derefFindingBaseObj: Dereference aliases in locating the base
object of the Search, but not when searching subordinates of the
base object.
derefFindingBaseObj: ベースオブジェクトの部下を身体検査しないとき検索のベース目的の場所を見つけることにおけるDereference別名。
derefAlways: Dereference aliases both in searching and in locating
the base object of the Search.
derefAlways: 探して、検索のベース目的の場所を見つけることにおけるDereference別名。
4.5.1.4. SearchRequest.sizeLimit
4.5.1.4. SearchRequest.sizeLimit
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.
検索の結果、返されるエントリーの最大数を制限するサイズ限界。 この分野のゼロの値は、検索には、どんなクライアントによって要求されたサイズ限界制限も有効でないことを示します。 また、サーバは、戻るために最大数のエントリーを実施するかもしれません。
Sermersheim Standards Track [Page 22] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[22ページ]RFC4511LDAPv3 June 2006
4.5.1.5. SearchRequest.timeLimit
4.5.1.5. SearchRequest.timeLimit
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.
最大の時間(秒の)を制限するタイムリミットは検索を考慮しました。 この分野のゼロの値は、どんなクライアントも、検索に、タイムリミット制限が有効であるよう要求しなかったのを示します。 また、サーバは検索のために最大のタイムリミットを実施するかもしれません。
4.5.1.6. SearchRequest.typesOnly
4.5.1.6. SearchRequest.typesOnly
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に設定するのに、属性記述と値の両方を返します。
4.5.1.7. SearchRequest.filter
4.5.1.7. SearchRequest.filter
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.)
フィルタの組み合わせを形成するのに'and'、'or'、および'not'選択を使用できます。 少なくとも1個のフィルタエレメントが'and'か'or'選択で存在していなければなりません。 他のものは検索の範囲のエントリーの個々の属性値に対して合っています。 (作成者の注意: 'not'フィルタはそれとなくタグ付けをされたモジュールにおけるタグ付けをされた選択に関する例です。 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.
Clause、[X.511](1993)の3で評価された論理によると、サーバがフィルタを評価しなければならない、7.8、.1 概要では、フィルタは、「本当」に関する評価にされる、「誤る」、または「未定義です」。 フィルタは特定のエントリー(そのエントリーの属性が検索結果(どんな適切なアクセス制御制限を条件とした)の一部として返されるその時)のためにTRUEに評価します。 フィルタはFALSEかUndefined、その時までエントリーを評価します。検索のために、無視されます。
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.
SET OFのすべてのフィルタが、そうでなければ、少なくとも1個のフィルタがFALSEと、UndefinedであるかどうかTRUE、FALSEに評価するなら、“and"選択のフィルタはTRUEです。 SET OFのすべてのフィルタが、そうでなければ、少なくとも1個のフィルタがTRUEと、UndefinedであるかどうかFALSE、TRUEに評価するなら、“or"選択のフィルタはFALSEです。 否定されるフィルタがFALSEであるなら、'not'選択のフィルタはTRUEです、そして、それであるなら、FALSEはTRUEです、そして、それであるなら、UndefinedはUndefinedです。
A filter item evaluates to Undefined when the server would not be able to determine whether the assertion value matches an entry. Examples include:
フィルタの品目は、サーバが、いつ主張値がエントリーに合っているかどうか決定できないかをUndefinedに評価します。 例は:
Sermersheim Standards Track [Page 23] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[23ページ]RFC4511LDAPv3 June 2006
- 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)がそれぞれUndefinedに評価するフィルタ。
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].
属性記述か合っている規則イドが認識されないか、主張値が無効であるか、または主張構文がサポートされないなら、サーバは誤りを返してはいけません。 Clause7.8で[X.511]をフィルタ処理に関するその他の詳細に与えます。
4.5.1.7.1. SearchRequest.filter.equalityMatch
4.5.1.7.1. SearchRequest.filter.equalityMatch
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フィルタのための合っている規則は属性のタイプか「副-タイプ」のためにEQUALITYの合っている規則で定義されます。 EQUALITY規則が属性への適用されるとしてのTRUEか「副-タイプ」と断言された値を返すとき、フィルタはTRUEです。
4.5.1.7.2. SearchRequest.filter.substrings
4.5.1.7.2. SearchRequest.filter.substrings
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'.
SHALLは高々そこでは、そうです。SubstringFilterの'サブストリング'における1つの'初期'の決勝と高々1'決勝'。 '初期'は存在していて、それはSHALLです。'サブストリング'の最初の要素になってください。 '最終的'は存在していて、それはSHALLです。'サブストリング'の最後の要素になってください。
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の合っている規則の主張構文にというよりむしろ属性タイプのためのEQUALITYの合っている規則の主張構文に一致しています。 概念的に、全体のSubstringFilterは規則を適用する前に規則に合っているサブストリングの主張値に変換されます。
Sermersheim Standards Track [Page 24] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[24ページ]RFC4511LDAPv3 June 2006
4.5.1.7.3. SearchRequest.filter.greaterOrEqual
4.5.1.7.3. SearchRequest.filter.greaterOrEqual
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の合っている規則で定義されます。 ORDERING規則が属性への適用されるとしてのFALSEか「副-タイプ」と断言された値を返すとき、フィルタはTRUEです。
4.5.1.7.4. SearchRequest.filter.lessOrEqual
4.5.1.7.4. SearchRequest.filter.lessOrEqual
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とEQUALITYの合っている規則で定義されます。 ORDERINGかEQUALITY規則が属性への適用されるとしてのTRUEか「副-タイプ」と断言された値を返すとき、フィルタはTRUEです。
4.5.1.7.5. SearchRequest.filter.present
4.5.1.7.5. SearchRequest.filter.present
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の現在の指定された属性記述の属性か「副-タイプ」がエントリー、およびUndefinedにあるとき、現在のフィルタはTRUEです。
4.5.1.7.6. SearchRequest.filter.approxMatch
4.5.1.7.6. SearchRequest.filter.approxMatch
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.
何らかの局所的に定義された大体の合っているアルゴリズム(例えば、スペル変化、音声のマッチなど)がTRUEを返す属性のタイプか「副-タイプ」の値があるとき、approxMatchフィルタはTRUEです。 また、値が平等のために合っているなら、それは大体のマッチを満たします。 大体のマッチングが属性のためにサポートされないなら、このフィルタの品目はequalityMatchとして扱われるべきです。
4.5.1.7.7. SearchRequest.filter.extensibleMatch
4.5.1.7.7. SearchRequest.filter.extensibleMatch
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は指定された属性タイプとその血液型亜型に対して比較されます。
Sermersheim Standards Track [Page 25] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[25ページ]RFC4511LDAPv3 June 2006
- 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と属性がいったん決定するようになると、フィルタの品目は、matchingRuleが認識されないか、使用に、matchingRuleが指定されたタイプで不適当であるか、またはassertionValueが無効であり、エントリー、およびUndefinedの属性タイプや「副-タイプ」を少しの合わせないならそれが少なくとも1人の属性タイプかエントリーにおける「副-タイプ」、FALSEに合っているかどうかTRUEに評価します。
4.5.1.8. SearchRequest.attributes
4.5.1.8. SearchRequest.attributes
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値は以下のAugmented BN記法(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. 「*」(ゼロか以上で、記述を結果と考える)を含むリストは他の記載された(操作上の)属性に加えたすべてのユーザ属性の復帰を要求します。
Sermersheim Standards Track [Page 26] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[26ページ]RFC4511LDAPv3 June 2006
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. 「1.1インチは返すためにどんな属性もそうでないことを示す」OIDだけを入れてあるリスト。 「他のattributeSelector値、「1.1インチのattributeSelectorは無視されること」を1.1インチに提供します。 そして、この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.
属性はエントリーで高々一度返されます。 属性記述がリストの一度よりもう少し命名されるなら、その後の名前は無視されます。 リストにおける属性記述が認識されないなら、それはサーバによって無視されます。
4.5.2. Search Result
4.5.2. 検索結果
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 }
SearchResultEntry:、:= [アプリケーション4] 系列objectName LDAPDN、属性PartialAttributeList
PartialAttributeList ::= SEQUENCE OF
partialAttribute PartialAttribute
PartialAttributeList:、:= partialAttribute PartialAttributeの系列
SearchResultReference ::= [APPLICATION 19] SEQUENCE
SIZE (1..MAX) OF uri URI
SearchResultReference:、:= [APPLICATION19] SEQUENCE SIZE(1..MAX)OF uri URI
SearchResultDone ::= [APPLICATION 5] LDAPResult
SearchResultDone:、:= [アプリケーション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で返された各エントリーはアクセスコントロールと他の施政方針を条件として検索Requestの属性分野の指定されるとしてのすべての適切な属性を含むでしょう。 PartialAttributeListが零元を保持するかもしれないことに注意してください。
Sermersheim Standards Track [Page 27] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[27ページ]RFC4511LDAPv3 June 2006
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 valsセットが零元を保持するかもしれないことに注意してください。 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属性リストに現れるかもしれません、それらはエントリーの保存された属性ではありませんが。 これがアクセスコントロールで受入れられても、クライアントSHOULD NOTは、すべての属性を変更できると仮定します。
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]を定義するなら、サーバSHOULDはその属性タイプ(属性タイプのオブジェクト識別子の<numericoid>[RFC4512]形式を使用することに優先した)に属性記述にそれらの名前の1つを使用します。 その名前があいまいであることがサーバによって知られているか、またはそうでなければ、それが相互運用性問題を引き起こしそうであるなら、サーバSHOULD NOTは省略名を使用します。
4.5.3. Continuation References in the Search Result
4.5.3. 検索結果における継続参照
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).
サーバができたなら、エントリーの場所を見つけるのが検索1か、より多くの非地方のエントリーにbaseObjectで言及しますが、不本意であった、サーバは1つ以上のSearchResultReferenceメッセージを返すかもしれません、それぞれもう1セットのサーバの操作を続ける参照を含んでいて。 サーバはどんなSearchResultReferenceメッセージも返して、baseObjectの場所を見つけていなくて、その結果、少しのエントリーも捜していてはいけません。 この場合、それは紹介かnoSuchObject結果コードのどちらかを含む(baseObjectで指定されたエントリーに関するサーバの知識によります)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はReferralと同じデータ型のものです。
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も操作を進行するのに使用されるかもしれないと仮定します。
Sermersheim Standards Track [Page 28] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[28ページ]RFC4511LDAPv3 June 2006
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で説明されたAbandon操作がクライアントとサーバの間の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].
[RFC4516]に従って、LDAPとTCP/IPを通してアクセスしやすい(v4かv6)[RFC793][RFC791]を実装するサーバのためのURIは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 MUSTの>部分を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.
- <範囲の>一部があいまいさを避けるために存在しているのは、RECOMMENDEDです。 <範囲の>一部が不在のとき、オリジナルの検索要求の範囲は想定されます。
- 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を無視するかもしれません。
Sermersheim Standards Track [Page 29] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[29ページ]RFC4511LDAPv3 June 2006
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のコード化されたUTF8キャラクタ、検索フィルタ、または紹介価値の他の野原をURI(例えば、空間)には法的でないかもしれなく、[RFC3986]の%メソッドを使用して、逃げなければなりません。
4.5.3.1. Examples
4.5.3.1. 例
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)の両方が<OU=人々を保持するのを知っています、そして、DCは例と等しいです、そして、DCはNET>と等しいです、そして、(1がマスターであり、もう片方のサーバは影です)そのLDAPできるサーバ(hostd)は下位木<OU=役割を主張します、DC=例、NET DC=>。 <DCのwholeSubtree検索が例と等しいなら、NET 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)
SearchResultEntry、CN=マネージャ、DC=がSearchResultReferenceを網で覆うDC=例のためのネットの例、DC=DC=SearchResultEntryに関しては、ネット?例、人々、DC=ネット?ldap://hostb/OU=人々、DC=例、潜水艦ldap://hostc/OU=DC=DC=潜水艦SearchResultReferenceがネット?://hostd/OU=役割、DC=例、DC=潜水艦をldapする、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=例、NET DC=>、サーバは以下の通り反応するかもしれません:
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)
SearchResultEntry、OU=人々、DC=がSearchResultReferenceを網で覆うDC=例に関しては、ネット?ldap://hoste/OU=マネージャ、OU=人々、DC=例、DC=潜水艦SearchResultReferenceがネット?://hostf/OU=コンサルタント、OU=人々、DC=例、DC=潜水艦をldapする、SearchResultDone(成功)
Similarly, if a singleLevel Search of <DC=Example,DC=NET> is requested to the contacted server, it may return the following:
同様に、<DCのsingleLevel検索が例と等しいなら、NET DC=>は連絡されたサーバに要求されて、以下を返すかもしれません:
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)
SearchResultEntry、CN=マネージャ、DC=がSearchResultReferenceを網で覆うDC=例に関しては、ネット?例、人々、DC=ネット?ldap://hostb/OU=人々、DC=例、ベースldap://hostc/OU=DC=DC=ベースSearchResultReferenceがネット?://hostd/OU=役割、DC=例、DC=ベースをldapする、SearchResultDone(成功)
Sermersheim Standards Track [Page 30] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[30ページ]RFC4511LDAPv3 June 2006
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?潜水艦と等しいです。
4.6. Modify Operation
4.6. 操作を変更してください。
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:
クライアントは、Modify操作からエントリーの変更がサーバによって利益に実行されるよう要求できます。Modify Requestは以下の通り定義されます:
ModifyRequest ::= [APPLICATION 6] SEQUENCE {
object LDAPDN,
changes SEQUENCE OF change SEQUENCE {
operation ENUMERATED {
add (0),
delete (1),
replace (2),
... },
modification PartialAttribute } }
ModifyRequest:、:= [アプリケーション6] 系列オブジェクトLDAPDN、変化SEQUENCE OFがSEQUENCEを変える、操作ENUMERATEDは(0) (1)を削除するように言い足して、(2)、…を取り替えます、変更PartialAttribute
Fields of the Modify Request are:
Modify Requestの分野は以下の通りです。
- 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.
- オブジェクト: この分野の値は変更されるべきエントリーの名前を含んでいます。 オブジェクトが変更されることを決定する際にサーバSHALL NOTはどんな別名の「反-参照をつけ」も実行します。
- 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].
- 変化: エントリーに実行されるべき変更箇所一覧。 全体の変更箇所一覧はオーダーで実行されて、それらがただ一つの原子操作として記載されているということであるに違いありません。 個々の変更がディレクトリ図式(オブジェクトクラス定義とディレクトリ情報Tree(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.
加えます: 必要なら、属性を作成して、値が変更属性に記載したと言い足してください。
Sermersheim Standards Track [Page 31] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[31ページ]RFC4511LDAPv3 June 2006
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(valsの空のSETを持っているかもしれない)は、以前はよく属性タイプか属性タイプと値が変更されているままにしました。
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:
Modify Requestを受け取り次第、サーバは、DITへの必要な変更を実行するのを試みて、以下の通り定義されたModify Responseで結果を返します:
ModifyResponse ::= [APPLICATION 7] LDAPResult
ModifyResponse:、:= [アプリケーション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変更の無事終了、または変更が失敗した理由を示す独身のModify Responseをクライアントに返すでしょう。 Modify Requestの変更箇所一覧を適用することにおける最小単位のための要件のため、クライアントは、受け取られたModify Responseがどんな種類の誤りも示すならDITの変更が全く実行されていなくて、すべてが、Modify ResponseがModify操作の無事終了を示すなら変更が実行されたよう要求したと予想するかもしれません。 Modify Responseが受け取られなかったなら(例えばLDAPセッションが終えられたか、またはModify操作は捨てられました)、クライアントは変更が適用されたかどうか決定できません。
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.
サーバは、エントリーがユーザとシステム図式規則か他のデータモデル規制に従うのを確実にしなければなりません。 エントリーから顕著な値(すなわち、エントリーの相対的な分類名を形成するそれらの値)のどれかを取り除くのにModify操作を使用できません。 そうする試みはnotAllowedOnRDN結果コードを返すサーバをもたらすでしょう。 セクション4.9で説明されたModify DN操作は、エントリーを改名するのに使用されます。
For attribute types that specify no equality matching, the rules in Section 2.5.1 of [RFC4512] are followed.
指定する属性タイプにとって、平等が全く合っていなくて、.1セクション2.5[RFC4512]の規則は従われています。
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
LDAPでされた簡素化のLDAP ModifyRequestにおける変化のダイレクトマッピングがDAP ModifyEntry操作、および異なった実装の変化へのためでないことに注意してください。
Sermersheim Standards Track [Page 32] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[32ページ]RFC4511LDAPv3 June 2006
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では、ゲートウェイは変化を表す異なった手段を使用するかもしれません。 うまくいくなら、エントリーへの操作の最終的な効果は同じであるに違いありません。
4.7. Add Operation
4.7. 操作を加えてください。
The Add operation allows a client to request the addition of an entry into the Directory. The Add Request is defined as follows:
Add操作で、クライアントはエントリーの追加をディレクトリに要求できます。 Add Requestは以下の通り定義されます:
AddRequest ::= [APPLICATION 8] SEQUENCE {
entry LDAPDN,
attributes AttributeList }
AddRequest:、:= [アプリケーション8] 系列エントリーLDAPDN、属性AttributeList
AttributeList ::= SEQUENCE OF attribute Attribute
AttributeList:、:= SEQUENCE OF属性Attribute
Fields of the Add Request are:
Add Requestの分野は以下の通りです。
- entry: the name of the entry to be added. The server SHALL NOT
dereference any aliases in locating the entry to be added.
- エントリー: 加えられるべきエントリーの名前。 サーバSHALL NOT反参照、加えられるためにエントリーの場所を見つけることにおけるどんな別名。
- 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属性などの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).
サーバは、エントリーがユーザとシステム図式規則か他のデータモデル規制に従うのを確実にしなければなりません。 指定する属性タイプにとって、平等が全く合っていなくて、.1セクション2.5[RFC4512]の規則は従われています(これは加えられるどんなマルチ評価された属性に加えた命名属性に適用されます)。
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のエントリー分野で指定されたエントリーは存在してはいけません。 加えられるべきオブジェクトか通称エントリーの即座の上司(親)は存在しなければなりません。 NET例えば、DCクライアントが、<CN=JS、DCが例と等しいと言い足すのを試みたなら=>、<DC=例、NET>DC=エントリーは存在しませんでした、そして、NET><DC=エントリーは存在しました、そして、次に、サーバはNET<DC=>を含んでいる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:
Add Requestを受け取り次第、サーバは、要求されたエントリーを加えるのを試みるでしょう。 Add試みの結果は以下の通り定義されたAdd Responseのクライアントに返されるでしょう:
AddResponse ::= [APPLICATION 9] LDAPResult
AddResponse:、:= [アプリケーション9] LDAPResult
Sermersheim Standards Track [Page 33] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[33ページ]RFC4511LDAPv3 June 2006
A response of success indicates that the new entry has been added to the Directory.
成功の応答は、新しいエントリーをディレクトリに追加してあるのを示します。
4.8. Delete Operation
4.8. 操作を削除してください。
The Delete operation allows a client to request the removal of an entry from the Directory. The Delete Request is defined as follows:
Delete操作で、クライアントはディレクトリからエントリーの取り外しを要求できます。 Delete Requestは以下の通り定義されます:
DelRequest ::= [APPLICATION 10] LDAPDN
DelRequest:、:= [アプリケーション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.
Delete Requestは、削除されるためにエントリーの名前から成ります。 取り除くために目標エントリーの名前を決議するSHALL NOT反参照別名がゆったり過ごすサーバ。
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:
Delete Requestを受け取り次第、サーバは、取り外しが要求したエントリーを実行して、以下の通り定義されたDelete Responseで結果を返すのを試みるでしょう:
DelResponse ::= [APPLICATION 11] LDAPResult
DelResponse:、:= [アプリケーション11] LDAPResult
4.9. Modify DN Operation
4.9. DN操作を変更してください。
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:
Modify DN操作で、クライアントは、ディレクトリにおけるエントリーのRelative Distinguished Name(RDN)を変えて、エントリーの下位木をディレクトリにおける新しい位置に動かします。 Modify DN Requestは以下の通り定義されます:
ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
entry LDAPDN,
newrdn RelativeLDAPDN,
deleteoldrdn BOOLEAN,
newSuperior [0] LDAPDN OPTIONAL }
ModifyDNRequest:、:= [アプリケーション12] 系列エントリーLDAPDN、newrdn RelativeLDAPDN、ブールdeleteoldrdn newSuperior[0]LDAPDN OPTIONAL
Fields of the Modify DN Request are:
Modify DN Requestの分野は以下の通りです。
- 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の属性値はエントリーに加えられます、そして、これが失敗するなら、適切な誤りは返されます。
Sermersheim Standards Track [Page 34] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[34ページ]RFC4511LDAPv3 June 2006
- 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.
オブジェクトの場所を見つけることにおけるどんな別名もエントリーで命名したサーバSHALL NOT反参照か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を受け取り次第、サーバは、改名を実行するのを試みて、以下の通り定義されたModify DN Responseで結果を返すでしょう:
ModifyDNResponse ::= [APPLICATION 13] LDAPResult
ModifyDNResponse:、:= [アプリケーション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.
例えば、cはエントリー分野で指定されたエントリーがジョン・<cn=スミスであったなら、米国>と等しいです、そして、newrdn分野はジョンCougarスミス<cn=>でした、そして、newSuperior分野が欠けていた、次に、この操作は<cnがジョン・Cougarスミスと等しいときにエントリーを改名するのを試みるでしょう、米国c=>。 その名前によるエントリーが既にあれば、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).
サーバは、エントリーがユーザとシステム図式規則か他のデータモデル規制に従うのを確実にしなければなりません。 指定する属性タイプにとって、平等が全く合っていなくて、.1セクション2.5[RFC4512]の規則は従われています(これは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で指定されたオブジェクトは存在しなければなりません。 NET例えば、DCクライアントが、<CN=JS、DCが例と等しいと言い足すのを試みたなら=>、<DC=例、NET>DC=エントリーは存在しませんでした、そして、NET><DC=エントリーは存在しました、そして、次に、サーバはNET<DC=>を含んでいる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がただ一つのサーバの中に含まれているエントリーだけに影響するようにModifyDN操作を制限することに注意してください。LDAPサーバがDAPに写像されると、この制限は適用されるでしょう、そして、この誤りが発生したなら、affectsMultipleDSAs結果コードは返されるでしょう。 一般に、クライアントは、サーバか文脈を命名することの間のエントリーと下位木の任意の運動を実行できると予想してはいけません。
Sermersheim Standards Track [Page 35] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[35ページ]RFC4511LDAPv3 June 2006
4.10. Compare Operation
4.10. 操作を比較してください。
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:
Compare操作で、クライアントはディレクトリにおける特定のエントリーにおける、特定の属性の値と主張値を比べることができます。 Compare Requestは以下の通り定義されます:
CompareRequest ::= [APPLICATION 14] SEQUENCE {
entry LDAPDN,
ava AttributeValueAssertion }
CompareRequest:、:= [アプリケーション14] 系列エントリーLDAPDN、ava AttributeValueAssertion
Fields of the Compare Request are:
Compare Requestの分野は以下の通りです。
- entry: the name of the entry to be compared. The server SHALL NOT
dereference any aliases in locating the entry to be compared.
- エントリー: 比較されるべきエントリーの名前。 サーバSHALL NOT反参照、比較されるためにエントリーの場所を見つけることにおけるどんな別名。
- 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:
Compare Requestを受け取り次第、サーバは、要求された比較を実行するのを試みて、以下の通り定義されたCompare Responseで結果を返すでしょう:
CompareResponse ::= [APPLICATION 15] LDAPResult
CompareResponse:、:= [アプリケーション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に合っている属性のEQUALITYに従った「副-タイプ」が、主張がavaで属性の分野と値を評価するのを示すか、または「副-タイプ」は合っていませんでした。 他の結果コードが、比較の結果がUndefinedであったのを示す、(セクション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などの)の値が他の手段で比較されますが、査問されないことを許可するアクセス制御を確立するかもしれないことに注意してください。
4.11. Abandon Operation
4.11. 操作を捨ててください。
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:
Abandon操作の機能はクライアントが、サーバが未完成の操作を捨てるよう要求するのを許容することです。 Abandon Requestは以下の通り定義されます:
AbandonRequest ::= [APPLICATION 16] MessageID
AbandonRequest:、:= [アプリケーション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.
MessageIDは、より早くこのLDAPメッセージ層で要求された操作のものです。 Abandon要求自体には、それ自身のMessageIDがあります。 これは捨てられる以前の操作のMessageIDと異なっています。
Sermersheim Standards Track [Page 36] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[36ページ]RFC4511LDAPv3 June 2006
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.
Abandon操作で定義された応答が全くありません。 AbandonRequestを受け取り次第、サーバはMessageIDによって特定された操作を捨てるかもしれません。 クライアントが首尾よく捨てられた操作と未完成の操作の違いを言うことができないので、Abandon操作の応用はクライアントが結果のしるしを必要としない用途に制限されます。
Abandon, Bind, Unbind, and StartTLS operations cannot be abandoned.
放棄、Bind、Unbind、および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.
サーバが検索への伝える応答の中での検索操作にAbandon Requestを受ける場合、そのサーバは、すぐに捨てられた要求へのエントリー応答を伝えるのをやめなければなりません、そして、それはSearchResultDoneを送ってはいけません。 もちろん、サーバは適切にコード化されたLDAPMessage PDUsだけが伝えられるのを確実にしなければなりません。
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).
クライアントは同じ操作を求めるAbandon要求に複数の回を送るべきではありません、そして、また、それらが捨てた操作から結果を受けるようにそれらを準備しなければなりません(これらがそうしたかもしれないので、Abandonであるときに、あって、トランジットは、要求しなかったか、捨てることができないかもしれません)。
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と既に捨てられた操作を求めるAbandon要求を捨てなければなりません。
4.12. Extended Operation
4.12. 拡大手術
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).
Extended操作は、兼業がプロトコルで既に利用可能でないサービスのために定義されるのを許容します。 例えば、インストールするAdd操作に、層のセキュリティを輸送してください(セクション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操作で、クライアントは、事前に定義された構文と意味論で要求をして、応答を受け取ります。 これらは、RFCsで定義されるか、または特定の実装に個人的であるかもしれません。
Each Extended operation consists of an Extended request and an Extended response.
それぞれのExtended操作はExtended要求とExtended応答から成ります。
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING OPTIONAL }
ExtendedRequest:、:= [アプリケーション23] 系列requestName[0]LDAPOIDで、requestValue[1]八重奏ストリング任意です。
Sermersheim Standards Track [Page 37] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[37ページ]RFC4511LDAPv3 June 2006
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は要求に対応するユニークなOBJECT IDENTIFIERのドット付き10進法表現です。 requestValueはOCTET STRINGの中でカプセル化されたその要求で定義された書式での情報です。
The server will respond to this with an LDAPMessage containing an ExtendedResponse.
LDAPMessageがExtendedResponseを含んでいて、サーバはこれに反応するでしょう。
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS OF LDAPResult,
responseName [10] LDAPOID OPTIONAL,
responseValue [11] OCTET STRING OPTIONAL }
ExtendedResponse:、:= [アプリケーション24] 系列LDAPResult、任意のresponseName[10]LDAPOID responseValue[11]八重奏ストリングの部品、任意
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分野は操作に関連している情報を含んでいます。 これらの分野の書式はExtended操作の仕様で定義されます。 バイトを全く含んでいなくて、これらの分野の任意のコンテンツを扱うように実装を準備しなければなりません。 また、セクション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'属性で認識するExtended Requestsの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に割り当てられたOBJECT IDENTIFIER
- 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(同じOBJECT IDENTIFIERがrequestNameとresponseNameの両方に使用されるかもしれないことに注意する)に割り当てられたOBJECT IDENTIFIER(もしあれば)
Sermersheim Standards Track [Page 38] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[38ページ]RFC4511LDAPv3 June 2006
- the format of the contents of the requestValue and responseValue
(if any), and
- そしてrequestValueとresponseValue(もしあれば)のコンテンツの形式。
- the semantics of the operation.
- 操作の意味論。
4.13. IntermediateResponse Message
4.13. IntermediateResponseメッセージ
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で複数のただ一つの要求/応答操作を定義するのに一般的機構を提供します。 応答情報をIntermediateに返すのを必要とする方法で既存のLDAP操作を広げるとき、複数の新しいただ一つの要求/応答操作を定義するExtended操作に関連してコントロールに関連してこのメッセージが使用されることを意図します。
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メッセージを利用するExtended操作とコントロールの定義と記述が事情を定義することを意図します。
IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
responseName [0] LDAPOID OPTIONAL,
responseValue [1] OCTET STRING OPTIONAL }
IntermediateResponse:、:= [アプリケーション25] 系列任意であって、responseValue[1]八重奏ストリング任意の状態で[0] LDAPOIDをresponseNameします。
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はSHALL NOTを通信させます。クライアントが明確に彼らの帰りに請求する要求を出さない場合、クライアントに返します。 このドキュメントは2つの形式の懇願を定義します: 拡大手術と要求は制御されます。 IntermediateResponseメッセージはそれらが請求される(すなわち、それらを使用するExtended操作か要求コントロール仕様で)方法を説明するドキュメントで指定されます。 これらの仕様は:
- the OBJECT IDENTIFIER (if any) assigned to the responseName,
- responseNameに割り当てられたOBJECT IDENTIFIER(もしあれば)
- 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).
IntermediateResponseメッセージSHALLの複数のタイプの帰りを許す拡大が、ユニークなresponseName値を使用することでそういったタイプの人を特定します(これらの1つが値を全く指定しないかもしれないことに注意してください)。
Sermersheim Standards Track [Page 39] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[39ページ]RFC4511LDAPv3 June 2006
Sections 4.13.1 and 4.13.2 describe additional requirements on the inclusion of responseName and responseValue in IntermediateResponse messages.
セクション4.13.1と.2がresponseNameとresponseValueの包含に関する追加要件について説明する4.13、IntermediateResponseメッセージ。
4.13.1. Usage with LDAP ExtendedRequest and ExtendedResponse
4.13.1. LDAP ExtendedRequestとExtendedResponseがある用法
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.
複数のただ一つの要求/応答操作は、ゼロに請求するただ一つのExtendedRequestメッセージかExtendedResponseメッセージがあとに続いた1種類以上の、より多くのIntermediateResponseメッセージを使用することで定義されるかもしれません。
4.13.2. Usage with LDAP Request Controls
4.13.2. LDAP要求コントロールがある用法
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メッセージが操作のためにコード化するゼロか以上の復帰を含むかもしれません。 要求コントロールに対応して1種類以上の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:
要求コントロールSHALLに関連しているすべての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 Extended操作で含まれています。
4.14. StartTLS Operation
4.14. StartTLS操作
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.
Start Transport Layer Security(StartTLS)操作の目的はTLS層のインストールを開始することです。 StartTLS操作は、セクション4.12で説明されたExtended操作メカニズムを使用することで定義されます。
4.14.1. StartTLS Request
4.14.1. StartTLS要求
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、0.20037インチ、およびrequestValue、分野がいつもある」
Sermersheim Standards Track [Page 40] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[40ページ]RFC4511LDAPv3 June 2006
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 Extended応答を受けるまでこのLDAPメッセージ層のどんなLDAP PDUsもこの要求に続かせてはいけなくて、TLS交渉を終了します。
Detected sequencing problems (particularly those detailed in Section 3.1.1 of [RFC4513]) result in the resultCode being set to operationsError.
検出された配列問題(特に.1セクション3.1[RFC4513]で詳しく述べられたもの)はoperationsErrorに用意ができているresultCodeをもたらします。
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で説明されるようにresultCodeセットとprotocolErrorにともに帰ります。
4.14.2. StartTLS Response
4.14.2. StartTLS応答
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、0.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応答を成功に返します。 うまくいっているStartTLS応答のクライアント領収書で、プロトコル同輩はTLS交渉と共に[RFC4513]のセクション3で議論するように始まるかもしれません。
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層なしで残されます。
4.14.3. Removal of the TLS Layer
4.14.3. 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 PDUsを送る前にもう片方の同輩から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 PDUsを送って、受けるかもしれません。
Sermersheim Standards Track [Page 41] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[41ページ]RFC4511LDAPv3 June 2006
Protocol peers MAY terminate the LDAP session after sending or receiving a TLS closure alert.
TLS閉鎖警戒を送るか、または受けた後に、プロトコル同輩はLDAPセッションを終えるかもしれません。
5. Protocol Encoding, Connection, and Transfer
5. プロトコルコード化、接続、および転送
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.
1つの基本的なサービス(TCPの上のLDAP)がセクション5.2で定義されます。 一般に、このサービスはインターネットでX.500ベースのディレクトリサービスを提供するか、または消費するアプリケーションに適用されます。 一般に、この仕様は念頭にTCPマッピングで書かれました。 他のマッピングを詳しく述べる仕様は様々な障害にぶつかるかもしれません。
Implementations of LDAP over TCP MUST implement the mapping as described in Section 5.2.
TCP MUSTの上のLDAPの実装はセクション5.2で説明されるようにマッピングを実装します。
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 |
+----------------------+
+----------------------+ | LDAPメッセージ層| +----------------------+ >LDAP PDUs+----------------------+ <データ| SASL層| +----------------------+ >はデータ+をSASL保護しました。----------------------+ <データ| TLS層| アプリケーション+----------------------+ >はデータをTLS保護しました。------------+----------------------+ <データTransport| 輸送接続| +----------------------+
5.1. Protocol Encoding
5.1. プロトコルコード化
The protocol elements of LDAP SHALL be encoded for exchange using the Basic Encoding Rules [BER] of [ASN.1] with the following restrictions:
要素について議定書の中で述べてください。LDAP SHALLでは、交換には、以下の制限と共に[ASN.1]のBasic Encoding Rules[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".
- ブールタイプの値が本当であるなら、値の八重奏のコード化は十六進法「ff」に設定されます。
Sermersheim Standards Track [Page 42] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[42ページ]RFC4511LDAPv3 June 2006
- 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.
- タイプの値がデフォルト値であるなら、欠けています。 ブールと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.
これらの制限は中でカプセル化されたOCTET STRING値のASN.1タイプに適用されません、属性値などのように、別の方法で述べられない場合。
5.2. Transmission Control Protocol (TCP)
5.2. 通信制御プロトコル(TCP)
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 PDUsは、セクション5.1で説明されたBERベースのコード化を使用することで直接TCP[RFC793]bytestreamに写像されます。 TCPをひくサーバ実装がLDAPポートが割り当てられたAssigned民数記Authority(IANA)、389[PortReg]のインターネットでプロトコルリスナーを提供するのは、お勧めです。 サーバは代わりに異なったポートナンバーでリスナーを提供するかもしれません。 クライアントは、どんな有効なTCPポートの上でも連絡がサーバであるとサポートしなければなりません。
5.3. Termination of the LDAP session
5.3. LDAPセッションの終了
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.
UnbindRequestを送るクライアント(セクション4.3)、またはDisconnectionのNoticeを送るサーバ(セクション4.4.1)によってLDAPセッションの終了は通常開始されます。 これらの場合では、それぞれのプロトコル同輩は優雅にLDAPメッセージ層で交換をやめることによって、LDAPセッションを終えます、どんなSASL層も取りこわして、どんなTLS層も取りこわして、輸送接続を終えて。
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で指定されるように扱われます。
6. Security Considerations
6. セキュリティ問題
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.
プロトコルのこのバージョンは簡易認証のためにcleartextパスワードを使用することで便宜を与えます、どんなSASL[RFC4422]メカニズムと同様に。 SASL、そして/または、TLS層をインストールすると、保全と他のデータ機密保護にサービスを提供できます。
It is also permitted that the server can return its credentials to the client, if it chooses to do so.
また、受入れられて、それが、そうするのを選ぶなら、サーバが資格証明書をクライアントに返すことができるのは、そうです。
Sermersheim Standards Track [Page 43] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[43ページ]RFC4511LDAPv3 June 2006
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.
cleartextパスワードの使用は基本的な輸送サービスが秘密性を保証できないで、パスワードの公開をもたらすかもしれないところで強く権限のないパーティーにお勧めできないです。
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認証交換がBindResponseのバージョン、BindRequestの名前欄、resultCode、diagnosticMessage、または紹介分野と、Bind要求に取り付けられたコントロールに含まれたどんな情報か応答のためのデータの機密性か保全保護も提供しないことに注意してください。 その結果、情報はこれらの分野にSHOULD NOTを保管していました。それが保護されていた状態で(トランスポート層で保護を確立などなどの)そうでなくない場合、当てにされてください。
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.
いくつかの場合、セキュリティ要素変化の観点からさえ操作を続けているのは適切であるかもしれません。 例えば、変化にかかわらずAbandon操作を続けているか、または変化がセキュリティ要素をアップグレードさせたときの(または、維持されます)操作を続けているのが適切であるかもしれません。 他の場合では、操作の処理を失敗するか、または変更するのが適切であるかもしれません。 または、例えば、秘密の保護を取り除くなら、極秘データを返すという要求に失敗するのが適切である、最少量で、極秘データの復帰を除くために。
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 MUSTを通して得た実装は、その情報が複数のクライアントに提供することであるならアクセス制御を維持するのを確実にします、サーバには特定の認証されたクライアントを除いて、検索結果におけるエントリーか属性の復帰を防ぐアクセス制御方針があるかもしれないので。 例えば、キャッシュはキャッシュにはそれが要求であったクライアントだけに結果情報をサービスするかもしれません。
Sermersheim Standards Track [Page 44] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[44ページ]RFC4511LDAPv3 June 2006
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.
プロトコル同輩は無効の、そして、任意の長さのプロトコルencodingsを扱う用意ができていなければなりません。 無効のプロトコルencodingsは: 例外をコード化する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.
プロトコル同輩がさらなるコミュニケーションのためLDAPセッションのときにどんな層でも自然で損害を与えることができた攻撃を感じる場合、プロトコル同輩はセクション5.3で説明されるように突然にLDAPセッションを終えるべきです。
7. Acknowledgements
7. 承認
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によってRFC2251に基礎づけられています。 RFC2251は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.
また、それはRFC2830に基づいています。 RFC2830は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によってRFC3771に基礎づけられています。 RFC3771は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、スティーブンLegg、およびHallvard Furusethを入れます。
Sermersheim Standards Track [Page 45] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[45ページ]RFC4511LDAPv3 June 2006
8. Normative References
8. 引用規格
[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/IEC8824- 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 Rec。 X.690(07/2002)| ISO/IEC8825-1: 2002 「情報技術--ASN.1コード化は以下を統治します」。 「基本的な符号化規則(BER)、正準な符号化規則(CER)、および顕著な符号化規則(DER)の仕様」、2002。
[ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
Architecture and Basic Multilingual Plane, ISO/IEC
10646-1 : 1993.
[ISO10646]普遍的な複数の八重奏コード化文字集合(UCS)--アーキテクチャと基本多言語水準、ISO/IEC10646-1: 1993.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3454] Hoffman P. and M. Blanchet, "Preparation of
Internationalized Strings ('stringprep')", RFC 3454,
December 2002.
[RFC3454] ホフマンP.とM.Blanchet、「国際化しているストリング('stringprep')の準備」、RFC3454、2002年12月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau、F.、「UTF-8、ISO10646の変換形式」STD63、RFC3629、11月2003日
[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、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、STD66、RFC3986、2005年1月。
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User
Names and Passwords", RFC 4013, February 2005.
[RFC4013]Zeilenga、K.、「SASLprep:」 「ユーザ名とパスワードのためのStringprepプロフィール」、RFC4013、2005年2月。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC4234] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
[RFC4346] Dierks, T. and E. Rescorla, "The TLS Protocol Version
1.1", RFC 4346, March 2006.
[RFC4346] Dierks、T.、およびE.レスコラ、「TLSは2006年3月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
Authentication and Security Layer (SASL)", RFC 4422,
June 2006.
エド[RFC4422]メリニコフ、A.、K.Zeilenga、エド、「簡易認証とセキュリティは(SASL)を層にする」RFC4422、6月2006日
Sermersheim Standards Track [Page 46] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[46ページ]RFC4511LDAPv3 June 2006
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
Protocol (LDAP): Technical Specification Road Map", RFC
4510, June 2006.
[RFC4510] Zeilenga、K.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「仕様書ロードマップ」、RFC4510、2006年6月。
[RFC4512] Zeilenga, K., Lightweight Directory Access Protocol
(LDAP): Directory Information Models", RFC 4512, June
2006.
[RFC4512]Zeilenga、K.、ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP): 「ディレクトリ情報モデル」、RFC4512、2006年6月。
[RFC4513] Harrison, R., Ed., "Lightweight Directory Access
Protocol (LDAP): Authentication Methods and Security
Mechanisms", RFC 4513, June 2006.
[RFC4513] ハリソン、R.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「認証方法とセキュリティー対策」、RFC4513、6月2006日
[RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access
Protocol (LDAP): String Representation of Distinguished
Names", RFC 4514, June 2006.
[RFC4514] Zeilenga、K.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「分類名のストリング表現」、RFC4514、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)について議定書の中で述べます」。 「Uniform Resource Locator」、RFC4516、2006年6月。
[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
(LDAP): Syntaxes and Matching Rules", RFC 4517, June
2006.
[RFC4517] Legg、S.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「構文とマッチングは統治する」RFC4517、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.、「インターネットはライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)のために数の権威(IANA)に問題を割り当てました」、BCP64、RFC4520、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/).
[ユニコード] ユニコードConsortium、「ユニコード規格、バージョン、3.2、0インチ、定義される、「ユニコード規格、修正されるバージョン3インチ(読書、MA、アディソン-ウエスリー、2000ISBN0-201- 61633-5)、「ユニコード規格別館#27:」 「ユニコード規格別館#28:」 ユニコード3.2インチ( http://www.unicode.org/reports/tr28/ )。
[X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
Models and Service", 1993.
[X.500]ITU-T Rec。 X.500、「ディレクトリ:」 「概念の、そして、モデルの、そして、サービスの概要」、1993。
[X.511] ITU-T Rec. X.511, "The Directory: Abstract Service
Definition", 1993.
[X.511]ITU-T Rec。 X.511、「ディレクトリ:」 「抽象的なサービス定義」、1993。
Sermersheim Standards Track [Page 47] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[47ページ]RFC4511LDAPv3 June 2006
9. Informative References
9. 有益な参照
[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.デイヴィス、「ユニコード技術報告書#17、文字符号化モデル」、UTR17、<は://www.unicode.org/unicode/reports/tr17/>をhttpして、8月は2000です。
[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/課題/ポートナンバー>。
[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/>。
10. IANA Considerations
10. IANA問題
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).
インターネットAssigned民数記Authority(IANA)はこのドキュメントが結果コード0-36のための決定的な技術仕様書を提供するのを示すためにLDAP結果コード登録をアップデートしました、48-54、64- 70、80-90。 また、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に、決定的な技術仕様書を提供するのを示すためにLDAPプロトコルMechanism登録をアップデートした、(1.3 .6 .1 .4 .1 .1466 .20037) 拡大手術。
IANA has assigned LDAP Object Identifier 18 [RFC4520] to identify the ASN.1 module defined in this document.
IANAは、本書では定義されたASN.1モジュールを特定するために、LDAP Object Identifier18[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
Subject: 詳細のために連絡するLDAP Object Identifier Registration PersonとEメールアドレスのために以下を要求してください。 ジム Sermersheim <jimse@novell.com 、gt;、仕様: RFC4511作者/変化コントローラ: IESGはコメントします: LDAP ASN.1モジュールを特定します。
Sermersheim Standards Track [Page 48] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[48ページ]RFC4511LDAPv3 June 2006
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]で定義されるかもしれません。 クライアント実装SHALLは彼らが未知のエラー条件として認識しない少しの結果コードも扱います。
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).
成功(0)、compareFalse(5)、compareTrue(6)、紹介(10)、および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)は操作の無事終了を示します。 以下に注意してください。 このコードはCompare操作と共に使用されません。 compareFalse(5)とcompareTrue(6)を見てください。
Sermersheim Standards Track [Page 49] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[49ページ]RFC4511LDAPv3 June 2006
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.
例えば、他の未完成の操作がありますが、クライアントが[RFC4346]をStartTLSに試みるか、またはTLS層が既にインストールされたなら、このコードは返されます。
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.
また、Bind操作だけにおいて、このコードは、サーバが要求されたプロトコルバージョンをサポートしないのを示すのに使用されます。
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.
また、Extended操作だけにおいて、このコードは、サーバが、Extendedが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.
FALSEかUndefinedに評価されて、compareFalse(5)は、操作が首尾よく終了したCompareと主張がそうしたのを示します。
compareTrue (6)
Indicates that the Compare operation has successfully
completed and the assertion has evaluated to TRUE.
TRUEに評価されて、compareTrue(6)は、操作が首尾よく終了したCompareと主張がそうしたのを示します。
authMethodNotSupported (7)
Indicates that the authentication method or mechanism is not
supported.
authMethodNotSupported(7)は、認証方法かメカニズムがサポートされないのを示します。
Sermersheim Standards Track [Page 50] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[50ページ]RFC4511LDAPv3 June 2006
strongerAuthRequired (8)
Indicates the server requires strong(er) authentication in
order to complete the operation.
strongerAuthRequired(8)は、サーバが操作を完了するために強い(えー)認証を必要とするのを示します。
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.
DisconnectionのNoticeと共に使用されて、操作、このコードが、サーバがそれを検出したのを示すと、クライアントとサーバとの設立されたセキュリティ仲間は、不意に失敗されるか、または感染されました。
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)は、認証過程を続けるためにサーバが、クライアントが同じSASLメカニズムによる新しいひもの要求を送るのを必要とするのを示します(セクション4.2を見てください)。
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.
SINGLE-VALUE規制を持っている属性に複数の値を供給するとき、例えば、このコードを返します。
Sermersheim Standards Track [Page 51] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[51ページ]RFC4511LDAPv3 June 2006
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分野(例えば、検索ベース、目標エントリー、ModifyDN 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)は、サーバが操作を修理できないくらい忙しいのを示します。
Sermersheim Standards Track [Page 52] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[52ページ]RFC4511LDAPv3 June 2006
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)は、エントリーの'objectClass'属性のオブジェクトのクラス(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)は、複数のサーバ(DSAs)に影響するように操作を実行できないのを示します。
other (80)
Indicates the server has encountered an internal error.
他の(80)は、サーバが内部エラーに遭遇したのを示します。
Sermersheim Standards Track [Page 53] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[53ページ]RFC4511LDAPv3 June 2006
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 ::=
ライト級ディレクトリアクセスプロトコルV3、1 3 6 1 1、18、--Copyright(C)インターネット協会(2006)。 このバージョン、--このASN.1モジュールはRFC4511の一部です。 完全な法定の通知に関してRFC自身を見てください。 暗黙のタグ伸展性が含意した定義:、:=
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 }
LDAPMessage:、:= 系列{ messageID MessageID; protocolOp選択; { 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; } , コントロール0Controls OPTIONAL; }
MessageID ::= INTEGER (0 .. maxInt)
MessageID:、:= 整数(0maxInt)
maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
maxInt整数:、:= 2147483647 -- (2^^31 - 1) --
LDAPString ::= OCTET STRING -- UTF-8 encoded,
-- [ISO10646] characters
LDAPString:、:= OCTET STRING--コード化されたUTF-8--[ISO10646]キャラクタ
Sermersheim Standards Track [Page 54] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[54ページ]RFC4511LDAPv3 June 2006
LDAPOID ::= OCTET STRING -- Constrained to <numericoid>
-- [RFC4512]
LDAPOID:、:= 八重奏ストリング--<numericoid>に抑制されます--[RFC4512]
LDAPDN ::= LDAPString -- Constrained to <distinguishedName>
-- [RFC4514]
LDAPDN:、:= LDAPString--<distinguishedName>に抑制されます--[RFC4514]
RelativeLDAPDN ::= LDAPString -- Constrained to <name-component>
-- [RFC4514]
RelativeLDAPDN:、:= LDAPString--<名コンポーネントに>を抑制します--[RFC4514]
AttributeDescription ::= LDAPString
-- Constrained to <attributedescription>
-- [RFC4512]
AttributeDescription:、:= LDAPString--<attributedescription>に抑制されます--[RFC4512]
AttributeValue ::= OCTET STRING
AttributeValue:、:= 八重奏ストリング
AttributeValueAssertion ::= SEQUENCE {
attributeDesc AttributeDescription,
assertionValue AssertionValue }
AttributeValueAssertion:、:= 系列attributeDesc AttributeDescription、assertionValue AssertionValue
AssertionValue ::= OCTET STRING
AssertionValue:、:= 八重奏ストリング
PartialAttribute ::= SEQUENCE {
type AttributeDescription,
vals SET OF value AttributeValue }
PartialAttribute:、:= 系列AttributeDescription、vals SET OF値のAttributeValueをタイプしてください。
Attribute ::= PartialAttribute(WITH COMPONENTS {
...,
vals (SIZE(1..MAX))})
以下を結果と考えてください:= PartialAttribute(WITH COMPONENTS、…、vals(SIZE(1..MAX)))
MatchingRuleId ::= LDAPString
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),
LDAPResult:、:= SEQUENCE、resultCode ENUMERATED、成功(0)、operationsError(1)、protocolError(2)、timeLimitExceeded(3)、sizeLimitExceeded(4)、compareFalse(5)、compareTrue(6)、authMethodNotSupported(7)、strongerAuthRequired(8)--予約された9--紹介(10)、adminLimitExceeded(11)、unavailableCriticalExtension(12)、confidentialityRequired(13)、saslBindInProgress(14)
Sermersheim Standards Track [Page 55] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[55ページ]RFC4511LDAPv3 June 2006
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 }
noSuchAttribute(16)、undefinedAttributeType(17)、inappropriateMatching(18)、constraintViolation(19)、attributeOrValueExists(20)、invalidAttributeSyntax(21)--22-31 未使用(noSuchObject(32)、aliasProblem(33)、invalidDNSyntax(34))の35は未定義のisLeaf(aliasDereferencingProblem(36))のために未使用で37-47を予約しました; inappropriateAuthentication(48)、invalidCredentials(49)、insufficientAccessRights(50)、忙しい(51)、入手できない(52)unwillingToPerform(53)、loopDetect(54)--55-63 未使用(namingViolation(64)、objectClassViolation(65)、notAllowedOnNonLeaf(66)、notAllowedOnRDN(67)、entryAlreadyExists(68)、objectClassModsProhibited(69))の70はCLDAP(affectsMultipleDSAs(71))のために未使用で72-79を予約しました--他の(80) matchedDN LDAPDN、diagnosticMessage LDAPString、紹介[3]紹介OPTIONAL
Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
紹介:、:= SEQUENCE SIZE(1..MAX)OF uri URI
URI ::= LDAPString -- limited to characters permitted in
-- URIs
URI:、:= LDAPString(受入れられたキャラクタに制限される)、URI
Controls ::= SEQUENCE OF control Control
コントロール:、:= SEQUENCE OFコントロールControl
Control ::= SEQUENCE {
controlType LDAPOID,
criticality BOOLEAN DEFAULT FALSE,
controlValue OCTET STRING OPTIONAL }
以下を制御してください:= 系列controlType LDAPOID、臨界BOOLEAN DEFAULT FALSE、controlValue OCTET STRING OPTIONAL
Sermersheim Standards Track [Page 56] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[56ページ]RFC4511LDAPv3 June 2006
BindRequest ::= [APPLICATION 0] SEQUENCE {
version INTEGER (1 .. 127),
name LDAPDN,
authentication AuthenticationChoice }
BindRequest:、:= [アプリケーション0] 系列バージョンINTEGER、(1 .127) 名前LDAPDN、認証AuthenticationChoice
AuthenticationChoice ::= CHOICE {
simple [0] OCTET STRING,
-- 1 and 2 reserved
sasl [3] SaslCredentials,
... }
AuthenticationChoice:、:= 選択簡単な[0]OCTET STRING(1と2予約されたsasl[3]SaslCredentials)
SaslCredentials ::= SEQUENCE {
mechanism LDAPString,
credentials OCTET STRING OPTIONAL }
SaslCredentials:、:= 系列メカニズムLDAPString、資格証明書OCTET STRING OPTIONAL
BindResponse ::= [APPLICATION 1] SEQUENCE {
COMPONENTS OF LDAPResult,
serverSaslCreds [7] OCTET STRING OPTIONAL }
BindResponse:、:= [アプリケーション1] 系列LDAPResultの部品、serverSaslCreds[7]八重奏ストリング、任意
UnbindRequest ::= [APPLICATION 2] NULL
UnbindRequest:、:= [アプリケーション2] ヌル
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 }
SearchRequest:、:= [アプリケーション3] 系列baseObject LDAPDN、範囲ENUMERATED、baseObject(0)、singleLevel(1)、wholeSubtree(2)、…、derefAliases ENUMERATED、neverDerefAliases(0)、derefInSearching(1)、derefFindingBaseObj(2)、derefAlways(3)、sizeLimit INTEGER(0maxInt)、typesOnlyブールであるtimeLimit INTEGER(0maxInt)はFilterをフィルターにかけます、属性AttributeSelection
AttributeSelection ::= SEQUENCE OF selector LDAPString
-- The LDAPString is constrained to
-- <attributeSelector> in Section 4.5.1.8
AttributeSelection:、:= SEQUENCE OFセレクタLDAPString--抑制されたLDAPString--<attributeSelector>コネセクション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,
以下をフィルターにかけてください:= CHOICE、[0] SET SIZE(1..MAX)OFは[2]フィルタ、equalityMatch[3]AttributeValueAssertionではなく、Filter、または[1]SET SIZE(1..MAX)OFフィルタFilterをフィルターにかけます。
Sermersheim Standards Track [Page 57] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[57ページ]RFC4511LDAPv3 June 2006
substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion,
present [7] AttributeDescription,
approxMatch [8] AttributeValueAssertion,
extensibleMatch [9] MatchingRuleAssertion,
... }
サブストリング[4]SubstringFilter(greaterOrEqual[5]AttributeValueAssertion、lessOrEqual[6]AttributeValueAssertion)は[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
}
SubstringFilter:、:= 系列タイプAttributeDescription、サブストリングSEQUENCE SIZE(1..MAX)OFサブストリングCHOICEは[0] AssertionValue--[1] 一度だいたいのいずれもAssertionValueに起こることができる決勝[2]AssertionValueに頭文字をつけます--高々一度起こることができます。
MatchingRuleAssertion ::= SEQUENCE {
matchingRule [1] MatchingRuleId OPTIONAL,
type [2] AttributeDescription OPTIONAL,
matchValue [3] AssertionValue,
dnAttributes [4] BOOLEAN DEFAULT FALSE }
MatchingRuleAssertion:、:= 系列matchingRule[1]MatchingRuleId OPTIONAL、タイプ[2]AttributeDescription OPTIONAL、matchValue[3]AssertionValue、dnAttributes[4]BOOLEAN DEFAULT FALSE
SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
objectName LDAPDN,
attributes PartialAttributeList }
SearchResultEntry:、:= [アプリケーション4] 系列objectName LDAPDN、属性PartialAttributeList
PartialAttributeList ::= SEQUENCE OF
partialAttribute PartialAttribute
PartialAttributeList:、:= partialAttribute PartialAttributeの系列
SearchResultReference ::= [APPLICATION 19] SEQUENCE
SIZE (1..MAX) OF uri URI
SearchResultReference:、:= [APPLICATION19] SEQUENCE SIZE(1..MAX)OF uri URI
SearchResultDone ::= [APPLICATION 5] LDAPResult
SearchResultDone:、:= [アプリケーション5] LDAPResult
ModifyRequest ::= [APPLICATION 6] SEQUENCE {
object LDAPDN,
changes SEQUENCE OF change SEQUENCE {
operation ENUMERATED {
add (0),
delete (1),
replace (2),
... },
modification PartialAttribute } }
ModifyRequest:、:= [アプリケーション6] 系列オブジェクトLDAPDN、変化SEQUENCE OFがSEQUENCEを変える、操作ENUMERATEDは(0) (1)を削除するように言い足して、(2)、…を取り替えます、変更PartialAttribute
ModifyResponse ::= [APPLICATION 7] LDAPResult
ModifyResponse:、:= [アプリケーション7] LDAPResult
Sermersheim Standards Track [Page 58] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[58ページ]RFC4511LDAPv3 June 2006
AddRequest ::= [APPLICATION 8] SEQUENCE {
entry LDAPDN,
attributes AttributeList }
AddRequest:、:= [アプリケーション8] 系列エントリーLDAPDN、属性AttributeList
AttributeList ::= SEQUENCE OF attribute Attribute
AttributeList:、:= SEQUENCE OF属性Attribute
AddResponse ::= [APPLICATION 9] LDAPResult
AddResponse:、:= [アプリケーション9] LDAPResult
DelRequest ::= [APPLICATION 10] LDAPDN
DelRequest:、:= [アプリケーション10] LDAPDN
DelResponse ::= [APPLICATION 11] LDAPResult
DelResponse:、:= [アプリケーション11] LDAPResult
ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
entry LDAPDN,
newrdn RelativeLDAPDN,
deleteoldrdn BOOLEAN,
newSuperior [0] LDAPDN OPTIONAL }
ModifyDNRequest:、:= [アプリケーション12] 系列エントリーLDAPDN、newrdn RelativeLDAPDN、ブールdeleteoldrdn newSuperior[0]LDAPDN OPTIONAL
ModifyDNResponse ::= [APPLICATION 13] LDAPResult
ModifyDNResponse:、:= [アプリケーション13] LDAPResult
CompareRequest ::= [APPLICATION 14] SEQUENCE {
entry LDAPDN,
ava AttributeValueAssertion }
CompareRequest:、:= [アプリケーション14] 系列エントリーLDAPDN、ava AttributeValueAssertion
CompareResponse ::= [APPLICATION 15] LDAPResult
CompareResponse:、:= [アプリケーション15] LDAPResult
AbandonRequest ::= [APPLICATION 16] MessageID
AbandonRequest:、:= [アプリケーション16] MessageID
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING OPTIONAL }
ExtendedRequest:、:= [アプリケーション23] 系列requestName[0]LDAPOIDで、requestValue[1]八重奏ストリング任意です。
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS OF LDAPResult,
responseName [10] LDAPOID OPTIONAL,
responseValue [11] OCTET STRING OPTIONAL }
ExtendedResponse:、:= [アプリケーション24] 系列LDAPResult、任意のresponseName[10]LDAPOID responseValue[11]八重奏ストリングの部品、任意
IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
responseName [0] LDAPOID OPTIONAL,
responseValue [1] OCTET STRING OPTIONAL }
IntermediateResponse:、:= [アプリケーション25] 系列任意であって、responseValue[1]八重奏ストリング任意の状態で[0] LDAPOIDをresponseNameします。
END
終わり
Sermersheim Standards Track [Page 59] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[59ページ]RFC4511LDAPv3 June 2006
Appendix C. Changes
付録C.変化
This appendix is non-normative.
この付録は非規範的です。
This appendix summarizes substantive changes made to RFC 2251, RFC 2830, and RFC 3771.
この付録はRFC2251、RFC2830、およびRFC3771にされた実質的な変更をまとめます。
C.1. Changes Made to RFC 2251
C.1。 RFC2251にされた変更
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、およびRFC2251の残りにされた実質的な変更をまとめます。 読者は他のセクションへの変化の概要のために[RFC4512]と[RFC4513]に相談するべきです。
C.1.1. Section 1 (Status of this Memo)
C.1.1。 セクション1(このMemoの状態)
- 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注意を取り除きました。 RFC2251の公表を掲示してください、そして、この注意を取り除くために十分な義務的なLDAP認証機構は標準化されました。 認証機構に関して[RFC4513]を見てください。
C.1.2. Section 3.1 (Protocol Model) and others
C.1.2。 セクション3.1(プロトコルモデル)と他のもの
- 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. Section 4 (Elements of Protocol)
C.1.3。 セクション4(プロトコルのElements)
- 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. Section 4.1.1 (Message Envelope)
C.1.4。 セクション4.1 .1(メッセージ封筒)
- 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が、ある方法で奇形であるときに、サーバがDisconnectionのNoticeを返して、輸送接続を下げるという義務的な要件がありました。 サーバSHOULDはこれをアップデートしたので、DisconnectionのNoticeを返します、そして、それはLDAP Sessionを終えなければなりません。
C.1.5. Section 4.1.1.1 (Message ID)
C.1.5。 セクション4.1 .1 .1(Message ID)
- Required that the messageID of requests MUST be non-zero as the
zero is reserved for Notice of Disconnection.
- ゼロがDisconnectionのNoticeのために予約されるとき要求のmessageIDが非ゼロであるに違いないことが必要でした。
Sermersheim Standards Track [Page 60] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[60ページ]RFC4511LDAPv3 June 2006
- 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.
- 既に使用されたmessageIDを返すのが適切な状態でいつ、それはあって、ないかを指定しました。 RFC2251は偶然この言葉遣いにおける同期サーバーの振舞いを課しました。
C.1.6. Section 4.1.2 (String Types)
C.1.6。 セクション4.1 .2(ストリングタイプ)
- Stated that LDAPOID is constrained to <numericoid> from [RFC4512].
- LDAPOIDが[RFC4512]から<numericoid>に抑制されると述べました。
C.1.7. Section 4.1.5.1 (Binary Option) and others
C.1.7。 セクション4.1.5人の.1(2進のオプション)と他のもの
- 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.
- 仕様からBinary Optionを取り外しました。 代替の属性タイプコード化のこのメソッドに関連している多数の相互運用性問題があります。 適当な交換を指定する仕事は進行中です。
C.1.8. Section 4.1.8 (Attribute)
C.1.8。 セクション4.1 .8(属性)
- Combined the definitions of PartialAttribute and Attribute here,
and defined Attribute in terms of PartialAttribute.
- ここでPartialAttributeとAttributeの定義を結合して、PartialAttributeに関してAttributeを定義しました。
C.1.9. Section 4.1.10 (Result Message)
C.1.9。 セクション4.1 .10(結果メッセージ)
- 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"は非誤り結果のために送ることができます。 - 何らかの言語をAppendix Aに動かして、そこで読者を差し向けました。 - それら以外の結果コードのために存在している許容matchedDNはRFC2251に記載しました。 - はっきりさせるこのコードが、より強い認証が与えられた操作を実行するのに必要であることを示すためにしばしば返されるかもしれない"strongerAuthRequired"への"strongAuthRequired"にコードを改名しました。
C.1.10. Section 4.1.11 (Referral)
C.1.10。 セクション4.1 .11(紹介)
- 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.
- URLよりむしろURIに関して紹介を定義しました。 - すべての紹介URIが等しく操作の進歩をすることができなければならないという要件を取り除きました。 声明は、あいまいであり、どうそれを行うかに関する指示を全く提供しませんでした。 - クライアントがサーバの間で輪にしてはいけないという要件を加えました。 - 紹介にLDAPURLsを使用するための指示をはっきりさせて、そうする際に範囲の一部が存在しているという推薦を加えました。 - クライアントが操作を進行する特定の方法でURLを使用するのを必要とした命令を取り除きました。 これらは相互運用性のために何もしませんでした。
Sermersheim Standards Track [Page 61] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[61ページ]RFC4511LDAPv3 June 2006
C.1.11. Section 4.1.12 (Controls)
C.1.11。 セクション4.1 .12(コントロール)
- 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. Section 4.2 (Bind Operation)
C.1.12。 セクション4.2(ひもの操作)
- 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を返すのを強制しました。 - 簡易認証が使用されていて、名前が空であり、パスワードが非空であるときに、振舞いのあいまいさを除きました。 - Bindのための反参照別名でないことへの必要なサーバ。 これは、他の操作がある一貫性、データの一貫性を確実にするのを助けるために加えられました。 - UTF-8がユニコードをコード化したので原文のパスワードがわたっているのが必要であり、ストリング準備のときに推薦を言い足しました。 これは、異なったクライアントから送られるパスワードの相互運用性を確実にするのを助けるためのものでした。
C.1.13. Section 4.2.1 (Sequencing of the Bind Request)
C.1.13。 セクション4.2 .1(ひもの要求の配列)
- 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].
- このセクションは読み易さのために主に再編成されました、そして、言語は、失敗して捨てられたBind操作の認証状態をはっきりさせるために加えられました。 - 取り除かれる: 「SASL転送暗号化か保全メカニズムが交渉されたなら、そのメカニズムは資格証明書の1つのアイデンティティから別のアイデンティティまでの変化をサポートしないで、次に、クライアントは代わりに新しい接続を確立しなければなりません。」 特定のSASLメカニズムの複数の交渉の間には、依存があれば、そのSASLメカニズムのための技術仕様書はそれらに対処するアプリケーションがことである方法を詳しく述べます。 LDAPは少しの特別な取り扱いも必要とするはずがありません。 - 下げられて、必須のコネは、[RFC2119]に並ぶために3について短い記事を書かなければなりませんか?
Sermersheim Standards Track [Page 62] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[62ページ]RFC4511LDAPv3 June 2006
- 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.
- Bindが進行していますが、クライアントが非ひもの操作を送らないのを強制して、それらが受け取られているなら、サーバがそれらを処理しないのを示しました。 これが、他の操作との関係における、Bindの適切な配列を確実にするのに必要です。
C.1.14. Section 4.2.3 (Bind Response)
C.1.14。 セクション4.2 .3(ひもの応答)
- 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.
- 誤り最も関連のテキストをAppendix Aに動かして、Bind操作に関連して使用されるある誤りに関するテキストを加えました。 - 適切でないときにserverSaslCredsを指定するのからサーバを禁じました。
C.1.15. Section 4.3 (Unbind Operation)
C.1.15。 セクション4.3(操作を解きます)
- Specified that both peers are to cease transmission and terminate
the LDAP session for the Unbind operation.
- 両方の同輩がトランスミッションをやめて、Unbind操作のためのLDAPセッションを終えることになっていると指定しました。
C.1.16. Section 4.4 (Unsolicited Notification)
C.1.16。 セクション4.4(求められていない通知)
- Added instructions for future specifications of Unsolicited
Notifications.
- Unsolicited Notificationsの将来の仕様のための指示を加えました。
C.1.17. Section 4.5.1 (Search Request)
C.1.17。 セクション4.5 .1(検索要求)
- 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.
- 現在AttributeDescriptionListよりむしろAttributeSelectionタイプとSearchRequest属性を定義します、そして、ABNFを提供します。 - SearchRequest属性は写し属性記述を含むかもしれません。 これは以前に、禁止されました。 現在、それらがコピーされたらサーバがその後の名前を無視するよう命令されます。 これは、異なった省略名とOIDsも属性のために要求されているのを許容するためにリラックスしました。 - 現在の検索フィルタは、現在、指定された属性がいつサーバに知られていないかをUndefinedに評価します。それは、以前はよく'not'オペレータが特にいつ使用されたかをFALSEに評価していました。(FALSEは大部分が予想することに反している振舞いを引き起こしました)。 - Filterの特選しているSubstringFilterサブストリングタイプは現在、1の下界によって定義されます。 - 'サブストリングが'頭文字をつける'SubstringFilter、どんな'現在、最終的な'タイプはLDAPStringよりむしろAssertionValueです'。 また、最初に'初期'で(存在しているなら)それを述べる加えられた命令を記載しなければなりません、そして、最後に'決勝'(存在しているなら)を記載しなければなりません。 - derefAliases選択の意味論のあいまいさを除きました。 derefInSearchingがwholeSubtree検索でベースオブジェクトに適用したかどうかに関して質問がありました。 - equalityMatch、サブストリング、greaterOrEqual、lessOrEqual、およびapproxMatchのために指示を加えました。
Sermersheim Standards Track [Page 63] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[63ページ]RFC4511LDAPv3 June 2006
C.1.18. Section 4.5.2 (Search Result)
C.1.18。 セクション4.5 .2(検索結果)
- 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. Section 4.5.3 (Continuation References in the Search Result)
C.1.19。 セクション4.5 .3(検索結果における継続参照)
- Made changes similar to those made to Section 4.1.11.
- セクション4.1.11まで作られたものと同様の人工の変化。
C.1.20. Section 4.5.3.1 (Example)
C.1.20。 セクション4.5 .3 .1(例)
- Fixed examples to adhere to changes made to Section 4.5.3.
- セクション4.5.3まで行われた変更を固守する固定例。
C.1.21. Section 4.6 (Modify Operation)
C.1.21。 セクション4.6(操作を変更します)
- 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をAttributeに取り替えました。 - 一時図式に違反するかもしれない変更変化のタイプを指定しました。 どんな一時的な図式違反も許されたという印象でいた読者もいました。
C.1.22. Section 4.7 (Add Operation)
C.1.22。 セクション4.7(操作を加えます)
- 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の属性がエントリーを作成するのに記載された属性に関連して使用されるので、Add操作をX.511に一直線にしました。 以前、Addは、顕著な値が記載された属性で存在しているのを必要としました。 - 何人かのDSEタイプがこの属性を必要としないので指定されていて、objectClassが結果と考える取り除かれた要件はそうしなければなりません。 副出記入がデータモデルを固く守るのが必要であることで、代わりに、ジェネリック言葉遣いは加えられました。 - オブジェクトのプレースメントに関して推薦を取り除きました。 これはデータモデルドキュメントでカバーされています。
C.1.23. Section 4.9 (Modify DN Operation)
C.1.23。 セクション4.9(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.
- Modify DNのための反参照別名でないことへの必要なサーバ。 これは、他の操作がある一貫性、データの一貫性を確実にするのを助けるために加えられました。 - 文脈を命名するとき移行するときにはModify DNは失敗されてください。 - newrdnの属性がエントリーのときに存在していないとき、何が起こるかを指定しました。
Sermersheim Standards Track [Page 64] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[64ページ]RFC4511LDAPv3 June 2006
C.1.24. Section 4.10 (Compare Operation)
C.1.24。 セクション4.10(操作を比較します)
- 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がCompareが行われて、結果が誤っていることを意味すると指定しました。 人々が、UndefinedマッチがcompareFalseをもたらすと信じているように導いた混乱がありました。 - Compareのための反参照別名でないことへの必要なサーバ。 これは、他の操作がある一貫性、データの一貫性を確実にするのを助けるために加えられました。
C.1.25. Section 4.11 (Abandon Operation)
C.1.25。 セクション4.11(放棄操作)
- 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.
- 彼らが、結果を知る必要があるならAbandonが応答を全く返さないのでクライアントがそれを使用するべきでないと説明しました。 - AbandonとUnbindを捨てることができないと指定しました。
C.1.26. Section 4.12 (Extended Operation)
C.1.26。 セクション4.12(拡大手術)
- 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に関して定義されたExtended操作の値がことである方法を指定しました。 - 仕様がどんなExtended操作に成るかに関して指示を加えました。 - サーバが広告を出すという推薦がExtendedに操作をサポートしたと言い足しました。
C.1.27. Section 5.2 (Transfer Protocols)
C.1.27。 セクション5.2(転送プロトコル)
- Moved referral-specific instructions into referral-related
sections.
- 紹介特有の指示を紹介関連のセクションに動かしました。
C.1.28. Section 7 (Security Considerations)
C.1.28。 セクション7(セキュリティ問題)
- 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 Bindメッセージのある一定の局面を保護しないSASLに関する注を言い換えました。 - Serversが匿名で[RFC4513]を認証したクライアントによるディレクトリ変更を防ぐよう奨励されることに注意しました。 - セキュリティ要素(認証、承認、およびデータの機密性)への変化の可能性に関する注を加えました。 - データ・ストリームで注入されたかもしれない紹介に続くのは避けるように注意されます。 - エラー条件であるか否かに関係なく、サーバが等しく情報を保護するべきであることに注意して、明確にmatchedDN、diagnosticMessage、およびresultCodesについて言及しました。 - 奇形の、そして、長いencodingsに関する注を加えました。
Sermersheim Standards Track [Page 65] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[65ページ]RFC4511LDAPv3 June 2006
C.1.29. Appendix A (Complete ASN.1 Definition)
C.1.29。 付録A(完全なASN.1定義)
- Added "EXTENSIBILITY IMPLIED" to ASN.1 definition. - Removed AttributeType. It is not used.
- 「含意された伸展性」をASN.1定義に加えました。 - AttributeTypeを取り外しました。 それは使用されていません。
C.2. Changes Made to RFC 2830
C.2。 RFC2830にされた変更
This section summarizes the substantive changes made to Sections of RFC 2830. Readers should consult [RFC4513] for summaries of changes to other sections.
このセクションはRFC2830のセクションにされた実質的な変更をまとめます。 読者は他のセクションへの変化の概要のために[RFC4513]に相談するべきです。
C.2.1. Section 2.3 (Response other than "success")
C.2.1。 セクション2.3(「成功」を除いた応答)
- 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. Section 4 (Closing a TLS Connection)
C.2.1。 セクション4(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 RFC 3771
C.3。 RFC3771にされた変更
- 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.
- 異なったタイプには要求へのIntermediate応答があるかもしれなくて、応答タイプのひとりが応答値を全く持たないように指定されるかもしれないと指定しました。
Sermersheim Standards Track [Page 66] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[66ページ]RFC4511LDAPv3 June 2006
Editor's Address
エディタのアドレス
Jim Sermersheim Novell, Inc. 1800 South Novell Place Provo, Utah 84606, USA
Placeプロボ、ジムSermersheimノベルInc.1800の南ノベルユタ 84606、米国
Phone: +1 801 861-3088 EMail: jimse@novell.com
以下に電話をしてください。 +1 801 861-3088 メールしてください: jimse@novell.com
Sermersheim Standards Track [Page 67] RFC 4511 LDAPv3 June 2006
Sermersheim標準化過程[67ページ]RFC4511LDAPv3 June 2006
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Sermersheim Standards Track [Page 68]
Sermersheim標準化過程[68ページ]
一覧
スポンサーリンク
