RFC2251 日本語訳
2251 Lightweight Directory Access Protocol (v3). M. Wahl, T. Howes, S.Kille. December 1997. (Format: TXT=114488 bytes) (Obsoleted by RFC4510, RFC4511, RFC4513, RFC4512) (Updated by RFC3377, RFC3771) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Wahl
Request for Comments: 2251 Critical Angle Inc.
Category: Standards Track T. Howes
Netscape Communications Corp.
S. Kille
Isode Limited
December 1997
コメントを求めるワーキンググループM.ウォール要求をネットワークでつないでください: 2251年の臨界角株式会社カテゴリ: 1997年12月に制限された標準化過程T.ハウズネットスケープ・コミュニケーションズS.Kille Isode
Lightweight Directory Access Protocol (v3)
ライトウェイト・ディレクトリ・アクセス・プロトコル(v3)
1. Status of this Memo
1. この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 (1997). All Rights Reserved.
Copyright(C)インターネット協会(1997)。 All rights reserved。
IESG Note
IESG注意
This document describes a directory access protocol that provides both read and update access. Update access requires secure authentication, but this document does not mandate implementation of any satisfactory authentication mechanisms.
このドキュメントは読まれた両方を提供するディレクトリアクセス・プロトコルとアップデートアクセサリーについて説明します。 アップデートアクセスは安全な認証を必要としますが、このドキュメントはどんな満足できる認証機構の実装も強制しません。
In accordance with RFC 2026, section 4.4.1, this specification is being approved by IESG as a Proposed Standard despite this limitation, for the following reasons:
RFC2026、セクション4.4.1に従って、この制限にもかかわらず、この仕様はProposed StandardとしてIESGによって承認されます、以下の理由で:
a. to encourage implementation and interoperability testing of
these protocols (with or without update access) before they
are deployed, and
そしてa. 以前これらのプロトコル(アップデートアクセスのあるなしにかかわらず)の実装と相互運用性テストを奨励するために、それらが配布される。
b. to encourage deployment and use of these protocols in read-only
applications. (e.g. applications where LDAPv3 is used as
a query language for directories which are updated by some
secure mechanism other than LDAP), and
b. 書き込み禁止アプリケーションにおけるこれらのプロトコルの展開と使用を奨励するために。 (例えば、LDAPv3がLDAP以外の何らかの安全なメカニズムによってアップデートされるディレクトリに照会言語として使用されるアプリケーション), そして
c. to avoid delaying the advancement and deployment of other Internet
standards-track protocols which require the ability to query, but
not update, LDAPv3 directory servers.
c. LDAPv3ディレクトリサーバを質問しますが、アップデートしない能力を必要とする他のインターネット標準化過程プロトコルの前進と展開を遅らせるのを避けるために。
Wahl, et. al. Standards Track [Page 1] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[1ページ]RFC2251LDAPv3 December 1997
Readers are hereby warned that until mandatory authentication mechanisms are standardized, clients and servers written according to this specification which make use of update functionality are UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
Readers are hereby warned that until mandatory authentication mechanisms are standardized, clients and servers written according to this specification which make use of update functionality are UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
Implementors are hereby discouraged from deploying LDAPv3 clients or servers which implement the update functionality, until a Proposed Standard for mandatory authentication in LDAPv3 has been approved and published as an RFC.
作成者はアップデートの機能性を実装するLDAPv3クライアントかサーバを配布して、これによりがっかりしています、LDAPv3での義務的な認証のためのProposed StandardがRFCとして承認されて、発行されるまで。
Table of Contents
目次
1. Status of this Memo .................................... 1
Copyright Notice ....................................... 1
IESG Note .............................................. 1
2. Abstract ............................................... 3
3. Models ................................................. 4
3.1. Protocol Model ........................................ 4
3.2. Data Model ............................................ 5
3.2.1. Attributes of Entries ............................... 5
3.2.2. Subschema Entries and Subentries .................... 7
3.3. Relationship to X.500 ................................. 8
3.4. Server-specific Data Requirements ..................... 8
4. Elements of Protocol ................................... 9
4.1. Common Elements ....................................... 9
4.1.1. Message Envelope .................................... 9
4.1.1.1. Message ID ........................................ 11
4.1.2. String Types ........................................ 11
4.1.3. Distinguished Name and Relative Distinguished Name .. 11
4.1.4. Attribute Type ...................................... 12
4.1.5. Attribute Description ............................... 13
4.1.5.1. Binary Option ..................................... 14
4.1.6. Attribute Value ..................................... 14
4.1.7. Attribute Value Assertion ........................... 15
4.1.8. Attribute ........................................... 15
4.1.9. Matching Rule Identifier ............................ 15
4.1.10. Result Message ..................................... 16
4.1.11. Referral ........................................... 18
4.1.12. Controls ........................................... 19
4.2. Bind Operation ........................................ 20
4.2.1. Sequencing of the Bind Request ...................... 21
4.2.2. Authentication and Other Security Services .......... 22
4.2.3. Bind Response ....................................... 23
4.3. Unbind Operation ...................................... 24
4.4. Unsolicited Notification .............................. 24
4.4.1. Notice of Disconnection ............................. 24
4.5. Search Operation ...................................... 25
1. このMemoの状態… 1つの版権情報… 1つのIESG注意… 1 2. 要約… 3 3. モデル… 4 3.1. モデルについて議定書の中で述べてください… 4 3.2. データはモデル化されます… 5 3.2.1. エントリーの属性… 5 3.2.2. サブスキーマエントリーと副次的記載… 7 3.3. X.500との関係… 8 3.4. サーバ特有のデータ要件… 8 4. プロトコルのElements… 9 4.1. 一般的なElements… 9 4.1.1. メッセージ封筒… 9 4.1.1.1. メッセージID… 11 4.1.2. タイプを結んでください… 11 4.1.3. 分類名と相対的な分類名。 11 4.1.4. タイプを結果と考えてください… 12 4.1.5. 記述を結果と考えてください… 13 4.1.5.1. 2進のオプション… 14 4.1.6. 値を結果と考えてください… 14 4.1.7. 値の主張を結果と考えてください… 15 4.1.8. 結果と考えます。 15 4.1.9. マッチングは識別子を統治します… 15 4.1.10. 結果メッセージ… 16 4.1.11. 紹介… 18 4.1.12. コントロール… 19 4.2. 操作を縛ってください… 20 4.2.1. ひもの要求の配列… 21 4.2.2. 認証と他のセキュリティサービス… 22 4.2.3. 応答を縛ってください… 23 4.3. 操作を解いてください… 24 4.4. 求められていない通知… 24 4.4.1. 断線の通知… 24 4.5. 操作を捜してください… 25
Wahl, et. al. Standards Track [Page 2] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[2ページ]RFC2251LDAPv3 December 1997
4.5.1. Search Request ...................................... 25 4.5.2. Search Result ....................................... 29 4.5.3. Continuation References in the Search Result ........ 31 4.5.3.1. Example ........................................... 31 4.6. Modify Operation ...................................... 32 4.7. Add Operation ......................................... 34 4.8. Delete Operation ...................................... 35 4.9. Modify DN Operation ................................... 36 4.10. Compare Operation .................................... 37 4.11. Abandon Operation .................................... 38 4.12. Extended Operation ................................... 38 5. Protocol Element Encodings and Transfer ................ 39 5.1. Mapping Onto BER-based Transport Services ............. 39 5.2. Transfer Protocols .................................... 40 5.2.1. Transmission Control Protocol (TCP) ................. 40 6. Implementation Guidelines .............................. 40 6.1. Server Implementations ................................ 40 6.2. Client Implementations ................................ 40 7. Security Considerations ................................ 41 8. Acknowledgements ....................................... 41 9. Bibliography ........................................... 41 10. Authors' Addresses ..................................... 42 Appendix A - Complete ASN.1 Definition ..................... 44 Full Copyright Statement ................................... 50
4.5.1. 要求を捜してください… 25 4.5.2. 結果を捜してください… 29 4.5.3. 検索における継続参照は結果として生じます… 31 4.5.3.1. 例… 31 4.6. 操作を変更してください… 32 4.7. 操作を加えてください… 34 4.8. 操作を削除してください… 35 4.9. DN操作を変更してください… 36 4.10. 操作を比較してください… 37 4.11. 操作を捨ててください… 38 4.12. 操作を広げています… 38 5. 要素Encodingsと転送について議定書の中で述べてください… 39 5.1. BERベースの輸送サービスに写像します。 39 5.2. プロトコルを移してください… 40 5.2.1. 通信制御プロトコル(TCP)… 40 6. 実装ガイドライン… 40 6.1. サーバ実装… 40 6.2. クライアント実装… 40 7. セキュリティ問題… 41 8. 承認… 41 9. 図書目録… 41 10. 作者のアドレス… 42 付録A--ASN.1定義を終了してください… 44 完全な著作権宣言文… 50
2. Abstract
2. 要約
The protocol described in this document is designed to provide access to directories supporting the X.500 models, while not incurring the resource requirements of the X.500 Directory Access Protocol (DAP). This protocol is specifically targeted at management applications and browser applications that provide read/write interactive access to directories. When used with a directory supporting the X.500 protocols, it is intended to be a complement to the X.500 DAP.
本書では説明されたプロトコルは、X.500ディレクトリAccessプロトコル(DAP)のリソース要件を被っていない間にX.500モデルをサポートするディレクトリへのアクセスを提供するように設計されています。 提供されるブラウザ利用は、ディレクトリへの対話的なアクセスをこのプロトコルが管理アプリケーションのときに明確に狙って、読むか、または書きます。 X.500プロトコルをサポートするディレクトリと共に使用されると、X.500 DAPへの補数であることは意図しています。
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 RFC 2119 [10].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「」、「推薦された」、およびこのドキュメントの「5月」はRFC2119[10]で説明されるように解釈されることになっているべきであるものとします。
Key aspects of this version of LDAP are:
LDAPのこのバージョンの特徴は以下の通りです。
- All protocol elements of LDAPv2 (RFC 1777) are supported. The
protocol is carried directly over TCP or other transport, bypassing
much of the session/presentation overhead of X.500 DAP.
- LDAPv2(RFC1777)のすべてのプロトコル要素が支えられます。 X.500 DAPのセッション/プレゼンテーションオーバーヘッドの多くを迂回させて、プロトコルはTCPか他の輸送の直接上まで運ばれます。
- Most protocol data elements can be encoded as ordinary strings
(e.g., Distinguished Names).
- 普通のストリング(例えば、Distinguished Names)としてほとんどのプロトコルデータ要素をコード化できます。
Wahl, et. al. Standards Track [Page 3] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[3ページ]RFC2251LDAPv3 December 1997
- Referrals to other servers may be returned.
- 他のサーバへの紹介を返すかもしれません。
- SASL mechanisms may be used with LDAP to provide association
security services.
- SASLメカニズムは、協会セキュリティー・サービスを提供するのにLDAPと共に使用されるかもしれません。
- Attribute values and Distinguished Names have been
internationalized through the use of the ISO 10646 character set.
- 属性値とDistinguished NamesはISO10646文字集合の使用で国際的にされました。
- The protocol can be extended to support new operations, and
controls may be used to extend existing operations.
- 新しい操作をサポートするためにプロトコルを広げることができます、そして、コントロールは、既存の操作を広げるのに使用されるかもしれません。
- Schema is published in the directory for use by clients.
- 図式は使用のためのディレクトリでクライアントによって発表されます。
3. Models
3. モデル
Interest in X.500 [1] directory technologies in the Internet has led to efforts to reduce the high cost of entry associated with use of these technologies. This document continues the efforts to define directory protocol alternatives, updating the LDAP [2] protocol specification.
インターネットのX.500[1]ディレクトリ技術への関心は、これらの技術の使用に関連しているエントリーの高いコストを削減するために取り組みにつながりました。 LDAP[2]プロトコル仕様をアップデートして、このドキュメントは、ディレクトリプロトコル代替手段を定義するために取り組みを続けています。
3.1. Protocol Model
3.1. プロトコルモデル
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 the operation(s), the server returns a response containing any results or errors to the requesting client.
このプロトコルによって採用された一般的なモデルはサーバに対してプロトコル操作を実行しているクライアントのひとりです。 このモデルで、クライアントはサーバに実行されるために操作について説明するプロトコル要求を伝えます。次に、サーバはディレクトリにおける必要な操作を実行するのに原因となります。 操作の完成のときに、サーバはどんな結果も含む応答か誤りを要求しているクライアントに返します。
In keeping with the goal of easing the costs associated with use of the directory, it is an objective of this protocol to minimize the complexity of clients so as to facilitate widespread deployment of applications capable of using the directory.
ディレクトリの使用に関連しているコストを緩和するという目標のために保つのにおいて、それはディレクトリを使用できるアプリケーションの広範囲の展開を容易にするためにクライアントの複雑さを最小にするこのプロトコルの目的です。
Note that 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 may be exchanged between a client and server in any order, provided the client eventually receives a response for every request that requires one.
サーバがそのような応答がプロトコルで定義されるときはいつも、応答を返すのに必要ですが、同期振舞いのための要件が全くクライアントかサーバのどちらか側のないことに注意してください。 順不同なクライアントとサーバの間で同時併行処理のための要求と応答を交換するかもしれません、クライアントが結局1を必要とするあらゆる要求のための応答を受けるなら。
In LDAP versions 1 and 2, no provision was made for protocol servers returning referrals to clients. However, for improved performance and distribution this version of the protocol permits servers to return to clients referrals to other servers. This allows servers to offload the work of contacting other servers to progress operations.
LDAPバージョン1と2では、紹介をクライアントに返すプロトコルサーバに備えました。 しかしながら、向上した性能と分配のために、プロトコルのこのバージョンは、サーバが他のサーバへのクライアント紹介に戻ることを許可します。 これで、サーバは操作を進行するように他のサーバに連絡する仕事を積み下ろすことができます。
Wahl, et. al. Standards Track [Page 4] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[4ページ]RFC2251LDAPv3 December 1997
Note that the core protocol operations defined in this document can be mapped to a strict subset of the X.500(1997) directory abstract service, so it can be cleanly provided by the DAP. However there is not a one-to-one mapping between LDAP protocol operations and DAP operations: server implementations acting as a gateway to X.500 directories may need to make multiple DAP requests.
DAPが清潔にそれを提供できるように、厳しい抽象的にX.500(1997)ディレクトリサービスの部分集合に本書では定義されたコアプロトコル操作は写像できることに注意してください。 しかしながら、LDAPプロトコル操作とDAP操作の間には、1〜1つのマッピングがありません: X.500ディレクトリへのゲートウェイとして機能するサーバ実装は、複数のDAP要求をする必要があるかもしれません。
3.2. Data Model
3.2. データモデル
This section provides a brief introduction to the X.500 data model, as used by LDAP.
LDAPによって使用されるようにこのセクションはX.500データモデルに簡潔な序論を供給します。
The LDAP protocol assumes there are one or more servers which jointly provide access to a Directory Information Tree (DIT). The tree is made up of entries. Entries have names: one or more attribute values from the entry form its relative distinguished name (RDN), which MUST be unique among all its siblings. The concatenation of the relative distinguished names of the sequence of entries from a particular entry to an immediate subordinate of the root of the tree forms that entry's Distinguished Name (DN), which is unique in the tree. An example of a Distinguished Name is
LDAPプロトコルは、共同でディレクトリ情報Tree(DIT)へのアクセスを提供する1つ以上のサーバがあると仮定します。 木はエントリーで作られます。 エントリーには、名前があります: エントリーからの1つ以上の属性値が相対的な分類名(RDN)を形成します。(それは、すべての兄弟の中でユニークであるに違いありません)。 エントリーの系列の相対的な分類名の特定のエントリーから即座の木の根の部下までの連結はそのエントリーのDistinguished Name(DN)を形成します。(Distinguished Nameは木でユニークです)。 Distinguished Nameに関する例はそうです。
CN=Steve Kille, O=Isode Limited, C=GB
CNはスティーブKille、O=Isode株式会社と等しく、CはGBと等しいです。
Some servers may hold cache or shadow copies of entries, which can be used to answer search and comparison queries, but will return referrals or contact other servers if modification operations are requested.
いくつかのサーバが検索と比較質問に答えるのに使用できるエントリーのキャッシュか影のコピーを支えるかもしれません、変更操作が要求されると、紹介を返すか、または他のサーバに連絡するのを除いて。
Servers which perform caching or shadowing MUST ensure that they do not violate any access control constraints placed on the data by the originating server.
キャッシュかシャドウイングを実行するサーバは、起因するサーバによってデータに置かれた少しのアクセス制御規制にも違反しないのを確実にしなければなりません。
The largest collection of entries, starting at an entry that is mastered by a particular server, and including all its subordinates and their subordinates, down to the entries which are mastered by different servers, is termed a naming context. The root of the DIT is a DSA-specific Entry (DSE) and not part of any naming context: each server has different attribute values in the root DSE. (DSA is an X.500 term for the directory server).
特定のサーバによってマスタリングされるエントリーで始まって、すべての部下と彼らの部下を異なったサーバによってマスタリングされるエントリーまで含むエントリーの最も大きい収集は命名文脈と呼ばれます。 DITの根はどんな命名文脈の一部ではなく、DSA特有のEntry(DSE)ですも: 各サーバには、根のDSEの異なった属性値があります。 (DSAはディレクトリサーバのためのX.500用語です。)
3.2.1. Attributes of Entries
3.2.1. エントリーの属性
Entries consist of a set of attributes. An attribute is a type with one or more associated values. The attribute type is identified by a short descriptive name and an OID (object identifier). The attribute
エントリーは1セットの属性から成ります。 属性は1つ以上の関連値があるタイプです。 属性タイプは短い描写的である名前とOID(オブジェクト識別子)によって特定されます。 属性
Wahl, et. al. Standards Track [Page 5] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[5ページ]RFC2251LDAPv3 December 1997
type governs whether there can be more than one value of an attribute of that type in an entry, the syntax to which the values must conform, the kinds of matching which can be performed on values of that attribute, and other functions.
タイプは、エントリーにおける、そのタイプの属性、値が従わなければならない構文、その属性の値に実行できるマッチングの種類、および他の機能の1つ以上の値があることができるかどうかを治めます。
An example of an attribute is "mail". There may be one or more values of this attribute, they must be IA5 (ASCII) strings, and they are case insensitive (e.g. "foo@bar.com" will match "FOO@BAR.COM").
属性に関する例は「メール」です。 この属性の1つ以上の値があるかもしれません、そして、IA5(ASCII)ストリングであるに違いありません、そして、それらは大文字と小文字を区別しないです(例えば、" foo@bar.com "は" FOO@BAR.COM "に合うでしょう)。
Schema is the collection of attribute type definitions, object class definitions and other information which a server uses to determine how to match a filter or attribute value assertion (in a compare operation) against the attributes of an entry, and whether to permit add and modify operations. The definition of schema for use with LDAP is given in [5] and [6]. Additional schema elements may be defined in other documents.
図式がサーバがエントリーの属性に対してフィルタか属性値主張(aでは、操作を比較する)に合う方法を決定するのに使用する属性型定義、オブジェクトクラス定義、および他の情報の収集であり、可能にするかどうかが、操作を加えて、変更します。 [5]と[6]でLDAPとの使用のための図式の定義を与えます。 追加図式要素は他のドキュメントで定義されるかもしれません。
Each entry MUST have an objectClass attribute. The objectClass attribute specifies the object classes of an entry, which along with the system and user schema determine the permitted attributes of an entry. Values of this attribute may be modified by clients, but the objectClass attribute cannot be removed. Servers may restrict the modifications of this attribute to prevent the basic structural class of the entry from being changed (e.g. one cannot change a person into a country). When creating an entry or adding an objectClass value to an entry, all superclasses of the named classes are implicitly added as well if not already present, and the client must supply values for any mandatory attributes of new superclasses.
各エントリーには、objectClass属性がなければなりません。 objectClass属性はエントリーのオブジェクトのクラスを指定します。(クラスはシステムとユーザ図式と共にエントリーの受入れられた属性を決定します)。 この属性の値はクライアントによって変更されるかもしれませんが、objectClass属性を取り除くことができません。 サーバは、エントリーの基本的な構造的なクラスが変えられるのを防ぐためにこの属性の変更を制限するかもしれません(例えば、1つは人を国に変えることができません)。 エントリーにエントリーを作成するか、またはobjectClass価値を高めるとき、命名されたクラスのすべての「スーパー-クラス」が、それとなくまた、加えられるか、または既に存在しています、そして、クライアントは新しい「スーパー-クラス」のどんな義務的な属性にも値を供給しなければなりません。
Some attributes, termed operational attributes, are used by servers for administering the directory system itself. They are not returned in search results unless explicitly requested by name. Attributes which are not operational, such as "mail", will have their schema and syntax constraints enforced by servers, but servers will generally not make use of their values.
操作上の属性と呼ばれたいくつかの属性が、ディレクトリシステム自体を管理するのにサーバによって使用されます。 名前によって明らかに要求されない場合、それらは検索結果で返されません。 「メール」などのように操作上でない属性は、それらの図式と構文規制がサーバによって励行されるのを持つでしょうが、一般に、サーバはそれらの値を利用しないでしょう。
Servers MUST NOT permit clients to add attributes to an entry unless those attributes are permitted by the object class definitions, the schema controlling that entry (specified in the subschema - see below), or are operational attributes known to that server and used for administrative purposes. Note that there is a particular objectClass 'extensibleObject' defined in [5] which permits all user attributes to be present in an entry.
サーバは、それらの属性がオブジェクトクラス定義、そのエントリーを制御する図式(サブスキーマ--指定されて、以下を見る)によって受入れられるか、またはそのサーバに知られて、管理目的に使用される操作上の属性でないならクライアントがエントリーに属性を加えることを許可してはいけません。 エントリーですべてのユーザ属性が現在であることを許可する[5]で定義された特定のobjectClass'extensibleObject'があることに注意してください。
Entries MAY contain, among others, the following operational attributes, defined in [5]. These attributes are maintained automatically by the server and are not modifiable by clients:
エントリーは特に[5]で定義された以下の操作上の属性を含むかもしれません。 これらの属性は、サーバによって自動的に維持されて、クライアントは修正できません:
Wahl, et. al. Standards Track [Page 6] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[6ページ]RFC2251LDAPv3 December 1997
- creatorsName: the Distinguished Name of the user who added this
entry to the directory.
- creatorsName: このエントリーをディレクトリに追加したユーザのDistinguished Name。
- createTimestamp: the time this entry was added to the directory.
- createTimestamp: このエントリーがディレクトリに追加された時。
- modifiersName: the Distinguished Name of the user who last modified
this entry.
- modifiersName: 最後にこのエントリーを変更したユーザのDistinguished Name。
- modifyTimestamp: the time this entry was last modified.
- modifyTimestamp: このエントリーが最後に変更された時。
- subschemaSubentry: the Distinguished Name of the subschema entry
(or subentry) which controls the schema for this entry.
- subschemaSubentry: このエントリーに図式を制御するサブスキーマエントリー(または、副次的記載)のDistinguished Name。
3.2.2. Subschema Entries and Subentries
3.2.2. サブスキーマエントリーと副次的記載
Subschema entries are used for administering information about the directory schema, in particular the object classes and attribute types supported by directory servers. A single subschema entry contains all schema definitions used by entries in a particular part of the directory tree.
サブスキーマエントリーは、ディレクトリ図式の情報、特にオブジェクトのクラス、およびディレクトリサーバによってサポートされた属性タイプを管理するのに使用されます。 単一のサブスキーマエントリーはディレクトリツリーの特定の部分でエントリーで使用されるすべての図式定義を含んでいます。
Servers which follow X.500(93) models SHOULD implement subschema using the X.500 subschema mechanisms, and so these subschemas are not ordinary entries. LDAP clients SHOULD NOT assume that servers implement any of the other aspects of X.500 subschema. A server which masters entries and permits clients to modify these entries MUST implement and provide access to these subschema entries, so that its clients may discover the attributes and object classes which are permitted to be present. It is strongly recommended that all other servers implement this as well.
X.500(93)モデルのためにSHOULDに続くサーバがX.500サブスキーマメカニズムを使用することでサブスキーマを実装するので、これらのサブスキーマは普通のエントリーではありません。 LDAPクライアントSHOULD NOTは、サーバがX.500サブスキーマの他の局面のどれかを実装すると仮定します。 エントリーをマスタリングして、クライアントがこれらのエントリーを変更することを許可するサーバは、これらのサブスキーマエントリーへのアクセスを実装して、提供しなければなりません、クライアントが存在していることが許可されている属性とオブジェクトのクラスを発見できるように。 また、他のすべてのサーバがこれを実装することが強く勧められます。
The following four attributes MUST be present in all subschema entries:
以下の4つの属性がすべてのサブスキーマエントリーに存在していなければなりません:
- cn: this attribute MUST be used to form the RDN of the subschema
entry.
- cn: サブスキーマエントリーのRDNを形成するのにこの属性を使用しなければなりません。
- objectClass: the attribute MUST have at least the values "top" and
"subschema".
- objectClass: 属性に、少なくとも値「先端」と「サブスキーマ」がなければなりません。
- objectClasses: each value of this attribute specifies an object
class known to the server.
- objectClasses: この属性の各値はサーバに知られているオブジェクトのクラスを指定します。
- attributeTypes: each value of this attribute specifies an attribute
type known to the server.
- attributeTypes: この属性の各値はサーバに知られている属性タイプを指定します。
These are defined in [5]. Other attributes MAY be present in subschema entries, to reflect additional supported capabilities.
これらは[5]で定義されます。 他の属性は、追加サポートしている能力を反映するためにサブスキーマエントリーに存在しているかもしれません。
Wahl, et. al. Standards Track [Page 7] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[7ページ]RFC2251LDAPv3 December 1997
These include matchingRules, matchingRuleUse, dITStructureRules, dITContentRules, nameForms and ldapSyntaxes.
これらはmatchingRules、matchingRuleUse、dITStructureRules、dITContentRules、nameForms、およびldapSyntaxesを含んでいます。
Servers SHOULD provide the attributes createTimestamp and modifyTimestamp in subschema entries, in order to allow clients to maintain their caches of schema information.
サーバSHOULDは属性のcreateTimestampとmodifyTimestampをサブスキーマエントリーに提供します、クライアントが彼らの図式情報のキャッシュを維持するのを許容するために。
Clients MUST only retrieve attributes from a subschema entry by requesting a base object search of the entry, where the search filter is "(objectClass=subschema)". (This will allow LDAPv3 servers which gateway to X.500(93) to detect that subentry information is being requested.)
クライアントは、サブスキーマエントリーから検索フィルタが「(objectClass=サブスキーマ)」であるエントリーのベースオブジェクト検索を要求することによって、属性を検索するだけでよいです。 (これはその副次的記載情報を検出するX.500(93)へのそれのゲートウェイが要求されているサーバをLDAPv3に許容するでしょう。)
3.3. Relationship to X.500
3.3. X.500との関係
This document defines LDAP in terms of X.500 as an X.500 access mechanism. An LDAP server MUST act in accordance with the X.500(1993) series of ITU recommendations when providing the service. However, it is not required that an LDAP server make use of any X.500 protocols in providing this service, e.g. LDAP can be mapped onto any other directory system so long as the X.500 data and service model as used in LDAP is not violated in the LDAP interface.
このドキュメントはX.500に関してX.500アクセス機構とLDAPを定義します。 サービスを提供するとき、X.500によると、LDAPサーバは(1993)シリーズのITU推薦を機能させなければなりません。 しかしながら、LDAPサーバがこのサービスを提供する際にどんなX.500プロトコルも利用するのが必要でなく、例えば、データとサービスがLDAPで使用されるようにモデル化するX.500がLDAPインタフェースで違反されない限り、いかなる他のディレクトリシステムにもLDAPを写像できます。
3.4. Server-specific Data Requirements
3.4. サーバ特有のデータ要件
An LDAP server MUST provide information about itself and other information that is specific to each server. This is represented as a group of attributes located in the root DSE (DSA-Specific Entry), which is named with the zero-length LDAPDN. These attributes are retrievable if a client performs a base object search of the root with filter "(objectClass=*)", however they are subject to access control restrictions. The root DSE MUST NOT be included if the client performs a subtree search starting from the root.
LDAPサーバは各サーバに特定のそれ自体の情報と他の情報を提供しなければなりません。属性のグループが根のDSE(DSA特有のEntry)(ゼロ・レングスLDAPDNで命名される)で場所を見つけられたので、これは表されます。 クライアントがフィルタによる根のベースオブジェクト検索を実行するなら「(objectClassは*と等しいです)」というこれらの属性が回収可能である、しかしながら、彼らはアクセス制御制限を受けることがあります。 根から始めて、クライアントが下位木検索を実行するなら含まれていて、DSE MUST NOTを根づかせてください。
Servers may allow clients to modify these attributes.
サーバで、クライアントはこれらの属性を変更できるかもしれません。
The following attributes of the root DSE are defined in section 5 of [5]. Additional attributes may be defined in other documents.
根のDSEの以下の属性は[5]のセクション5で定義されます。 追加属性は他のドキュメントで定義されるかもしれません。
- namingContexts: naming contexts held in the server. Naming contexts
are defined in section 17 of X.501 [6].
- namingContexts: 文脈を命名するのはサーバで成立しました。命名文脈はX.501[6]のセクション17で定義されます。
- subschemaSubentry: subschema entries (or subentries) known by this
server.
- subschemaSubentry: このサーバによって知られていたサブスキーマエントリー(または、副次的記載)。
- altServer: alternative servers in case this one is later
unavailable.
- altServer: 場合では、これは後です。代替のサーバ、入手できません。
Wahl, et. al. Standards Track [Page 8] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[8ページ]RFC2251LDAPv3 December 1997
- supportedExtension: list of supported extended operations.
- supportedExtension: サポートしている拡大手術のリスト。
- supportedControl: list of supported controls.
- supportedControl: サポートしているコントロールのリスト。
- supportedSASLMechanisms: list of supported SASL security features.
- supportedSASLMechanisms: サポートしているSASLセキュリティ機能のリスト。
- supportedLDAPVersion: LDAP versions implemented by the server.
- supportedLDAPVersion: サーバによって実装されたLDAPバージョン。
If the server does not master entries and does not know the locations of schema information, the subschemaSubentry attribute is not present in the root DSE. If the server masters directory entries under one or more schema rules, there may be any number of values of the subschemaSubentry attribute in the root DSE.
サーバがエントリーをマスタリングしないで、また図式情報の位置を知らないなら、subschemaSubentry属性は根のDSEに存在していません。 サーバが、ディレクトリエントリーが1つ以上未満の図式規則であるとマスタリングするなら、根のDSEにはsubschemaSubentry属性のいろいろな値があるかもしれません。
4. Elements of Protocol
4. プロトコルのElements
The LDAP protocol is described using Abstract Syntax Notation 1 (ASN.1) [3], and is typically transferred using a subset of ASN.1 Basic Encoding Rules [11]. In order to support future extensions to this protocol, clients and servers MUST ignore elements of SEQUENCE encodings whose tags they do not recognize.
LDAPプロトコルを抽象的なSyntax Notation1(ASN.1)[3]を使用することで説明して、ASN.1Basic Encoding Rules[11]の部分集合を使用することで通常移します。 このプロトコルに今後の拡大をサポートするために、クライアントとサーバは彼らがタグを認識しないSEQUENCE encodingsの要素を無視しなければなりません。
Note that unlike X.500, each change to the LDAP protocol other than through the extension mechanisms will have a different version number. A client will indicate the version it supports as part of the bind request, described in section 4.2. If a client has not sent a bind, the server MUST assume that version 3 is supported in the client (since version 2 required that the client bind first).
X.500と異なって、拡張機能以外のLDAPプロトコルへの各変化には異なった見解番号があることに注意してください。 クライアントはそれがセクション4.2で説明されたひもの要求の一部としてサポートするバージョンを示すでしょう。 クライアントがひもを送らないなら、サーバは、バージョン3がクライアントでサポートされると仮定しなければなりません(バージョン2が、クライアントが最初に付くのを必要としたので)。
Clients may determine the protocol version a server supports by reading the supportedLDAPVersion attribute from the root DSE. Servers which implement version 3 or later versions MUST provide this attribute. Servers which only implement version 2 may not provide this attribute.
クライアントはサーバが根のDSEからsupportedLDAPVersion属性を読むことによってサポートするプロトコルバージョンを決定するかもしれません。 バージョン3以降がバージョンであると実装するサーバはこの属性を提供しなければなりません。 バージョン2を実装するだけであるサーバはこの属性を提供しないかもしれません。
4.1. Common Elements
4.1. 一般的なElements
This section describes the LDAPMessage envelope PDU (Protocol Data Unit) format, as well as data type definitions which are used in the protocol operations.
このセクションはLDAPMessage封筒PDU(プロトコルData Unit)形式について説明します、プロトコル操作に使用されるデータ型定義と同様に。
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 {
LDAPMessage:、:= 系列
Wahl, et. al. Standards Track [Page 9] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[9ページ]RFC2251LDAPv3 December 1997
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 },
controls [0] Controls OPTIONAL }
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; } , コントロール0Controls OPTIONAL
MessageID ::= INTEGER (0 .. maxInt)
MessageID:、:= 整数(0maxInt)
maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
maxInt整数:、:= 2147483647 -- (2^^31 - 1) --
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 message ID and the controls.
LDAPMessageの機能はすべてのプロトコル交換で必要である共同耕地を含む封筒を提供することです。 このとき、唯一の共同耕地は、メッセージIDとコントロールです。
If the server receives a PDU 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 MUST return the notice of disconnection described in section 4.4.1, with resultCode protocolError, and immediately close the connection. In other cases that the server cannot parse the request received by the client, the server MUST return an appropriate response to the request, with the resultCode set to protocolError.
サーバがLDAPMessage SEQUENCEタグを認識できないクライアントからPDUを受けるか、messageIDを分析できないか、protocolOpのタグが要求として認められないか、またはデータ・フィールドのコード化構造か長さが不正確であることがわかっているなら、サーバは、resultCode protocolErrorと共にセクション4.4.1で説明された断線の通知を返して、すぐに、接続を終えなければなりません。 サーバが分析できない他の場合では、要求はクライアントのそばで受信されて、サーバは要求への適切な応答を返さなければなりません、protocolErrorに用意ができているresultCodeと共に。
If the client receives a PDU from the server which cannot be parsed, the client may discard the PDU, or may abruptly close the connection.
クライアントが分析できないサーバからPDUを受け取るなら、クライアントは、PDUを捨てるか、または突然に接続を終えるかもしれません。
The ASN.1 type Controls is defined in section 4.1.12.
ASN.1タイプControlsはセクション4.1.12で定義されます。
Wahl, et. al. Standards Track [Page 10] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[10ページ]RFC2251LDAPv3 December 1997
4.1.1.1. Message ID
4.1.1.1. メッセージID
All LDAPMessage envelopes encapsulating responses contain the messageID value of the corresponding request LDAPMessage.
応答をカプセル化するすべてのLDAPMessage封筒が対応する要求LDAPMessageのmessageID値を含んでいます。
The message ID of a request MUST have a value different from the values of any other requests outstanding in the LDAP session of which this message is a part.
要求のメッセージIDには、このメッセージが部分であるLDAPセッションの未払いのいかなる他の要求の値とも異なった値がなければなりません。
A client MUST NOT send a second request with the same message ID as an earlier request on the same connection if the client has not received the final response from the earlier request. Otherwise the behavior is undefined. Typical clients increment a counter for each request.
クライアントが以前の要求から最終的な応答を受けていないなら、クライアントは以前の要求として同じメッセージIDとの2番目の要求を同じ接続に送ってはいけません。 さもなければ、振舞いは未定義です。 典型的なクライアントは各要求のためにカウンタを増加します。
A client MUST NOT reuse the message id of an abandonRequest or of the abandoned operation until it has received a response from the server for another request invoked subsequent to the abandonRequest, as the abandonRequest itself does not have a response.
abandonRequest自身には応答がないのでabandonRequestにその後で呼び出された別の要求のためのサーバから応答を受けるまで、クライアントはabandonRequestか捨てられた操作のメッセージイドを再利用してはいけません。
4.1.2. String Types
4.1.2. ストリングタイプ
The LDAPString is a notational convenience to indicate that, although strings of LDAPString type encode as OCTET STRING types, the ISO 10646 [13] character set (a superset of Unicode) is used, encoded following the UTF-8 algorithm [14]. Note that in the UTF-8 algorithm characters which are the same as ASCII (0x0000 through 0x007F) are represented as that same ASCII character in a single byte. The other byte values are used to form a variable-length encoding of an arbitrary character.
LDAPStringはUTF-8アルゴリズム[14]に従って、ISO10646[13]文字集合(ユニコードのスーパーセット)がOCTET STRINGがタイプするようにLDAPStringのストリングがエンコードをタイプしますが、中古で、コード化されているのを示す記号法の便利です。 UTF-8アルゴリズムで、ASCII(0x007Fを通した0×0000)と同じキャラクタがその同じASCII文字として1バイトで代理をされることに注意してください。 他のバイト値は、気紛れな質の可変長のコード化を形成するのに使用されます。
LDAPString ::= OCTET STRING
LDAPString:、:= 八重奏ストリング
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.
LDAPOIDはこのストリングの受入れられた値がOBJECT IDENTIFIERの(コード化されたUTF-8)ドット付き10進法表現であることを示す記号法の便利です。
LDAPOID ::= OCTET STRING
LDAPOID:、:= 八重奏ストリング
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 and a RelativeLDAPDN are respectively defined to be the representation of a Distinguished Name and a Relative Distinguished Name after encoding according to the specification in [4], such that
LDAPDNとRelativeLDAPDNは[4]の仕様に従ったコード化の後のDistinguished NameとRelative Distinguished Nameの表現になるようにそれぞれ定義されて、そのようなものはそれです。
Wahl, et. al. Standards Track [Page 11] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[11ページ]RFC2251LDAPv3 December 1997
<distinguished-name> ::= <name>
<分類名>:、:= <名前>。
<relative-distinguished-name> ::= <name-component>
<の相対的な分類名の>:、:= <名コンポーネント>。
where <name> and <name-component> are as defined in [4].
<名前>と<名前部品>が[4]で定義されるようにあるところで。
LDAPDN ::= LDAPString
LDAPDN:、:= LDAPString
RelativeLDAPDN ::= LDAPString
RelativeLDAPDN:、:= LDAPString
Only Attribute Types can be present in a relative distinguished name component; the options of Attribute Descriptions (next section) MUST NOT be used in specifying distinguished names.
Attribute Typesだけが相対的な分類名コンポーネントで存在している場合があります。 分類名を指定する際にAttribute記述(次のセクション)のオプションを使用してはいけません。
4.1.4. Attribute Type
4.1.4. 属性タイプ
An AttributeType takes on as its value the textual string associated with that AttributeType in its specification.
AttributeTypeは値として仕様でそのAttributeTypeに関連している原文のストリングを帯びます。
AttributeType ::= LDAPString
AttributeType:、:= LDAPString
Each attribute type has a unique OBJECT IDENTIFIER which has been assigned to it. This identifier may be written as decimal digits with components separated by periods, e.g. "2.5.4.10".
各属性タイプはそれに割り当てられたユニークなOBJECT IDENTIFIERを持っています。 コンポーネントがある10進数字が周期的に例えば分離したのでこの識別子が書かれているかもしれない、「2.5 .4 0.1インチ」
A specification may also assign one or more textual names for an attribute type. These names MUST begin with a letter, and only contain ASCII letters, digit characters and hyphens. They are case insensitive. (These ASCII characters are identical to ISO 10646 characters whose UTF-8 encoding is a single byte between 0x00 and 0x7F.)
また、仕様は属性タイプのために1つ以上の原文の名前を割り当てるかもしれません。 これらの名前は、手紙で始まって、ASCII手紙、ケタキャラクタ、およびハイフンを含むだけでよいです。 それらは大文字と小文字を区別しないです。 (これらのASCII文字がISOと同じである、UTF-8コード化が0×00と0x7F.の間の1バイトである10646のキャラクタ)
If the server has a textual name for an attribute type, it MUST use a textual name for attributes returned in search results. The dotted- decimal OBJECT IDENTIFIER is only used if there is no textual name for an attribute type.
サーバに属性タイプのための原文の名前があるなら、それは検索結果で返された属性に原文の名前を使用しなければなりません。 属性タイプのためのどんな原文の名前もない場合にだけ、点を打たされた10進OBJECT IDENTIFIERは使用されます。
Attribute type textual names are non-unique, as two different specifications (neither in standards track RFCs) may choose the same name.
2つの規格相違(どちらも、規格では、RFCsを追跡しない)が同じ名前を選ぶかもしれないので、属性タイプの原文の名は非ユニークです。
A server which masters or shadows entries SHOULD list all the attribute types it supports in the subschema entries, using the attributeTypes attribute. Servers which support an open-ended set of attributes SHOULD include at least the attributeTypes value for the 'objectClass' attribute. Clients MAY retrieve the attributeTypes value from subschema entries in order to obtain the OBJECT IDENTIFIER and other information associated with attribute types.
サーバのどのマスターか影のエントリーSHOULDがそれがサブスキーマエントリーでサポートするすべての属性タイプを記載します、attributeTypes属性を使用して。 属性SHOULDの制限のないセットを支えるサーバが'objectClass'属性のための少なくともattributeTypes値を含んでいます。 クライアントは、属性タイプに関連しているOBJECT IDENTIFIERと他の情報を入手するためにサブスキーマエントリーからattributeTypes値を検索するかもしれません。
Wahl, et. al. Standards Track [Page 12] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[12ページ]RFC2251LDAPv3 December 1997
Some attribute type names which are used in this version of LDAP are described in [5]. Servers may implement additional attribute types.
LDAPのこのバージョンで使用されるいくつかの属性型名が[5]で説明されます。 サーバは追加属性タイプを実装するかもしれません。
4.1.5. Attribute Description
4.1.5. 属性記述
An AttributeDescription is a superset of the definition of the AttributeType. It has the same ASN.1 definition, but allows additional options to be specified. They are also case insensitive.
AttributeDescriptionはAttributeTypeの定義のスーパーセットです。 それは、同じASN.1定義を持っていますが、追加オプションが指定されるのを許容します。 また、それらも大文字と小文字を区別しないです。
AttributeDescription ::= LDAPString
AttributeDescription:、:= LDAPString
A value of AttributeDescription is based on the following BNF:
AttributeDescriptionの値は以下のBNFに基づいています:
<AttributeDescription> ::= <AttributeType> [ ";" <options> ]
<AttributeDescription>:、:= <AttributeType>。[「」、;、<オプション>]
<options> ::= <option> | <option> ";" <options>
<オプション>:、:= <オプション>。| 「<オプション>」;、」 <オプション>。
<option> ::= <opt-char> <opt-char>*
<オプション>:、:= 炭の><を選んでいる<炭を選んでいる>*
<opt-char> ::= ASCII-equivalent letters, numbers and hyphen
炭を選んでいる<>:、:= ASCII同等な手紙、数、およびハイフン
Examples of valid AttributeDescription:
有効なAttributeDescriptionに関する例:
cn
userCertificate;binary
cn userCertificate; バイナリー
One option, "binary", is defined in this document. Additional options may be defined in IETF standards-track and experimental RFCs. Options beginning with "x-" are reserved for private experiments. Any option could be associated with any AttributeType, although not all combinations may be supported by a server.
「2進である」1つのオプションが本書では定義されます。 追加オプションはIETF標準化過程と実験的なRFCsで定義されるかもしれません。 「x」で始まるオプションは個人的な実験のために控えられます。 すべての組み合わせがサーバで後押しされているかもしれないというわけではありませんが、どんなオプションもどんなAttributeTypeにも関連づけることができました。
An AttributeDescription with one or more options is treated as a subtype of the attribute type without any options. Options present in an AttributeDescription are never mutually exclusive. Implementations MUST generate the <options> list sorted in ascending order, and servers MUST treat any two AttributeDescription with the same AttributeType and options as equivalent. A server will treat an AttributeDescription with any options it does not implement as an unrecognized attribute type.
1つ以上のオプションがあるAttributeDescriptionは少しもオプションなしで属性タイプの「副-タイプ」として扱われます。 AttributeDescriptionの現在のオプションは互いに決して排他的ではありません。 実装は昇順に分類された<オプション>リストを生成しなければなりません、そして、サーバは同じ同じくらいAttributeTypeと同等な同じくらいオプションでどんな2AttributeDescriptionも扱わなければなりません。 サーバはそれが認識されていない属性タイプとして実装しない少しのオプションでもAttributeDescriptionを扱うでしょう。
The data type "AttributeDescriptionList" describes a list of 0 or more attribute types. (A list of zero elements has special significance in the Search request.)
データ型"AttributeDescriptionList"は0人以上の属性タイプのリストについて説明します。 (零元のリストには、検索要求における特別な意味があります。)
AttributeDescriptionList ::= SEQUENCE OF
AttributeDescription
AttributeDescriptionList:、:= AttributeDescriptionの系列
Wahl, et. al. Standards Track [Page 13] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[13ページ]RFC2251LDAPv3 December 1997
4.1.5.1. Binary Option
4.1.5.1. 2進のオプション
If the "binary" option is present in an AttributeDescription, it overrides any string-based encoding representation defined for that attribute in [5]. Instead the attribute is to be transferred as a binary value encoded using the Basic Encoding Rules [11]. The syntax of the binary value is an ASN.1 data type definition which is referenced by the "SYNTAX" part of the attribute type definition.
「2進」のオプションがAttributeDescriptionに存在しているなら、それは表現が[5]のその属性のために定義したどんなストリングベースのコード化もくつがえします。 代わりに、属性はBasic Encoding Rules[11]を使用することでコード化された2進の値として移すことです。 2進の価値の構文は属性型定義の「構文」部分によって参照をつけられるASN.1データ型定義です。
The presence or absence of the "binary" option only affects the transfer of attribute values in protocol; servers store any particular attribute in a single format. If a client requests that a server return an attribute in the binary format, but the server cannot generate that format, the server MUST treat this attribute type as an unrecognized attribute type. Similarly, clients MUST NOT expect servers to return an attribute in binary format if the client requested that attribute by name without the binary option.
「2進」のオプションの存在か欠如がプロトコルにおける、属性値の転送に影響するだけです。 サーバはただ一つの形式でどんな特定の属性も保存します。 クライアントが、サーバがバイナリフォーマットで属性を返すよう要求しますが、サーバがその形式を生成することができないなら、サーバは認識されていない属性タイプとしてこの属性タイプを扱わなければなりません。 同様に、クライアントが2進のオプションのない名前のその属性を要求したなら、クライアントは、サーバがバイナリフォーマットで属性を返すと予想してはいけません。
This option is intended to be used with attributes whose syntax is a complex ASN.1 data type, and the structure of values of that type is needed by clients. Examples of this kind of syntax are "Certificate" and "CertificateList".
構文が複雑なASN.1データ型である属性と共にこのオプションが使用されることを意図して、そのタイプの値の構造はクライアントによって必要とされます。 この種類の構文に関する例は、「証明書」と"CertificateList"です。
4.1.6. Attribute Value
4.1.6. 属性値
A field of type AttributeValue takes on as its value either a string encoding of a AttributeValue data type, or an OCTET STRING containing an encoded binary value, depending on whether the "binary" option is present in the companion AttributeDescription to this AttributeValue.
タイプAttributeValueの分野は値としてAttributeValueデータ型をコード化するストリングかコード化された2進の値を含むOCTET STRINGのどちらかを帯びます、このAttributeValueへの仲間AttributeDescriptionで「2進」のオプションが存在しているかどうかによって。
The definition of string encodings for different syntaxes and types may be found in other documents, and in particular [5].
異なった構文とタイプのためのストリングencodingsの定義は他のドキュメント、および特定の[5]で見つけられるかもしれません。
AttributeValue ::= OCTET STRING
AttributeValue:、:= 八重奏ストリング
Note that there is no defined limit on the size of this encoding; thus protocol values may include multi-megabyte attributes (e.g. photographs).
定義された限界が全くこのコード化のサイズにないことに注意してください。 したがって、プロトコル値はマルチメガバイト属性(例えば、写真)を含むかもしれません。
Attributes may be defined which have arbitrary and non-printable syntax. Implementations MUST NEITHER simply display nor attempt to decode as ASN.1 a value if its syntax is not known. The implementation may attempt to discover the subschema of the source entry, and retrieve the values of attributeTypes from it.
属性は定義されるかもしれません(任意の、そして、非印刷可能な構文があります)。 実装MUST NEITHERは、単に表示して、構文が知られていないなら、ASN.1として値を解読するのを試みます。 実装は、ソースエントリーのサブスキーマを発見して、それからattributeTypesの値を検索するのを試みるかもしれません。
Clients MUST NOT send attribute values in a request which are not valid according to the syntax defined for the attributes.
クライアントは要求における属性のために定義された構文によると、有効でない属性値を送ってはいけません。
Wahl, et. al. Standards Track [Page 14] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[14ページ]RFC2251LDAPv3 December 1997
4.1.7. Attribute Value Assertion
4.1.7. 属性値主張
The AttributeValueAssertion type definition is similar to the one in the X.500 directory standards. It contains an attribute description and a matching rule assertion value suitable for that type.
AttributeValueAssertion型定義はX.500ディレクトリ規格においてものと同様です。 それはそのタイプに適した属性記述と合っている規則主張価値を含んでいます。
AttributeValueAssertion ::= SEQUENCE {
attributeDesc AttributeDescription,
assertionValue AssertionValue }
AttributeValueAssertion:、:= 系列attributeDesc AttributeDescription、assertionValue AssertionValue
AssertionValue ::= OCTET STRING
AssertionValue:、:= 八重奏ストリング
If the "binary" option is present in attributeDesc, this signals to the server that the assertionValue is a binary encoding of the assertion value.
「2進」のオプションがattributeDescに存在しているなら、これは、assertionValueが主張価値をコード化するバイナリーであるとサーバに合図します。
For all the string-valued user attributes described in [5], the assertion value syntax is the same as the value syntax. Clients may use attribute values as assertion values in compare requests and search filters.
[5]で説明されたすべてのストリングで評価されたユーザ属性において、主張値の構文は値の構文と同じです。 中の主張値が要求と検索フィルタを比較するとき、クライアントは属性値を使用するかもしれません。
Note however that the assertion syntax may be different from the value syntax for other attributes or for non-equality matching rules. These may have an assertion syntax which contains only part of the value. See section 20.2.1.8 of X.501 [6] for examples.
しかしながら、他の属性か非平等において、主張構文が規則を合わせながら値の構文と異なるかもしれないことに注意してください。 これらには、価値の一部だけを含む主張構文があるかもしれません。 セクション20.2を見てください。.1 例のための.8X.501[6]。
4.1.8. Attribute
4.1.8. 属性
An attribute consists of a type and one or more values of that type. (Though attributes MUST have at least one value when stored, due to access control restrictions the set may be empty when transferred in protocol. This is described in section 4.5.2, concerning the PartialAttributeList type.)
属性はそのタイプのタイプと1つ以上の値から成ります。 (属性に、保存されると、少なくとも1つの値がなければなりませんが、アクセス制御制限のために、プロトコルで移すと、セットは空であるかもしれません。 これはPartialAttributeListタイプに関してセクション4.5.2で説明されます。)
Attribute ::= SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
以下を結果と考えてください:= 系列AttributeDescription、vals SET OF AttributeValueをタイプしてください。
Each attribute value is distinct in the set (no duplicates). The order of attribute values within the vals set is undefined and implementation-dependent, and MUST NOT be relied upon.
それぞれの属性値はセット(写しがない)において異なっています。 valsセットの中の属性値の注文を未定義であって、実装依存していて、当てにされてはいけません。
4.1.9. Matching Rule Identifier
4.1.9. 合っている規則識別子
A matching rule is a means of expressing how a server should compare an AssertionValue received in a search filter with an abstract data value. The matching rule defines the syntax of the assertion value and the process to be performed in the server.
合っている規則はサーバがどう検索フィルタに抽象的なデータ値で受け取られたAssertionValueを比較するべきであるかを言い表す手段です。 合っている規則は、サーバで実行されるために主張値とプロセスの構文を定義します。
Wahl, et. al. Standards Track [Page 15] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[15ページ]RFC2251LDAPv3 December 1997
An X.501(1993) Matching Rule is identified in the LDAP protocol by the printable representation of its OBJECT IDENTIFIER, either as one of the strings given in [5], or as decimal digits with components separated by periods, e.g. "caseIgnoreIA5Match" or "1.3.6.1.4.1.453.33.33".
または、X.501の(1993)合っているRuleはOBJECT IDENTIFIERの印刷可能な表現によってLDAPプロトコルで特定されます、どちらか[5]、またはコンポーネントがある10進数字が期間、例えば、"caseIgnoreIA5Match"で分離したので与えられたストリングの1つとして「1.3 .6 .1 .4 .1 .453 .33 0.33インチ」
MatchingRuleId ::= LDAPString
MatchingRuleId:、:= LDAPString
Servers which support matching rules for use in the extensibleMatch search filter MUST list the matching rules they implement in subschema entries, using the matchingRules attributes. The server SHOULD also list there, using the matchingRuleUse attribute, the attribute types with which each matching rule can be used. More information is given in section 4.4 of [5].
extensibleMatch検索フィルタにおける使用のための合っている規則をサポートするサーバはそれらがサブスキーマエントリーで実装する合っている規則を記載しなければなりません、matchingRules属性を使用して。 また、サーバSHOULDはそこに記載します、matchingRuleUse属性(それぞれの合っている規則を使用できる属性タイプ)を使用して [5]のセクション4.4で詳しい情報を与えます。
4.1.10. Result Message
4.1.10. 結果メッセージ
The LDAPResult is the construct used in this protocol to return success or failure indications from servers to clients. In response to various requests servers will return responses containing fields of type LDAPResult to indicate the final status of a protocol operation request.
LDAPResultはサーバからクライアントまでの成否指摘を返すのにこのプロトコルに使用される構造物です。 様々な要求に対応して、サーバは、プロトコル操作要求の最終的な状態を示すためにタイプLDAPResultの分野を含む応答を返すでしょう。
LDAPResult ::= SEQUENCE {
resultCode ENUMERATED {
success (0),
operationsError (1),
protocolError (2),
timeLimitExceeded (3),
sizeLimitExceeded (4),
compareFalse (5),
compareTrue (6),
LDAPResult:、:= SEQUENCE、resultCode ENUMERATED、成功(0)、operationsError(1)、protocolError(2)、timeLimitExceeded(3)、sizeLimitExceeded(4)、compareFalse(5)、compareTrue(6)
authMethodNotSupported (7),
strongAuthRequired (8),
-- 9 reserved --
referral (10), -- new
adminLimitExceeded (11), -- new
unavailableCriticalExtension (12), -- new
confidentialityRequired (13), -- new
saslBindInProgress (14), -- new
noSuchAttribute (16),
undefinedAttributeType (17),
inappropriateMatching (18),
constraintViolation (19),
attributeOrValueExists (20),
invalidAttributeSyntax (21),
-- 22-31 unused --
authMethodNotSupported(7)、strongAuthRequired(8)--予約された9--紹介(10)--新しいadminLimitExceeded(11)--新しいunavailableCriticalExtension(12)--新しいconfidentialityRequired(13)--新しいsaslBindInProgress(14)--新しいnoSuchAttribute(16)、undefinedAttributeType(17)、inappropriateMatching(18)、constraintViolation(19)、attributeOrValueExists(20)、invalidAttributeSyntax(21)--22-31 未使用--
Wahl, et. al. Standards Track [Page 16] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[16ページ]RFC2251LDAPv3 December 1997
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), -- new
-- 72-79 unused --
other (80) },
-- 81-90 reserved for APIs --
matchedDN LDAPDN,
errorMessage LDAPString,
referral [3] Referral OPTIONAL }
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、errorMessage LDAPString、--APIのために予約された81-90--紹介3Referral OPTIONAL
All the result codes with the exception of success, compareFalse and compareTrue are to be treated as meaning the operation could not be completed in its entirety.
成功、compareFalse、およびcompareTrue以外のすべての結果コードは操作が全体として完了できなかったことを意味するとして扱われることです。
Most of the result codes are based on problem indications from X.511 error data types. Result codes from 16 to 21 indicate an AttributeProblem, codes 32, 33, 34 and 36 indicate a NameProblem, codes 48, 49 and 50 indicate a SecurityProblem, codes 51 to 54 indicate a ServiceProblem, and codes 64 to 69 and 71 indicates an UpdateProblem.
結果コードの大部分はX.511誤りデータ型からの問題指摘に基づいています。 16〜21までの結果コードはAttributeProblemを示します、そして、コード32、33、34、および36はNameProblemを示します、そして、コード48、49、および50はSecurityProblemを示します、そして、コード51〜54は64〜69にServiceProblem、およびコードを示します、そして、71はUpdateProblemを示します。
If a client receives a result code which is not listed above, it is to be treated as an unknown error condition.
クライアントが上に記載されていない結果コードを受け取るなら、それは未知のエラー条件として扱われることになっています。
The errorMessage field of this construct may, at the server's option, be used to return a string containing a textual, human-readable (terminal control and page formatting characters should be avoided) error diagnostic. As this error diagnostic is not standardized,
サーバの選択では、この構造物のerrorMessage分野は、原文の、そして、人間読み込み可能な(端末のコントロールとキャラクタをフォーマットするページは避けられるべきである)エラー診断を含むストリングを返すのに使用されるかもしれません。 この誤りとして、病気の特徴は標準化されません。
Wahl, et. al. Standards Track [Page 17] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[17ページ]RFC2251LDAPv3 December 1997
implementations MUST NOT rely on the values returned. If the server chooses not to return a textual diagnostic, the errorMessage field of the LDAPResult type MUST contain a zero length string.
実装は返された値を当てにしてはいけません。 サーバが、原文の病気の特徴を返さないのを選ぶなら、LDAPResultタイプのerrorMessage分野はゼロ長ストリングを含まなければなりません。
For result codes of noSuchObject, aliasProblem, invalidDNSyntax and aliasDereferencingProblem, the matchedDN field is set to the name of the lowest entry (object or alias) in the directory that was matched. If no aliases were dereferenced while attempting to locate the entry, this will be a truncated form of the name provided, or if aliases were dereferenced, of the resulting name, as defined in section 12.5 of X.511 [8]. The matchedDN field is to be set to a zero length string with all other result codes.
noSuchObject、aliasProblem、invalidDNSyntax、およびaliasDereferencingProblemの結果コードにおいて、matchedDN分野は合わせられたディレクトリで最も低いエントリー(オブジェクトか別名)の名前に設定されます。 エントリーの場所を見つけるのを試みている間、別名が全く「反-参照をつけ」られなかったなら、これは提供という名前の端が欠けているフォームか別名が結果として起こる名前について「反-参照をつけ」られたかどうかということでしょう、X.511[8]のセクション12.5で定義されるように。 matchedDN分野は他のすべての結果コードがあるゼロ長ストリングに設定されることです。
4.1.11. Referral
4.1.11. 紹介
The referral error indicates that the contacted server does not hold the target entry of the request. The referral field is present in an LDAPResult if the LDAPResult.resultCode field value is referral, and absent with all other result codes. It contains a reference to another server (or set of servers) which 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 URL MUST be present in the Referral.
紹介誤りは、連絡されたサーバが要求の目標エントリーを保持しないのを示します。 LDAPResult.resultCode分野価値が他のすべての結果コードで紹介であって、欠けるなら、紹介分野はLDAPResultに存在しています。 それはLDAPを通してアクセスされるかもしれない別のサーバ(または、サーバのセット)か他のプロトコルの参照を含んでいます。 どんな操作要求に対応して紹介を返すことができます(応答を持っていないものを、解いて、捨ててください)。 少なくとも1つのURLがReferralに存在していなければなりません。
The referral is not returned for a singleLevel or wholeSubtree search in which the search scope spans multiple naming contexts, and several different servers would need to be contacted to complete the operation. Instead, continuation references, described in section 4.5.3, are returned.
紹介は検索範囲が複数の命名文脈にかかるsingleLevelかwholeSubtree検索のために返されません、そして、いくつかの異なったサーバが操作を完了するために連絡される必要があるでしょう。 代わりに、セクション4.5.3で説明された継続参照を返します。
Referral ::= SEQUENCE OF LDAPURL -- one or more
紹介:、:= SEQUENCE OF LDAPURL--1以上
LDAPURL ::= LDAPString -- limited to characters permitted in URLs
LDAPURL:、:= LDAPString--URLで受入れられたキャラクタに制限されます。
If the client wishes to progress the operation, it MUST follow the referral by contacting any one of servers. All the URLs MUST be equally capable of being used to progress the operation. (The mechanisms for how this is achieved by multiple servers are outside the scope of this document.)
クライアントが操作を進行したいなら、サーバのどれかに連絡することによって、それは紹介に続かなければなりません。 すべてのURLが、操作を進行するのに等しく使用できなければなりません。 (このドキュメントの範囲の外にこれが複数のサーバによってどう達成されるかメカニズムがあります。)
URLs for servers implementing the LDAP protocol are written according to [9]. If an alias was dereferenced, the <dn> part of the URL MUST be present, with the new target object name. If the <dn> part is present, the client MUST use this name in its next request to progress the operation, and if it is not present the client will use the same name as in the original request. Some servers (e.g. participating in distributed indexing) may provide a different filter in a referral for a search operation. If the filter part of the URL
[9]によると、LDAPプロトコルを実装するサーバのためのURLは書かれています。 別名が「反-参照をつけ」られたなら、URLの<dn>部分は新しい目標オブジェクト名について存在していなければなりません。 <dn>部分が存在しているなら、クライアントは操作を進行するという次の要求でこの名前を使用しなければなりません、そして、それが存在していないと、クライアントはオリジナルの要求のように同じ名前を使用するでしょう。 いくつかのサーバ(例えば、分配されたインデックスに参加する)が異なったフィルタを索敵行動のための紹介に提供するかもしれません。 フィルタであるなら、URLを離れさせてください。
Wahl, et. al. Standards Track [Page 18] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[18ページ]RFC2251LDAPv3 December 1997
is present in an LDAPURL, the client MUST use this filter in its next request to progress this search, and if it is not present the client MUST use the same filter as it used for that search. Other aspects of the new request may be the same or different as the request which generated the referral.
プレゼントがLDAPURLにあります、そして、クライアントはこの検索を進行するという次の要求でこのフィルタを使用しなければなりません、そして、それが存在していないなら、クライアントはその検索において使用されていた状態でそれと同じフィルタを使用しなければなりません。 新しい要求の他の局面は、紹介を生成した要求として、同じであるか、または異なっているかもしれません。
Note that UTF-8 characters appearing in a DN or search filter may not be legal for URLs (e.g. spaces) and MUST be escaped using the % method in RFC 1738 [7].
DNか検索フィルタに現れるUTF-8キャラクタをURL(例えば、空間)には法的でないかもしれなく、RFC1738[7]で%メソッドを使用して、逃げなければならないことに注意してください。
Other kinds of URLs may be returned, so long as the operation could be performed using that protocol.
そのプロトコルを使用することで操作を実行できるだろう限り、他の種類のURLを返すかもしれません。
4.1.12. Controls
4.1.12. コントロール
A control is a way to specify extension information. Controls which are sent as part of a request apply only to that request and are not saved.
コントロールは拡大情報を指定する方法です。 要求の一部として送られるコントロールは、その要求だけに適用して、保存されません。
Controls ::= 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 MUST be a UTF-8 encoded dotted-decimal representation of an OBJECT IDENTIFIER which uniquely identifies the control. This prevents conflicts between control names.
controlType分野はUTF-8が唯一コントロールを特定するOBJECT IDENTIFIERのドット付き10進法表現をコード化したということであるに違いありません。 これは規制名の間の闘争を防ぎます。
The criticality field is either TRUE or FALSE.
臨界分野は、TRUEかFALSEのどちらかです。
If the server recognizes the control type and it is appropriate for the operation, the server will make use of the control when performing the operation.
操作を実行するとき、サーバがコントロールタイプを見分けて、操作に、それが適切であるなら、サーバはコントロールを利用するでしょう。
If the server does not recognize the control type and the criticality field is TRUE, the server MUST NOT perform the operation, and MUST instead return the resultCode unsupportedCriticalExtension.
サーバがコントロールタイプを見分けないで、臨界分野がTRUEであるなら、サーバは、操作を実行してはいけなくて、代わりにresultCode unsupportedCriticalExtensionを返さなければなりません。
If the control is not appropriate for the operation and criticality field is TRUE, the server MUST NOT perform the operation, and MUST instead return the resultCode unsupportedCriticalExtension.
操作には、コントロールが適切でなく、臨界分野がTRUEであるなら、サーバは、操作を実行してはいけなくて、代わりにresultCode unsupportedCriticalExtensionを返さなければなりません。
If the control is unrecognized or inappropriate but the criticality field is FALSE, the server MUST ignore the control.
コントロールが認識されていないか、または不適当ですが、臨界分野がFALSEであるなら、サーバはコントロールを無視しなければなりません。
Wahl, et. al. Standards Track [Page 19] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[19ページ]RFC2251LDAPv3 December 1997
The controlValue contains any information associated with the control, and its format is defined for the control. The server 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 which is associated with a control of its type.
controlValueはコントロールに関連しているどんな情報も含んでいます、そして、書式はコントロールのために定義されます。 バイトを全く含んでいなくて、controlValue八重奏ストリングの任意のコンテンツを扱うようにサーバを準備しなければなりません。 どんなタイプのコントロールに関連している値の情報もない場合にだけ、欠けています。
This document does not define any controls. Controls may be defined in other documents. The definition of a control consists of:
このドキュメントは少しのコントロールも定義しません。 コントロールは他のドキュメントで定義されるかもしれません。 コントロールの定義は以下から成ります。
- the OBJECT IDENTIFIER assigned to the control,
- コントロールに割り当てられたOBJECT IDENTIFIER
- whether the control is always noncritical, always critical, or
critical at the client's option,
- コントロールは、クライアントの選択でいつも非臨界である、いつも重要ですか、または重要ですか?
- the format of the controlValue contents of the control.
- コントロールのcontrolValueコンテンツの形式。
Servers list the controls which they recognize in the supportedControl attribute in the root DSE.
サーバは彼らが根のDSEのsupportedControl属性で認識するコントロールを記載します。
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.
Bind Operationの機能は認証情報がクライアントとサーバの間で交換されるのを許容することです。
The Bind Request is defined as follows:
Bind Requestは以下の通り定義されます:
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が[3] SaslCredentialsをsaslする
SaslCredentials ::= SEQUENCE {
mechanism LDAPString,
credentials OCTET STRING OPTIONAL }
SaslCredentials:、:= 系列メカニズムLDAPString、資格証明書OCTET STRING OPTIONAL
Parameters of the Bind Request are:
Bind Requestのパラメタは以下の通りです。
- version: A version number indicating the version of the protocol to
be used in this protocol session. This document describes version
3 of the LDAP protocol. Note that there is no version negotiation,
and the client just sets this parameter to the version it desires.
If the client requests protocol version 2, a server that supports
the version 2 protocol as described in [2] will not return any v3-
- バージョン: このプロトコルセッションのときに使用されるためにプロトコルのバージョンを示すバージョン番号。 このドキュメントはLDAPプロトコルのバージョン3について説明します。 バージョン交渉が全くないことに注意してください。そうすれば、クライアントはただそれが望んでいるバージョンにこのパラメタを設定します。 クライアント要求がバージョン2について議定書の中で述べると、[2]で説明されるようにバージョン2プロトコルをサポートするサーバは少しのv3も返さないでしょう。
Wahl, et. al. Standards Track [Page 20] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[20ページ]RFC2251LDAPv3 December 1997
specific protocol fields. (Note that not all LDAP servers will
support protocol version 2, since they may be unable to generate
the attribute syntaxes associated with version 2.)
特定のプロトコル分野。 (すべてのLDAPサーバがプロトコルバージョン2をサポートするというわけではないことに注意してください、属性がバージョン2に関連している構文であると生成することができないかもしれないので。)
- name: 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, when authentication
has been performed at a lower layer, or when using SASL credentials
with a mechanism that includes the LDAPDN in the credentials.
- 以下を命名してください。 クライアントが縛りたがっているディレクトリオブジェクトの名前。 この分野は認証が下層で実行されたか、またはSASL資格証明書を使用するときの匿名のひもの目的のために、資格証明書にLDAPDNを含んでいるメカニズムでヌル値(ゼロ長ストリング)を呈するかもしれません。
- authentication: information used to authenticate the name, if any,
provided in the Bind Request.
- 認証: 情報は以前はよくもしあればBind Requestに提供された名前を認証していました。
Upon receipt of a Bind Request, a protocol server will authenticate the requesting client, if necessary. The server will then return a Bind Response to the client indicating the status of the authentication.
必要なら、Bind Requestを受け取り次第、プロトコルサーバは要求しているクライアントを認証するでしょう。 そして、サーバは認証の状態を示すクライアントにBind Responseを返すでしょう。
Authorization is the use of this authentication information when performing operations. Authorization MAY be affected by factors outside of the LDAP Bind request, such as lower layer security services.
操作を実行するとき、承認はこの認証情報の使用です。 承認は下層セキュリティー・サービスなどのLDAP Bind要求における外の要素で影響を受けるかもしれません。
4.2.1. Sequencing of the Bind Request
4.2.1. ひもの要求の配列
For some SASL authentication mechanisms, it may be necessary for the client to invoke the BindRequest multiple times. If at any stage the client wishes to abort the bind process it MAY unbind and then drop the underlying connection. Clients MUST NOT invoke operations between two Bind requests made as part of a multi-stage bind.
いくつかのSASL認証機構に、クライアントが複数の回BindRequestを呼び出すのが必要であるかもしれません。 クライアントがどんな段階でもひものプロセスを中止したいなら、それは、基本的な接続を解いて、下げるかもしれません。 クライアントはマルチステージひもの一部としてされた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ひもの交渉を中止するかもしれません。
If the client sends a BindRequest with the sasl mechanism field as an empty string, the server MUST return a BindResponse with authMethodNotSupported as the resultCode. This will allow clients to abort a negotiation if it wishes to try again with the same SASL mechanism.
クライアントが空のストリングとしてsaslメカニズム分野があるBindRequestを送るなら、サーバはresultCodeとしてauthMethodNotSupportedとBindResponseを返さなければなりません。 これで、同じSASLメカニズムで再試行したいなら、クライアントは交渉を中止できるでしょう。
Unlike LDAP v2, the client need not send a Bind Request in the first PDU of the connection. The client may request any operations and the server MUST treat these as unauthenticated. If the server requires that the client bind before browsing or modifying the directory, the server MAY reject a request other than binding, unbinding or an extended request with the "operationsError" result.
LDAP v2と異なって、クライアントは接続の最初のPDUでBind Requestを送る必要はありません。 クライアントは、どんな操作とサーバも非認証されるようにこれらを扱わなければならないよう要求するかもしれません。 サーバが、ディレクトリをブラウズするか、または変更する前にクライアントが付くのを必要とするなら、サーバは"operationsError"結果で結合、解くことまたは拡張要求以外の要求を拒絶するかもしれません。
Wahl, et. al. Standards Track [Page 21] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[21ページ]RFC2251LDAPv3 December 1997
If the client did not bind before sending a request and receives an operationsError, it may then send a Bind Request. If this also fails or the client chooses not to bind on the existing connection, it will close the connection, reopen it and begin again by first sending a PDU with a Bind Request. This will aid in interoperating with servers implementing other versions of LDAP.
クライアントが要求を送る前に、付かないで、operationsErrorを受け取るなら、それはBind Requestを送るかもしれません。 また、これが失敗するか、またはクライアントが、既存の接続のときに付かないのを選ぶと、それは、Bind RequestとPDUを送りながら、最初にで接続を終えて、それを再開させて、やり直すでしょう。 これはサーバがLDAPの他のバージョンを実装していて共同利用する際に支援されるでしょう。
Clients MAY send multiple bind requests on a connection to change their credentials. A subsequent bind process has the effect of abandoning all operations outstanding on the connection. (This simplifies server implementation.) Authentication from earlier binds are subsequently ignored, and so if the bind fails, the connection will be treated as anonymous. If a SASL transfer encryption or integrity mechanism has been negotiated, and that mechanism does not support the changing of credentials from one identity to another, then the client MUST instead establish a new connection.
クライアントはそれらの資格証明書を変えるという接続に関する複数のひもの要求を送るかもしれません。 その後のひものプロセスは未払いのすべての操作を捨てるという影響を接続に与えます。 (これはサーバ実装を簡素化します。) 以前のひもからの認証が次に無視されるので、ひもが失敗すると、接続は匿名として扱われるでしょう。 SASL転送暗号化か保全メカニズムが交渉されて、そのメカニズムが資格証明書の1つのアイデンティティから別のアイデンティティまでの変化をサポートしないなら、クライアントは代わりに新しい接続を確立しなければなりません。
4.2.2. Authentication and Other Security Services
4.2.2. 認証と他のセキュリティー・サービス
The simple authentication option provides minimal authentication facilities, with the contents of the authentication field consisting only of a cleartext password. Note that the use of cleartext passwords is not recommended over open networks when there is no authentication or encryption being performed by a lower layer; see the "Security Considerations" section.
簡易認証オプションは最小量の認証施設を提供します、認証分野のコンテンツがcleartextパスワードだけから成っていて。 下層によって実行されるどんな認証も暗号化もないとき、cleartextパスワードの使用がオープンネットワークの上で推薦されないことに注意してください。 「セキュリティ問題」セクションを見てください。
If no authentication is to be performed, then the simple authentication option MUST be chosen, and the password be of zero length. (This is often done by LDAPv2 clients.) Typically the DN is also of zero length.
どんな認証も実行されないことであるなら簡易認証オプションを選ばなければなりません、そして、パスワードはゼロ・レングスについて選びます。 (これがしばしばLDAPv2クライアントによって行われます。) DNは通常、またゼロ・レングスについてものです。
The sasl choice allows for any mechanism defined for use with SASL [12]. The mechanism field contains the name of the mechanism. The credentials field contains the arbitrary data used for authentication, inside an OCTET STRING wrapper. Note that unlike some Internet application protocols where SASL is used, LDAP is not text-based, thus no base64 transformations are performed on the credentials.
sasl選択は使用のためにSASL[12]で定義されたどんなメカニズムも考慮します。 メカニズム分野はメカニズムの名前を含んでいます。 資格証明書分野は認証にOCTET STRINGラッパーに使用される任意のデータを含んでいます。 SASLが使用されている、LDAPがテキストベースでない、その結果base64変換が全く資格証明書に実行されないいくつかのインターネットアプリケーション・プロトコルと異なってそれに注意してください。
If any SASL-based integrity or confidentiality services are enabled, they take effect following the transmission by the server and reception by the client of the final BindResponse with resultCode success.
何かSASLベースの保全や秘密性サービスが可能にされるなら、resultCode成功でサーバによるトランスミッションと最終的なBindResponseのクライアントによるレセプションに続いて、それらは効きます。
The client can request that the server use authentication information from a lower layer protocol by using the SASL EXTERNAL mechanism.
クライアントは、サーバがSASL EXTERNALメカニズムを使用することによって下位層プロトコルからの認証情報を使用するよう要求できます。
Wahl, et. al. Standards Track [Page 22] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[22ページ]RFC2251LDAPv3 December 1997
4.2.3. Bind Response
4.2.3. ひもの応答
The Bind Response is defined as follows.
Bind Responseは以下の通り定義されます。
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 he
status of the client's request for authentication.
BindResponseがサーバから単に指示から成る、彼、認証を求めるクライアントの要求の状態。
f the bind was successful, the resultCode will be success, therwise it will be one of:
f、ひもがうまくいった、resultCodeが成功であるために望んでいて、それをtherwiseする、1であるために以下を望んでください。
- operationsError: server encountered an internal error,
- operationsError: サーバは内部エラーに遭遇しました。
- protocolError: unrecognized version number or incorrect PDU
structure,
- protocolError: 認識されていないバージョン番号か不正確なPDU構造
- authMethodNotSupported: unrecognized SASL mechanism name,
- authMethodNotSupported: 認識されていないSASLメカニズム名
- strongAuthRequired: the server requires authentication be
performed with a SASL mechanism,
- strongAuthRequired: サーバが認証を必要とする、SASLメカニズムで、実行されてください。
- referral: this server cannot accept this bind and the client
should try another,
- 紹介: このサーバはこのひもを受け入れることができません、そして、クライアントは別のものを試みるべきです。
- saslBindInProgress: the server requires the client to send a
new bind request, with the same sasl mechanism, to continue the
authentication process,
- saslBindInProgress: サーバは、クライアントが同じsaslメカニズムによる新しいひもの要求を送って、認証過程を続けているのを必要とします。
- inappropriateAuthentication: the server requires the client
which had attempted to bind anonymously or without supplying
credentials to provide some form of credentials,
- inappropriateAuthentication: サーバはクライアントを必要とします(匿名でか何らかのフォームの資格証明書を提供するために資格証明書を供給しないで付くのを試みました)。
- invalidCredentials: the wrong password was supplied or the SASL
credentials could not be processed,
- invalidCredentials: 間違ったパスワードを提供できませんでしたか、SASL資格証明書を処理できませんでした。
- unavailable: the server is shutting down.
- 入手できません: サーバは停止しています。
If the server does not support the client's requested protocol version, it MUST set the resultCode to protocolError.
サーバがクライアントの要求されたプロトコルバージョンをサポートしないなら、それはprotocolErrorにresultCodeを設定しなければなりません。
If the client receives a BindResponse response where the resultCode was protocolError, it MUST close the connection as the server will be unwilling to accept further operations. (This is for compatibility with earlier versions of LDAP, in which the bind was always the first operation, and there was no negotiation.)
クライアントがresultCodeがprotocolErrorであった、それが閉じなければならないところでBindResponse応答を受けると、サーバとしての接続はさらなる操作を受け入れたがっていないでしょう。 (これはいつもひもが最初の操作であったLDAPの以前のバージョンとの互換性のためのものであり、交渉は全くありませんでした。)
Wahl, et. al. Standards Track [Page 23] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[23ページ]RFC2251LDAPv3 December 1997
The serverSaslCreds are 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 password choice, or the SASL mechanism does not require the server to return information to the client, then this field is not to be included in the result.
serverSaslCredsは、クライアントがそれが伝える予定であるサーバを認証するか、または「チャレンジレスポンス」認証を実行するのを許容するのにSASLによって定義されたひものメカニズムの一部として使用されます。 クライアントがパスワード選択で付いたか、またはSASLメカニズムが情報をクライアントに返すためにサーバを必要としないなら、この分野は結果に含まれないことです。
4.3. Unbind Operation
4.3. 操作を解いてください。
The function of the Unbind Operation is to terminate a protocol session. The Unbind Operation is defined as follows:
Unbind Operationの機能はプロトコルセッションを終えることです。 Unbind Operationは以下の通り定義されます:
UnbindRequest ::= [APPLICATION 2] NULL
UnbindRequest:、:= [アプリケーション2] ヌル
The Unbind Operation has no response defined. Upon transmission of an UnbindRequest, a protocol client may assume that the protocol session is terminated. Upon receipt of an UnbindRequest, a protocol server may assume that the requesting client has terminated the session and that all outstanding requests may be discarded, and may close the connection.
Unbind Operationには、定義されなかった応答が全くあります。 UnbindRequestのトランスミッションのときに、プロトコルクライアントは、プロトコルセッションが終えられると仮定するかもしれません。 UnbindRequestを受け取り次第、プロトコルサーバは、すべての傑出している要求が要求しているクライアントがセッションを終えて、捨てられて、接続を終えるかもしれないと仮定するかもしれません。
4.4. Unsolicited Notification
4.4. 求められていない通知
An unsolicited notification is an LDAPMessage sent from the server to the client which 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 connection 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です。それは、クライアントとサーバの間のサーバか接続における並はずれた状態に合図するのに使用されます。通知は顧問に自然です、そして、サーバはどんな応答もクライアントから返されると予想しないでしょう。
The unsolicited notification is structured as an LDAPMessage in which the messageID is 0 and protocolOp is of the extendedResp form. The responseName field of the ExtendedResponse is present. The LDAPOID value MUST be unique for this notification, and not be used in any other situation.
messageIDが0とprotocolOpであるLDAPMessageがextendedRespフォームのものであるときに、求められていない通知は構造化されます。 ExtendedResponseのresponseName分野は存在しています。 LDAPOID値は、この通知にユニークであり、いかなる他の状況でも使用されてはいけません。
One unsolicited notification is defined in this document.
1つの求められていない通知が本書では定義されます。
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 close the connection due to an error condition. Note that this notification is NOT a response to an unbind requested by the client: the server MUST follow the procedures of section 4.3. This notification is intended to assist clients in distinguishing between an error condition and a transient network
この通知はサーバによって使用されて、サーバがエラー条件による接続を終えようとしているとクライアントに忠告するかもしれません。 この通知が応答でないことに注意してください、解く、クライアントによって要求されています: サーバはセクション4.3の手順に従わなければなりません。 この通知がエラー条件と一時的なネットワークを見分けるのにクライアントを助けることを意図します。
Wahl, et. al. Standards Track [Page 24] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[24ページ]RFC2251LDAPv3 December 1997
failure. As with a connection close due to network failure, the client MUST NOT assume that any outstanding requests which modified the directory have succeeded or failed.
失敗。 ネットワーク失敗に接続閉鎖なら、クライアントは、ディレクトリを変更したどんな傑出している要求も成功するか、または失敗したと仮定してはいけません。
The responseName is 1.3.6.1.4.1.1466.20036, the response field is absent, and the resultCode is used to indicate the reason for the disconnection.
responseNameはそうです。1.3 .6 .1 .4 .1 .1466 .20036 応答分野は欠けていて、resultCodeは、断線の理由を示すのに使用されます。
The following resultCode values are to be used in this notification:
以下のresultCode値はこの通知で使用されることです:
- protocolError: The server has received data from the client in
which
the LDAPMessage structure could not be parsed.
- protocolError: サーバはLDAPMessage構造を分析できなかったクライアントからデータを受け取りました。
- strongAuthRequired: The server has detected that an established
underlying security association protecting communication between
the client and server has unexpectedly failed or been compromised.
- strongAuthRequired: サーバはそれを検出しました。クライアントとサーバとのコミュニケーションを保護する設立された基本的なセキュリティ協会は、不意に失敗されるか、または感染されました。
- unavailable: This server will stop accepting new connections and
operations on all existing connections, and be unavailable for an
extended period of time. The client may make use of an alternative
server.
- 入手できません: このサーバは、新しい接続と操作を受け入れるのをすべての既存の接続に止めて、時間の長期間を入手できなくなるでしょう。 クライアントは代替のサーバを利用するかもしれません。
After sending this notice, the server MUST close the connection. After receiving this notice, the client MUST NOT transmit any further on the connection, and may abruptly close the connection.
この通知を送った後に、サーバは接続を終えなければなりません。 この通知を受け取った後に、クライアントは、接続のときにこれ以上伝わってはいけなくて、突然に接続を終えるかもしれません。
4.5. Search Operation
4.5. 索敵行動
The Search Operation allows a client to request that a search be performed on its behalf by a server. This can be used to read attributes from a single entry, from entries immediately below a particular entry, or a whole subtree of entries.
検索Operationは検索がサーバによって利益に実行されるようクライアントを要求させます。単一のエントリーから属性を読むのにこれを使用できます、特定のエントリーのすぐ下のエントリー、またはエントリーの全体の下位木から。
4.5.1. Search Request
4.5.1. 検索要求
The Search Request is defined as follows:
検索Requestは以下の通り定義されます:
SearchRequest ::= [APPLICATION 3] SEQUENCE {
baseObject LDAPDN,
scope ENUMERATED {
baseObject (0),
singleLevel (1),
wholeSubtree (2) },
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
SearchRequest:、:= [APPLICATION3]SEQUENCE、baseObject LDAPDN、範囲ENUMERATED、baseObject(0)、singleLevel(1)、wholeSubtree(2)、derefAliases ENUMERATED、neverDerefAliases(0)、derefInSearching(1)、derefFindingBaseObj(2)
Wahl, et. al. Standards Track [Page 25] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[25ページ]RFC2251LDAPv3 December 1997
derefAlways (3) },
sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt),
typesOnly BOOLEAN,
filter Filter,
attributes AttributeDescriptionList }
derefAlways(3)、sizeLimit INTEGER(0maxInt)、typesOnlyブールであるtimeLimit INTEGER(0maxInt)はFilter、属性AttributeDescriptionListをフィルターにかけます。
Filter ::= CHOICE {
and [0] SET OF Filter,
or [1] SET OF Filter,
not [2] Filter,
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion,
present [7] AttributeDescription,
approxMatch [8] AttributeValueAssertion,
extensibleMatch [9] MatchingRuleAssertion }
以下をフィルターにかけてください:= 選択そして、[2]フィルタ、AttributeValueAssertion(サブストリング[4]SubstringFilter、greaterOrEqual[5]AttributeValueAssertion、lessOrEqual[6]AttributeValueAssertion)が[7]AttributeDescription、approxMatch[8]AttributeValueAssertion、extensibleMatch[9]MatchingRuleAssertionを寄贈するequalityMatch[3]ではなく、[0]SET OF Filter、または[1]SET OF Filter
SubstringFilter ::= SEQUENCE {
type AttributeDescription,
-- at least one must be present
substrings SEQUENCE OF CHOICE {
initial [0] LDAPString,
any [1] LDAPString,
final [2] LDAPString } }
SubstringFilter:、:= 系列AttributeDescriptionをタイプしてください--少なくとも1つは現在のサブストリングSEQUENCE OF CHOICEが[0]LDAPString、どんな[1]LDAPString、決勝[2]LDAPStringにも頭文字をつけるということであるに違いありません。
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
Parameters of the Search Request are:
検索Requestのパラメタは以下の通りです。
- baseObject: An LDAPDN that is the base object entry relative to
which the search is to be performed.
- baseObject: に比例した実行される検索がことであるベースオブジェクトエントリーであるLDAPDN。
- scope: An indicator of the scope of the search to be performed. The
semantics of the possible values of this field are identical to the
semantics of the scope field in the X.511 Search Operation.
- 範囲: 実行されるべき検索の範囲のインディケータ。 この分野の可能な値の意味論はX.511検索Operationの範囲分野の意味論と同じです。
- derefAliases: An indicator as to how alias objects (as defined in
X.501) are to be handled in searching. The semantics of the
possible values of this field are:
- derefAliases: 別名オブジェクト(X.501で定義されるように)が探すことでどう扱われることになっているかに関するインディケータ。 この分野の可能な値の意味論は以下の通りです。
neverDerefAliases: do not dereference aliases in searching
or in locating the base object of the search;
neverDerefAliases: 探すか、または検索のベース目的の場所を見つける際にどんな反参照にも別名をしないでください。
Wahl, et. al. Standards Track [Page 26] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[26ページ]RFC2251LDAPv3 December 1997
derefInSearching: dereference aliases in subordinates of
the base object in searching, but not in locating the
base object of the search;
derefInSearching: ベースオブジェクトの部下の探しますが、検索のベース目的の場所を見つける際に探すというわけではないことにおける反参照別名。
derefFindingBaseObj: dereference aliases in locating
the base object of the search, but not when searching
subordinates of the base object;
derefFindingBaseObj: ベースオブジェクトの部下を身体検査しないとき検索のベース目的の場所を見つけることにおける反参照別名。
derefAlways: dereference aliases both in searching and in
locating the base object of the search.
derefAlways: 探して、検索のベース目的の場所を見つけることにおける反参照別名。
- sizelimit: A sizelimit that restricts the maximum number of entries
to be returned as a result of the search. A value of 0 in this
field indicates that no client-requested sizelimit restrictions are
in effect for the search. Servers may enforce a maximum number of
entries to return.
- sizelimit: 検索の結果、返されるエントリーの最大数を制限するsizelimit。 この分野の0の値は、検索には、どんなクライアントによって要求されたsizelimit制限も有効でないことを示します。 サーバは、戻るために最大数のエントリーを実施するかもしれません。
- timelimit: A timelimit that restricts the maximum time (in seconds)
allowed for a search. A value of 0 in this field indicates that no
client-requested timelimit restrictions are in effect for the
search.
- timelimit: 最大の時間(秒の)を制限するtimelimitは検索を考慮しました。 この分野の0の値は、検索には、どんなクライアントによって要求されたtimelimit制限も有効でないことを示します。
- typesOnly: An indicator as to whether search results will contain
both attribute types and values, or just attribute types. Setting
this field to TRUE causes only attribute types (no values) to be
returned. Setting this field to FALSE causes both attribute types
and values to be returned.
- typesOnly: 検索が結果として生じるかどうかに関するインディケータは属性タイプと値か、まさしく属性タイプの両方を含むでしょう。 この分野をTRUEに設定するのに、属性タイプだけ(値がありません)を返します。 この分野をFALSEに設定するのに、属性タイプと値の両方を返します。
- 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 was explicit.)
フィルタの組み合わせを形成するのに'and'、'or'、および'not'選択を使用できます。 少なくとも1個のフィルタエレメントが'and'か'or'選択で存在していなければなりません。 他のものは検索の範囲のエントリーの個々の属性値に対して合っています。 (作成者の注意: 'not'フィルタはそれとなくタグ付けをされたモジュールにおけるタグ付けをされた選択に関する例です。 BERでは、まるでタグが明白であるかのようにこれは扱われます。)
A server MUST evaluate filters according to the three-valued logic
of X.511(93) section 7.8.1. In summary, a filter is evaluated to
either "TRUE", "FALSE" or "Undefined". If the filter evaluates
to TRUE for a particular entry, then the attributes of that entry
are returned as part of the search result (subject to any applicable
access control restrictions). If the filter evaluates to FALSE or
Undefined, then the entry is ignored for the search.
X.511(93)部7.8の.1の3で評価された論理によると、サーバはフィルタを評価しなければなりません。 概要では、フィルタは「本当で」、「誤る」か「未定義に」評価されます。 フィルタは特定のエントリー(そのエントリーの属性が検索結果(どんな適切なアクセス制御制限を条件とした)の一部として返されるその時)のためにTRUEに評価します。 フィルタはFALSEかUndefined、その時までエントリーを評価します。検索のために、無視されます。
Wahl, et. al. Standards Track [Page 27] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[27ページ]RFC2251LDAPv3 December 1997
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
otherwise Undefined. A filter of the "or" choice is FALSE if all
of 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です。
The present match evaluates to TRUE where there is an attribute or
subtype of the specified attribute description present in an entry,
and FALSE otherwise (including a presence test with an unrecognized
attribute description.)
現在のマッチは、そうでなければ、エントリー、およびFALSEの現在の指定された属性記述の属性か「副-タイプ」がどこにあるかをTRUEに評価します。(認識されていない属性記述による存在テストを含んでいます。)
The extensibleMatch is new in this version of LDAP. If the
matchingRule field is absent, the type field MUST be present, and
the equality match is performed for that type. If the type field is
absent and matchingRule is present, the matchValue is compared
against all attributes in an entry which support that matchingRule,
and the matchingRule determines the syntax for the assertion value
(the filter item evaluates to TRUE if it matches with at least
one attribute in the entry, FALSE if it does not match any attribute
in the entry, and Undefined if the matchingRule is not recognized
or the assertionValue cannot be parsed.) If the type field is
present and matchingRule is present, the matchingRule MUST be one
permitted for use with that type, otherwise the filter item is
undefined. If the dnAttributes field is set to TRUE, the match is
applied against all the attributes in an entry's distinguished name
as well, and also evaluates to TRUE if there is at least one
attribute in the distinguished name for which the filter item
evaluates to TRUE. (Editors note: The dnAttributes field is present
so that there does not need to be multiple versions of generic
matching rules such as for word matching, one to apply to entries
and another to apply to entries and dn attributes as well).
extensibleMatchはLDAPのこのバージョンで新しいです。 matchingRule分野が欠けるなら、タイプ分野は存在していなければなりません、そして、平等マッチはそのタイプのために実行されます。 タイプ分野が欠けていて、matchingRuleが存在していて、matchValueがエントリーにおけるそのmatchingRuleをサポートするすべての属性に対して比較されて、matchingRuleが主張値のために構文を決定するなら(フィルタの品目は、それがエントリーにおける少なくとも1つの属性に合わせるかどうかTRUEに評価して、エントリー、およびUndefinedのmatchingRuleが認識されないか、そして、assertionValueのどんな属性も合わせないなら、FALSEは分析できません。) タイプ分野が存在していて、matchingRuleが存在しているなら、matchingRuleが使用のためにそのタイプで受入れられたものであるに違いない、さもなければ、フィルタの品目は未定義です。 dnAttributes分野がTRUEに設定されるなら、マッチは、また、エントリーの分類名におけるすべての属性に対して申し込まれて、また、分類名で少なくとも1つの属性がフィルタの品目がTRUEに評価するもののためにあるかをTRUEに評価します。 (: dnAttributes分野が存在しているのでするというエディターズメモは、また、エントリーとdn属性に適用するのに単語マッチングや、エントリーに適用する1つや別のものなどのジェネリックマッチング規則の複数のバージョンである必要がありません。)
A filter item evaluates to Undefined when the server would not
be able to determine whether the assertion value matches an
entry. If an attribute description in an equalityMatch, substrings,
greaterOrEqual, lessOrEqual, approxMatch or extensibleMatch
filter is not recognized by the server, a matching rule id in the
extensibleMatch is not recognized by the server, the assertion
value cannot be parsed, or the type of filtering requested is not
implemented, then the filter is Undefined. Thus for example if a
server did not recognize the attribute type shoeSize, a filter of
(shoeSize=*) would evaluate to FALSE, and the filters (shoeSize=12),
(shoeSize>=12) and (shoeSize<=12) would evaluate to Undefined.
フィルタの品目は、サーバが、いつ主張値がエントリーに合っているかどうか決定できないかをUndefinedに評価します。 equalityMatch、サブストリング、greaterOrEqual、lessOrEqual、approxMatchまたはextensibleMatchフィルタの属性記述がサーバによって認識されないか、extensibleMatchの合っている規則イドがサーバによって認識されないか、主張値を分析できないか、または要求されたフィルタリングのタイプが実装されないなら、フィルタはUndefinedです。 例えば、サーバがそうしなかったなら、したがって、shoeSize、(shoeSize=*)のフィルタがFALSEに評価して、フィルタ(shoeSize=12)、(shoeSize>=12)、および(shoeSize<=12)がUndefinedに評価する属性タイプを見分けてください。
Wahl, et. al. Standards Track [Page 28] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[28ページ]RFC2251LDAPv3 December 1997
Servers MUST NOT return errors if attribute descriptions or matching
rule ids are not recognized, or assertion values cannot be parsed.
More details of filter processing are given in section 7.8 of X.511
[8].
属性記述か合っている規則イドを認識しないことができないか、主張値を分析できないなら、サーバは誤りを返してはいけません。 X.511[8]のセクション7.8でフィルタ処理に関するその他の詳細を与えます。
- attributes: A list of the attributes to be returned from each entry
which matches the search filter. There are two special values which
may be used: an empty list with no attributes, and the attribute
description string "*". Both of these signify that all user
attributes are to be returned. (The "*" allows the client to
request all user attributes in addition to specific operational
attributes).
- 属性: 検索フィルタに合っている各エントリーから返される属性のリスト。 使用されるかもしれない2つの特別な値があります: 記述ストリング「*」という属性、および属性のない空のリスト。 これらの両方が、すべてのユーザ属性が返されることであることを意味します。 (「*」で、クライアントは特定の操作上の属性に加えたすべてのユーザ属性を要求できます。)
Attributes MUST be named at most once in the list, and are returned
at most once in an entry. If there are attribute descriptions in
the list which are not recognized, they are ignored by the server.
属性は、リストで高々一度命名しなければならなくて、エントリーで高々一度返されます。 リストにおける認識されない属性記述があれば、それらはサーバによって無視されます。
If the client does not want any attributes returned, it can specify
a list containing only the attribute with OID "1.1". This OID was
chosen arbitrarily and does not correspond to any attribute in use.
クライアントがどんな属性も返して欲しくないなら、それはOIDと共に属性だけを含むリストを「1.1インチ」指定できます。 このOIDは任意に選ばれて、使用中のどんな属性にも対応していません。
Client implementors should note that even if all user attributes are
requested, some attributes of the entry may not be included in
search results due to access control or other restrictions.
Furthermore, servers will not return operational attributes, such
as objectClasses or attributeTypes, unless they are listed by name,
since there may be extremely large number of values for certain
operational attributes. (A list of operational attributes for use
in LDAP is given in [5].)
クライアント作成者は、すべてのユーザ属性が要求されても、エントリーのいくつかの属性がアクセスコントロールか他の制限のため検索結果に含まれないかもしれないことに注意するべきです。 その上、サーバは操作上の属性を返さないでしょう、objectClassesやattributeTypesのように、彼らが名前によって記載されない場合、ある操作上の属性のための非常に多くの値があるかもしれないので。 ([5]でLDAPにおける使用のための操作上の属性のリストを与えます。)
Note that an X.500 "list"-like operation can be emulated by the client requesting a one-level LDAP search operation with a filter checking for the existence of the objectClass attribute, and that an X.500 "read"-like operation can be emulated by a base object LDAP search operation with the same filter. A server which 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 must provide the same semantics as the X.500 search operation.
フィルタがobjectClass属性の存在がないかどうかチェックしている状態で1レベルのLDAP索敵行動を要求するクライアントがX.500の「リスト」のような操作を見習うことができて、同じフィルタによるベースオブジェクトLDAP索敵行動でX.500の「読み」のような操作を見習うことができることに注意してください。 X.500へのゲートウェイを提供するサーバはReadかList操作を使用するのに必要でなく、選ぶかもしれませんが、そのように、そうするならX.500索敵行動と同じ意味論を前提としなければなりません。
4.5.2. Search Result
4.5.2. 検索結果
The results of the search attempted by the server upon receipt of a Search Request are returned in Search Responses, which are LDAP messages containing either SearchResultEntry, SearchResultReference, ExtendedResponse or SearchResultDone data types.
検索Requestを受け取り次第サーバによって試みられた検索の結果は検索Responsesで返されます。(ResponsesはSearchResultEntry、SearchResultReference、ExtendedResponseまたはSearchResultDoneデータ型を含むLDAPメッセージです)。
SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
objectName LDAPDN,
SearchResultEntry:、:= [アプリケーション4]系列、objectName LDAPDN
Wahl, et. al. Standards Track [Page 29] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[29ページ]RFC2251LDAPv3 December 1997
attributes PartialAttributeList }
属性PartialAttributeList
PartialAttributeList ::= SEQUENCE OF SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
-- implementors should note that the PartialAttributeList may
-- have zero elements (if none of the attributes of that entry
-- were requested, or could be returned), and that the vals set
-- may also have zero elements (if types only was requested, or
-- all values were excluded from the result.)
PartialAttributeList:、:= SEQUENCE OF SEQUENCEはAttributeDescription、vals SET OF AttributeValueをタイプします--作成者はPartialAttributeListはそうするかもしれません--零元を持ってください(そのエントリーの属性のいずれか--でない要求したか、または返すかもしれないなら)、valsがセットしたことに注意するべきです--また、零元を持っているかもしれません。または、(タイプだけが要求されたなら--すべての値が結果から除かれた、)
SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL
-- at least one LDAPURL element must be present
SearchResultReference:、:= [APPLICATION19]SEQUENCE OF LDAPURL--少なくとも1つのLDAPURL要素が存在していなければなりません。
SearchResultDone ::= [APPLICATION 5] LDAPResult
SearchResultDone:、:= [アプリケーション5] LDAPResult
Upon receipt of a Search Request, a server will perform the necessary search of the DIT.
検索Requestを受け取り次第、サーバはDITの必要な検索を実行するでしょう。
If the LDAP session is operating over a connection-oriented transport such as TCP, the server will return to the client a sequence of responses in separate LDAP messages. There may be zero or more responses containing SearchResultEntry, one for each entry found during the search. There may also be zero or more responses containing SearchResultReference, one for each area not explored by this server during the search. The SearchResultEntry and SearchResultReference PDUs may come in any order. Following all the SearchResultReference responses and all SearchResultEntry responses to be returned by the server, the server will return a response containing the SearchResultDone, which contains an indication of success, or detailing any errors that have occurred.
LDAPセッションがTCPなどの接続指向の輸送の上で作動していると、サーバは別々のLDAPメッセージの応答の系列をクライアントに返すでしょう。 SearchResultEntry、検索の間に見つけられた各エントリーあたり1つを含むゼロか、より多くの応答があるかもしれません。 また、ゼロがあったかもしれませんか、またはSearchResultReference、各領域あたり1つを含むより多くの応答が検索の間、このサーバによって探検されませんでした。 SearchResultEntryとSearchResultReference PDUsは順不同に来るかもしれません。 サーバによって返されるすべてのSearchResultReference応答とすべてのSearchResultEntry応答に続いて、サーバは成功のしるしを含むSearchResultDoneを含んでいるか、または発生したどんな誤りも詳しく述べる応答を返すでしょう。
Each entry returned in a SearchResultEntry will contain all attributes, complete with associated values if necessary, as specified in the attributes field of the Search Request. Return of attributes is subject to access control and other administrative policy. Some attributes may be returned in binary format (indicated by the AttributeDescription in the response having the binary option present).
必要なら、SearchResultEntryで返された各エントリーは関連値で完全なすべての属性を含むでしょう、検索Requestの属性分野で指定されるように。 属性の復帰はアクセスコントロールと他の施政方針を受けることがあります。 いくつかの属性がバイナリフォーマット(2進のオプションプレゼントを持っている応答でAttributeDescriptionによって示される)で返されるかもしれません。
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 MUST NOT assume that all attributes can be modified, even if permitted by access control.
いくつかの属性が、サーバによって構成されて、SearchResultEntry属性リストに現れるかもしれません、それらはエントリーの保存された属性ではありませんが。 アクセスコントロールで受入れられても、クライアントは、すべての属性を変更できると仮定してはいけません。
LDAPMessage responses of the ExtendedResponse form are reserved for returning information associated with a control requested by the client. These may be defined in future versions of this document.
ExtendedResponse形式のLDAPMessage応答はクライアントによって要求されているコントロールに関連している返品情報のために控えられます。 これらはこのドキュメントの将来のバージョンで定義されるかもしれません。
Wahl, et. al. Standards Track [Page 30] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[30ページ]RFC2251LDAPv3 December 1997
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 to search all the entries in the scope at and under the baseObject, the server may return one or more SearchResultReference, each containing a reference to another set of servers for continuing the operation. A server MUST NOT return any SearchResultReference if it has not located the baseObject and thus has not searched any entries; in this case it would return a SearchResultDone containing a referral resultCode.
If the server was able to locate the entry referred to by the baseObject but was unable to search all the entries in the scope at and under the baseObject, the server may return one or more SearchResultReference, each containing a reference to another set of servers for continuing the operation. A server MUST NOT return any SearchResultReference if it has not located the baseObject and thus has not searched any entries; in this case it would return a SearchResultDone containing a referral resultCode.
In the absence of indexing information provided to a server from servers holding subordinate naming contexts, SearchResultReference responses are not affected by search filters and are always returned when in scope.
In the absence of indexing information provided to a server from servers holding subordinate naming contexts, SearchResultReference responses are not affected by search filters and are always returned when in scope.
The SearchResultReference is of the same data type as the Referral. URLs for servers implementing the LDAP protocol are written according to [9]. The <dn> part MUST be present in the URL, with the new target object name. The client MUST use this name in its next request. Some servers (e.g. part of a distributed index exchange system) may provide a different filter in the URLs of the SearchResultReference. If the filter part of the URL is present in an LDAP URL, the client MUST use the new filter in its next request to progress the search, and if the filter part is absent the client will use again the same filter. Other aspects of the new search request may be the same or different as the search which generated the continuation references.
The SearchResultReference is of the same data type as the Referral. URLs for servers implementing the LDAP protocol are written according to [9]. The <dn> part MUST be present in the URL, with the new target object name. The client MUST use this name in its next request. Some servers (e.g. part of a distributed index exchange system) may provide a different filter in the URLs of the SearchResultReference. If the filter part of the URL is present in an LDAP URL, the client MUST use the new filter in its next request to progress the search, and if the filter part is absent the client will use again the same filter. Other aspects of the new search request may be the same or different as the search which generated the continuation references.
Other kinds of URLs may be returned so long as the operation could be performed using that protocol.
Other kinds of URLs may be returned so long as the operation could be performed using that protocol.
The name of an unexplored subtree in a SearchResultReference need not be subordinate to the base object.
The name of an unexplored subtree in a SearchResultReference need not be subordinate to the base object.
In order to complete the search, the client MUST issue a new search operation for each SearchResultReference that is returned. Note that the abandon operation described in section 4.11 applies only to a particular operation sent on a connection between a client and server, and if the client has multiple outstanding search operations to different servers, it MUST abandon each operation individually.
In order to complete the search, the client MUST issue a new search operation for each SearchResultReference that is returned. Note that the abandon operation described in section 4.11 applies only to a particular operation sent on a connection between a client and server, and if the client has multiple outstanding search operations to different servers, it MUST abandon each operation individually.
4.5.3.1. Example
4.5.3.1. Example
For example, suppose the contacted server (hosta) holds the entry "O=MNN,C=WW" and the entry "CN=Manager,O=MNN,C=WW". It knows that either LDAP-capable servers (hostb) or (hostc) hold "OU=People,O=MNN,C=WW" (one is the master and the other server a
For example, suppose the contacted server (hosta) holds the entry "O=MNN,C=WW" and the entry "CN=Manager,O=MNN,C=WW". It knows that either LDAP-capable servers (hostb) or (hostc) hold "OU=People,O=MNN,C=WW" (one is the master and the other server a
Wahl, et. al. Standards Track [Page 31] RFC 2251 LDAPv3 December 1997
Wahl, et. al. Standards Track [Page 31] RFC 2251 LDAPv3 December 1997
shadow), and that LDAP-capable server (hostd) holds the subtree "OU=Roles,O=MNN,C=WW". If a subtree search of "O=MNN,C=WW" is requested to the contacted server, it may return the following:
shadow), and that LDAP-capable server (hostd) holds the subtree "OU=Roles,O=MNN,C=WW". If a subtree search of "O=MNN,C=WW" is requested to the contacted server, it may return the following:
SearchResultEntry for O=MNN,C=WW
SearchResultEntry for CN=Manager,O=MNN,C=WW
SearchResultReference {
ldap://hostb/OU=People,O=MNN,C=WW
ldap://hostc/OU=People,O=MNN,C=WW
}
SearchResultReference {
ldap://hostd/OU=Roles,O=MNN,C=WW
}
SearchResultDone (success)
SearchResultEntry for O=MNN,C=WW SearchResultEntry for CN=Manager,O=MNN,C=WW SearchResultReference { ldap://hostb/OU=People,O=MNN,C=WW ldap://hostc/OU=People,O=MNN,C=WW } SearchResultReference { ldap://hostd/OU=Roles,O=MNN,C=WW } SearchResultDone (success)
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 for the subtree "OU=People,O=MNN,C=WW", the server might respond as follows:
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 for the subtree "OU=People,O=MNN,C=WW", the server might respond as follows:
SearchResultEntry for OU=People,O=MNN,C=WW
SearchResultReference {
ldap://hoste/OU=Managers,OU=People,O=MNN,C=WW
}
SearchResultReference {
ldap://hostf/OU=Consultants,OU=People,O=MNN,C=WW
}
SearchResultDone (success)
SearchResultEntry for OU=People,O=MNN,C=WW SearchResultReference { ldap://hoste/OU=Managers,OU=People,O=MNN,C=WW } SearchResultReference { ldap://hostf/OU=Consultants,OU=People,O=MNN,C=WW } SearchResultDone (success)
If the contacted server does not hold the base object for the search, then it will return a referral to the client. For example, if the client requests a subtree search of "O=XYZ,C=US" to hosta, the server may return only a SearchResultDone containing a referral.
If the contacted server does not hold the base object for the search, then it will return a referral to the client. For example, if the client requests a subtree search of "O=XYZ,C=US" to hosta, the server may return only a SearchResultDone containing a referral.
SearchResultDone (referral) {
ldap://hostg/
}
SearchResultDone (referral) { ldap://hostg/ }
4.6. Modify Operation
4.6. Modify Operation
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:
The Modify Operation allows a client to request that a modification of an entry be performed on its behalf by a server. The Modify Request is defined as follows:
ModifyRequest ::= [APPLICATION 6] SEQUENCE {
object LDAPDN,
modification SEQUENCE OF SEQUENCE {
ModifyRequest ::= [APPLICATION 6] SEQUENCE { object LDAPDN, modification SEQUENCE OF SEQUENCE {
Wahl, et. al. Standards Track [Page 32] RFC 2251 LDAPv3 December 1997
Wahl, et. al. Standards Track [Page 32] RFC 2251 LDAPv3 December 1997
operation ENUMERATED {
add (0),
delete (1),
replace (2) },
modification AttributeTypeAndValues } }
operation ENUMERATED { add (0), delete (1), replace (2) }, modification AttributeTypeAndValues } }
AttributeTypeAndValues ::= SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
AttributeTypeAndValues ::= SEQUENCE { type AttributeDescription, vals SET OF AttributeValue }
Parameters of the Modify Request are:
Parameters of the Modify Request are:
- object: The object to be modified. The value of this field contains
the DN of the entry to be modified. The server will not perform
any alias dereferencing in determining the object to be modified.
- object: The object to be modified. The value of this field contains the DN of the entry to be modified. The server will not perform any alias dereferencing in determining the object to be modified.
- modification: A list of modifications to be performed on the entry.
The entire list of entry modifications MUST be performed
in the order they are listed, as a single atomic operation. While
individual modifications may violate the directory schema, the
resulting entry after the entire list of modifications is performed
MUST conform to the requirements of the directory schema. The
values that may be taken on by the 'operation' field in each
modification construct have the following semantics respectively:
- modification: A list of modifications to be performed on the entry. The entire list of entry modifications MUST be performed in the order they are listed, as a single atomic operation. While individual modifications may violate the directory schema, the resulting entry after the entire list of modifications is performed MUST conform to the requirements of the directory schema. The values that may be taken on by the 'operation' field in each modification construct have the following semantics respectively:
add: add values listed to the given attribute, creating
the attribute if necessary;
add: add values listed to the given attribute, creating the attribute if necessary;
delete: delete values listed from the given attribute,
removing the entire attribute if no values are listed, or
if all current values of the attribute are listed for
deletion;
delete: delete values listed from the given attribute, removing the entire attribute if no values are listed, or if all current values of the attribute are listed for deletion;
replace: replace all existing values of the given 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 is ignored if the
attribute does not exist.
replace: replace all existing values of the given 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 is ignored if the attribute does not exist.
The result of the modify attempted by the server upon receipt of a Modify Request is returned in a Modify Response, defined as follows:
The result of the modify attempted by the server upon receipt of a Modify Request is returned in a Modify Response, defined as follows:
ModifyResponse ::= [APPLICATION 7] LDAPResult
ModifyResponse ::= [APPLICATION 7] LDAPResult
Upon receipt of a Modify Request, a server will perform the necessary modifications to the DIT.
Upon receipt of a Modify Request, a server will perform the necessary modifications to the DIT.
Wahl, et. al. Standards Track [Page 33] RFC 2251 LDAPv3 December 1997
Wahl, et. al. Standards Track [Page 33] RFC 2251 LDAPv3 December 1997
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. Note that 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. If the connection fails, whether the modification occurred or not is indeterminate.
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. Note that 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. If the connection fails, whether the modification occurred or not is indeterminate.
The Modify Operation cannot be used to remove from an entry any of its distinguished values, those values which form the entry's relative distinguished name. An attempt to do so will result in the server returning the error notAllowedOnRDN. The Modify DN Operation described in section 4.9 is used to rename an entry.
The Modify Operation cannot be used to remove from an entry any of its distinguished values, those values which form the entry's relative distinguished name. An attempt to do so will result in the server returning the error notAllowedOnRDN. The Modify DN Operation described in section 4.9 is used to rename an entry.
If an equality match filter has not been defined for an attribute type, clients MUST NOT attempt to delete individual values of that attribute from an entry using the "delete" form of a modification, and MUST instead use the "replace" form.
If an equality match filter has not been defined for an attribute type, clients MUST NOT attempt to delete individual values of that attribute from an entry using the "delete" form of a modification, and MUST instead use the "replace" form.
Note that due to the simplifications made in LDAP, there is not a direct mapping of the modifications in an LDAP ModifyRequest onto the EntryModifications of a DAP ModifyEntry operation, and different implementations of LDAP-DAP gateways may use different means of representing the change. If successful, the final effect of the operations on the entry MUST be identical.
Note that due to the simplifications made in LDAP, there is not a direct mapping of the modifications in an LDAP ModifyRequest onto the EntryModifications of a DAP ModifyEntry operation, and different implementations of LDAP-DAP gateways may use different means of representing the change. If successful, the final effect of the operations on the entry MUST be identical.
4.7. Add Operation
4.7. Add Operation
The Add Operation allows a client to request the addition of an entry into the directory. The Add Request is defined as follows:
The Add Operation allows a client to request the addition of an entry into the directory. The Add Request is defined as follows:
AddRequest ::= [APPLICATION 8] SEQUENCE {
entry LDAPDN,
attributes AttributeList }
AddRequest ::= [APPLICATION 8] SEQUENCE { entry LDAPDN, attributes AttributeList }
AttributeList ::= SEQUENCE OF SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
AttributeList ::= SEQUENCE OF SEQUENCE { type AttributeDescription, vals SET OF AttributeValue }
Parameters of the Add Request are:
Parameters of the Add Request are:
- entry: the Distinguished Name of the entry to be added. Note that
the server will not dereference any aliases in locating the entry
to be added.
- entry: the Distinguished Name of the entry to be added. Note that the server will not dereference any aliases in locating the entry to be added.
Wahl, et. al. Standards Track [Page 34] RFC 2251 LDAPv3 December 1997
Wahl, et. al. Standards Track [Page 34] RFC 2251 LDAPv3 December 1997
- attributes: the list of attributes that make up the content of the
entry being added. Clients MUST include distinguished values
(those forming the entry's own RDN) in this list, the objectClass
attribute, and values of any mandatory attributes of the listed
object classes. Clients MUST NOT supply the createTimestamp or
creatorsName attributes, since these will be generated
automatically by the server.
- attributes: the list of attributes that make up the content of the entry being added. Clients MUST include distinguished values (those forming the entry's own RDN) in this list, the objectClass attribute, and values of any mandatory attributes of the listed object classes. Clients MUST NOT supply the createTimestamp or creatorsName attributes, since these will be generated automatically by the server.
The entry named in the entry field of the AddRequest MUST NOT exist for the AddRequest to succeed. The parent of the entry to be added MUST exist. For example, if the client attempted to add "CN=JS,O=Foo,C=US", the "O=Foo,C=US" entry did not exist, and the "C=US" entry did exist, then the server would return the error noSuchObject with the matchedDN field containing "C=US". If the parent entry exists but is not in a naming context held by the server, the server SHOULD return a referral to the server holding the parent entry.
The entry named in the entry field of the AddRequest MUST NOT exist for the AddRequest to succeed. The parent of the entry to be added MUST exist. For example, if the client attempted to add "CN=JS,O=Foo,C=US", the "O=Foo,C=US" entry did not exist, and the "C=US" entry did exist, then the server would return the error noSuchObject with the matchedDN field containing "C=US". If the parent entry exists but is not in a naming context held by the server, the server SHOULD return a referral to the server holding the parent entry.
Servers implementations SHOULD NOT restrict where entries can be located in the directory. Some servers MAY allow the administrator to restrict the classes of entries which can be added to the directory.
Servers implementations SHOULD NOT restrict where entries can be located in the directory. Some servers MAY allow the administrator to restrict the classes of entries which can be added to the directory.
Upon receipt of an Add Request, a server will attempt to perform the add requested. The result of the add attempt will be returned to the client in the Add Response, defined as follows:
Upon receipt of an Add Request, a server will attempt to perform the add requested. The result of the add attempt will be returned to the client in the Add Response, defined as follows:
AddResponse ::= [APPLICATION 9] LDAPResult
AddResponse ::= [APPLICATION 9] LDAPResult
A response of success indicates that the new entry is present in the directory.
A response of success indicates that the new entry is present in the directory.
4.8. Delete Operation
4.8. Delete Operation
The Delete Operation allows a client to request the removal of an entry from the directory. The Delete Request is defined as follows:
The Delete Operation allows a client to request the removal of an entry from the directory. The Delete Request is defined as follows:
DelRequest ::= [APPLICATION 10] LDAPDN
DelRequest ::= [APPLICATION 10] LDAPDN
The Delete Request consists of the Distinguished Name of the entry to be deleted. Note that the server will not dereference aliases while resolving the name of the target entry to be removed, and that only leaf entries (those with no subordinate entries) can be deleted with this operation.
The Delete Request consists of the Distinguished Name of the entry to be deleted. Note that the server will not dereference aliases while resolving the name of the target entry to be removed, and that only leaf entries (those with no subordinate entries) can be deleted with this operation.
The result of the delete attempted by the server upon receipt of a Delete Request is returned in the Delete Response, defined as follows:
The result of the delete attempted by the server upon receipt of a Delete Request is returned in the Delete Response, defined as follows:
Wahl, et. al. Standards Track [Page 35] RFC 2251 LDAPv3 December 1997
Wahl, et. al. Standards Track [Page 35] RFC 2251 LDAPv3 December 1997
DelResponse ::= [APPLICATION 11] LDAPResult
DelResponse ::= [APPLICATION 11] LDAPResult
Upon receipt of a Delete Request, a server will attempt to perform the entry removal requested. The result of the delete attempt will be returned to the client in the Delete Response.
Upon receipt of a Delete Request, a server will attempt to perform the entry removal requested. The result of the delete attempt will be returned to the client in the Delete Response.
4.9. Modify DN Operation
4.9. Modify DN Operation
The Modify DN Operation allows a client to change the leftmost (least significant) component of the name of an entry in the directory, or to move a subtree of entries to a new location in the directory. The Modify DN Request is defined as follows:
The Modify DN Operation allows a client to change the leftmost (least significant) component of the name of an entry in the directory, or to move a subtree of entries to a new location in the directory. The Modify DN Request is defined as follows:
ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
entry LDAPDN,
newrdn RelativeLDAPDN,
deleteoldrdn BOOLEAN,
newSuperior [0] LDAPDN OPTIONAL }
ModifyDNRequest ::= [APPLICATION 12] SEQUENCE { entry LDAPDN, newrdn RelativeLDAPDN, deleteoldrdn BOOLEAN, newSuperior [0] LDAPDN OPTIONAL }
Parameters of the Modify DN Request are:
Parameters of the Modify DN Request are:
- entry: the Distinguished Name of the entry to be changed. This
entry may or may not have subordinate entries.
- entry: the Distinguished Name of the entry to be changed. This entry may or may not have subordinate entries.
- newrdn: the RDN that will form the leftmost component of the new
name of the entry.
- newrdn: the RDN that will form the leftmost component of the new name of the entry.
- deleteoldrdn: a boolean parameter that controls whether the old RDN
attribute values are to be retained as attributes of the entry, or
deleted from the entry.
- deleteoldrdn: a boolean parameter that controls whether the old RDN attribute values are to be retained as attributes of the entry, or deleted from the entry.
- newSuperior: if present, this is the Distinguished Name of the entry
which becomes the immediate superior of the existing entry.
- newSuperior: if present, this is the Distinguished Name of the entry which becomes the immediate superior of the existing entry.
The result of the name change attempted by the server upon receipt of a Modify DN Request is returned in the Modify DN Response, defined as follows:
The result of the name change attempted by the server upon receipt of a Modify DN Request is returned in the Modify DN Response, defined as follows:
ModifyDNResponse ::= [APPLICATION 13] LDAPResult
ModifyDNResponse ::= [APPLICATION 13] LDAPResult
Upon receipt of a ModifyDNRequest, a server will attempt to perform the name change. The result of the name change attempt will be returned to the client in the Modify DN Response.
Upon receipt of a ModifyDNRequest, a server will attempt to perform the name change. The result of the name change attempt will be returned to the client in the Modify DN Response.
For example, if the entry named in the "entry" parameter was "cn=John Smith,c=US", the newrdn parameter was "cn=John Cougar Smith", and the newSuperior parameter was absent, then this operation would
For example, if the entry named in the "entry" parameter was "cn=John Smith,c=US", the newrdn parameter was "cn=John Cougar Smith", and the newSuperior parameter was absent, then this operation would
Wahl, et. al. Standards Track [Page 36] RFC 2251 LDAPv3 December 1997
Wahl, et. al. Standards Track [Page 36] RFC 2251 LDAPv3 December 1997
attempt to rename the entry to be "cn=John Cougar Smith,c=US". If there was already an entry with that name, the operation would fail with error code entryAlreadyExists.
attempt to rename the entry to be "cn=John Cougar Smith,c=US". If there was already an entry with that name, the operation would fail with error code entryAlreadyExists.
If the deleteoldrdn parameter is TRUE, the values forming the old RDN are deleted from the entry. If the deleteoldrdn parameter is FALSE, the values forming the old RDN will be retained as non-distinguished attribute values of the entry. The server may not perform the operation and return an error code if the setting of the deleteoldrdn parameter would cause a schema inconsistency in the entry.
If the deleteoldrdn parameter is TRUE, the values forming the old RDN are deleted from the entry. If the deleteoldrdn parameter is FALSE, the values forming the old RDN will be retained as non-distinguished attribute values of the entry. The server may not perform the operation and return an error code if the setting of the deleteoldrdn parameter would cause a schema inconsistency in the entry.
Note that X.500 restricts the ModifyDN operation to only affect entries that are contained within a single server. If the LDAP server is mapped onto DAP, then this restriction will apply, and the resultCode affectsMultipleDSAs 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.
Note that X.500 restricts the ModifyDN operation to only affect entries that are contained within a single server. If the LDAP server is mapped onto DAP, then this restriction will apply, and the resultCode affectsMultipleDSAs 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.
4.10. Compare Operation
4.10. Compare Operation
The Compare Operation allows a client to compare an assertion provided with an entry in the directory. The Compare Request is defined as follows:
The Compare Operation allows a client to compare an assertion provided with an entry in the directory. The Compare Request is defined as follows:
CompareRequest ::= [APPLICATION 14] SEQUENCE {
entry LDAPDN,
ava AttributeValueAssertion }
CompareRequest ::= [APPLICATION 14] SEQUENCE { entry LDAPDN, ava AttributeValueAssertion }
Parameters of the Compare Request are:
Parameters of the Compare Request are:
- entry: the name of the entry to be compared with.
- entry: the name of the entry to be compared with.
- ava: the assertion with which an attribute in the entry is to be
compared.
- ava: the assertion with which an attribute in the entry is to be compared.
The result of the compare attempted by the server upon receipt of a Compare Request is returned in the Compare Response, defined as follows:
The result of the compare attempted by the server upon receipt of a Compare Request is returned in the Compare Response, defined as follows:
CompareResponse ::= [APPLICATION 15] LDAPResult
CompareResponse ::= [APPLICATION 15] LDAPResult
Upon receipt of a Compare Request, a server will attempt to perform the requested comparison. The result of the comparison will be returned to the client in the Compare Response. Note that errors and the result of comparison are all returned in the same construct.
Upon receipt of a Compare Request, a server will attempt to perform the requested comparison. The result of the comparison will be returned to the client in the Compare Response. Note that errors and the result of comparison are all returned in the same construct.
Wahl, et. al. Standards Track [Page 37] RFC 2251 LDAPv3 December 1997
Wahl, et. al. Standards Track [Page 37] RFC 2251 LDAPv3 December 1997
Note that some directory systems may establish access controls which permit the values of certain attributes (such as userPassword) to be compared but not read. In a search result, it may be that an attribute of that type would be returned, but with an empty set of values.
Note that some directory systems may establish access controls which permit the values of certain attributes (such as userPassword) to be compared but not read. In a search result, it may be that an attribute of that type would be returned, but with an empty set of values.
4.11. Abandon Operation
4.11. Abandon Operation
The function of the Abandon Operation is to allow a client to request that the server abandon an outstanding operation. The Abandon Request is defined as follows:
The function of the Abandon Operation is to allow a client to request that the server abandon an outstanding operation. The Abandon Request is defined as follows:
AbandonRequest ::= [APPLICATION 16] MessageID
AbandonRequest ::= [APPLICATION 16] MessageID
The MessageID MUST be that of a an operation which was requested earlier in this connection.
The MessageID MUST be that of a an operation which was requested earlier in this connection.
(The abandon request itself has its own message id. This is distinct
from the id of the earlier operation being abandoned.)
(The abandon request itself has its own message id. This is distinct from the id of the earlier operation being abandoned.)
There is no response defined in the Abandon Operation. Upon transmission of an Abandon Operation, a client may expect that the operation identified by the Message ID in the Abandon Request has been abandoned. 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 MUST NOT send the SearchResponseDone. Of course, the server MUST ensure that only properly encoded LDAPMessage PDUs are transmitted.
There is no response defined in the Abandon Operation. Upon transmission of an Abandon Operation, a client may expect that the operation identified by the Message ID in the Abandon Request has been abandoned. 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 MUST NOT send the SearchResponseDone. Of course, the server MUST ensure that only properly encoded LDAPMessage PDUs are transmitted.
Clients MUST NOT send abandon requests for the same operation multiple times, and MUST also be prepared to receive results from operations it has abandoned (since these may have been in transit when the abandon was requested).
Clients MUST NOT send abandon requests for the same operation multiple times, and MUST also be prepared to receive results from operations it has abandoned (since these may have been in transit when the abandon was requested).
Servers MUST discard abandon requests for message IDs they do not recognize, for operations which cannot be abandoned, and for operations which have already been abandoned.
Servers MUST discard abandon requests for message IDs they do not recognize, for operations which cannot be abandoned, and for operations which have already been abandoned.
4.12. Extended Operation
4.12. Extended Operation
An extension mechanism has been added in this version of LDAP, in order to allow additional operations to be defined for services not available elsewhere in this protocol, for instance digitally signed operations and results.
An extension mechanism has been added in this version of LDAP, in order to allow additional operations to be defined for services not available elsewhere in this protocol, for instance digitally signed operations and results.
Wahl, et. al. Standards Track [Page 38] RFC 2251 LDAPv3 December 1997
Wahl, et. al. Standards Track [Page 38] RFC 2251 LDAPv3 December 1997
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. Each request MUST have a unique OBJECT IDENTIFIER assigned to it.
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. Each request MUST have a unique OBJECT IDENTIFIER assigned to it.
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING OPTIONAL }
ExtendedRequest ::= [APPLICATION 23] SEQUENCE { requestName [0] LDAPOID, requestValue [1] OCTET STRING OPTIONAL }
The requestName is a dotted-decimal representation of the OBJECT IDENTIFIER corresponding to the request. The requestValue is information in a form defined by that request, encapsulated inside an OCTET STRING.
The requestName is a dotted-decimal representation of the OBJECT IDENTIFIER corresponding to the request. The requestValue is information in a form defined by that request, encapsulated inside an OCTET STRING.
The server will respond to this with an LDAPMessage containing the ExtendedResponse.
The server will respond to this with an LDAPMessage containing the ExtendedResponse.
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS OF LDAPResult,
responseName [10] LDAPOID OPTIONAL,
response [11] OCTET STRING OPTIONAL }
ExtendedResponse ::= [APPLICATION 24] SEQUENCE { COMPONENTS OF LDAPResult, responseName [10] LDAPOID OPTIONAL, response [11] OCTET STRING OPTIONAL }
If the server does not recognize the request name, it MUST return only the response fields from LDAPResult, containing the protocolError result code.
If the server does not recognize the request name, it MUST return only the response fields from LDAPResult, containing the protocolError result code.
5. Protocol Element Encodings and Transfer
5. Protocol Element Encodings and Transfer
One underlying service is defined here. Clients and servers SHOULD implement the mapping of LDAP over TCP described in 5.2.1.
One underlying service is defined here. Clients and servers SHOULD implement the mapping of LDAP over TCP described in 5.2.1.
5.1. Mapping Onto BER-based Transport Services
5.1. Mapping Onto BER-based Transport Services
The protocol elements of LDAP are encoded for exchange using the Basic Encoding Rules (BER) [11] of ASN.1 [3]. However, due to the high overhead involved in using certain elements of the BER, the following additional restrictions are placed on BER-encodings of LDAP protocol elements:
The protocol elements of LDAP are encoded for exchange using the Basic Encoding Rules (BER) [11] of ASN.1 [3]. However, due to the high overhead involved in using certain elements of the BER, the following additional restrictions are placed on BER-encodings of LDAP protocol elements:
(1) Only the definite form of length encoding will be used.
(1) Only the definite form of length encoding will be used.
(2) OCTET STRING values will be encoded in the primitive form only.
(2) OCTET STRING values will be encoded in the primitive form only.
(3) If the value of a BOOLEAN type is true, the encoding MUST have
its contents octets set to hex "FF".
(3) If the value of a BOOLEAN type is true, the encoding MUST have its contents octets set to hex "FF".
Wahl, et. al. Standards Track [Page 39] RFC 2251 LDAPv3 December 1997
Wahl, et. al. Standards Track [Page 39] RFC 2251 LDAPv3 December 1997
(4) If a value of a type is its default value, it MUST be absent.
Only some BOOLEAN and INTEGER types have default values in this
protocol definition.
(4) If a value of a type is its default value, it MUST be absent. Only some BOOLEAN and INTEGER types have default values in this protocol definition.
These restrictions do not apply to ASN.1 types encapsulated inside of OCTET STRING values, such as attribute values, unless otherwise noted.
These restrictions do not apply to ASN.1 types encapsulated inside of OCTET STRING values, such as attribute values, unless otherwise noted.
5.2. Transfer Protocols
5.2. Transfer Protocols
This protocol is designed to run over connection-oriented, reliable transports, with all 8 bits in an octet being significant in the data stream.
This protocol is designed to run over connection-oriented, reliable transports, with all 8 bits in an octet being significant in the data stream.
5.2.1. Transmission Control Protocol (TCP)
5.2.1. Transmission Control Protocol (TCP)
The LDAPMessage PDUs are mapped directly onto the TCP bytestream. It is recommended that server implementations running over the TCP MAY provide a protocol listener on the assigned port, 389. Servers may instead provide a listener on a different port number. Clients MUST support contacting servers on any valid TCP port.
The LDAPMessage PDUs are mapped directly onto the TCP bytestream. It is recommended that server implementations running over the TCP MAY provide a protocol listener on the assigned port, 389. Servers may instead provide a listener on a different port number. Clients MUST support contacting servers on any valid TCP port.
6. Implementation Guidelines
6. Implementation Guidelines
This document describes an Internet protocol.
This document describes an Internet protocol.
6.1. Server Implementations
6.1. Server Implementations
The server MUST be capable of recognizing all the mandatory attribute type names and implement the syntaxes specified in [5]. Servers MAY also recognize additional attribute type names.
The server MUST be capable of recognizing all the mandatory attribute type names and implement the syntaxes specified in [5]. Servers MAY also recognize additional attribute type names.
6.2. Client Implementations
6.2. Client Implementations
Clients which request 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 target entry name, scope and filter. Some clients may be using a counter that is incremented each time referral handling occurs for an operation, and these kinds of clients MUST be able to handle a DIT with at least ten layers of naming contexts between the root and a leaf entry.
Clients which request 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 target entry name, scope and filter. Some clients may be using a counter that is incremented each time referral handling occurs for an operation, and these kinds of clients MUST be able to handle a DIT with at least ten layers of naming contexts between the root and a leaf entry.
In the absence of prior agreements with servers, clients SHOULD NOT assume that servers support any particular schemas beyond those referenced in section 6.1. Different schemas can have different attribute types with the same names. The client can retrieve the subschema entries referenced by the subschemaSubentry attribute in the server's root DSE or in entries held by the server.
In the absence of prior agreements with servers, clients SHOULD NOT assume that servers support any particular schemas beyond those referenced in section 6.1. Different schemas can have different attribute types with the same names. The client can retrieve the subschema entries referenced by the subschemaSubentry attribute in the server's root DSE or in entries held by the server.
Wahl, et. al. Standards Track [Page 40] RFC 2251 LDAPv3 December 1997
Wahl, et. al. Standards Track [Page 40] RFC 2251 LDAPv3 December 1997
7. Security Considerations
7. Security Considerations
When used with a connection-oriented transport, this version of the protocol provides facilities for the LDAP v2 authentication mechanism, simple authentication using a cleartext password, as well as any SASL mechanism [12]. SASL allows for integrity and privacy services to be negotiated.
When used with a connection-oriented transport, this version of the protocol provides facilities for the LDAP v2 authentication mechanism, simple authentication using a cleartext password, as well as any SASL mechanism [12]. SASL allows for integrity and privacy services to be negotiated.
It is also permitted that the server can return its credentials to the client, if it chooses to do so.
It is also permitted that the server can return its credentials to the client, if it chooses to do so.
Use of cleartext password is strongly discouraged where the underlying transport service cannot guarantee confidentiality and may result in disclosure of the password to unauthorized parties.
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.
When used with SASL, it should be noted that the name field of the BindRequest is not protected against modification. Thus if the distinguished name of the client (an LDAPDN) is agreed through the negotiation of the credentials, it takes precedence over any value in the unprotected name field.
When used with SASL, it should be noted that the name field of the BindRequest is not protected against modification. Thus if the distinguished name of the client (an LDAPDN) is agreed through the negotiation of the credentials, it takes precedence over any value in the unprotected name field.
Implementations which 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 which 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 cache.
Implementations which 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 which 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 cache.
8. Acknowledgements
8. Acknowledgements
This document is an update to RFC 1777, by Wengyik Yeong, Tim Howes, and Steve Kille. Design ideas included in this document are based on those discussed in ASID and other IETF Working Groups. The contributions of individuals in these working groups is gratefully acknowledged.
This document is an update to RFC 1777, by Wengyik Yeong, Tim Howes, and Steve Kille. Design ideas included in this document are based on those discussed in ASID and other IETF Working Groups. The contributions of individuals in these working groups is gratefully acknowledged.
9. Bibliography
9. Bibliography
[1] ITU-T Rec. X.500, "The Directory: Overview of Concepts, Models
and Service", 1993.
[1] ITU-T Rec. X.500, "The Directory: Overview of Concepts, Models and Service", 1993.
[2] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access
Protocol", RFC 1777, March 1995.
[2] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access Protocol", RFC 1777, March 1995.
[3] ITU-T Rec. X.680, "Abstract Syntax Notation One (ASN.1) -
Specification of Basic Notation", 1994.
[3] ITU-T Rec. X.680, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", 1994.
Wahl, et. al. Standards Track [Page 41] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[41ページ]RFC2251LDAPv3 December 1997
[4] Kille, S., Wahl, M., and T. Howes, "Lightweight Directory Access
Protocol (v3): UTF-8 String Representation of Distinguished
Names", RFC 2253, December 1997.
[4] Kille、S.、ウォール、M.、およびT.ハウズ、「軽量のディレクトリアクセスは(v3)について議定書の中で述べます」。 「分類名のUTF-8ストリング表現」、RFC2253、1997年12月。
[5] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax Definitions",
RFC 2252, December 1997.
[5] ウォール、M.、Coulbeck、A.、ハウズ、T.、およびS.Kille、「軽量のディレクトリアクセスは(v3)について議定書の中で述べます」。 「属性構文定義」、RFC2252、1997年12月。
[6] ITU-T Rec. X.501, "The Directory: Models", 1993.
[6] ITU-T Rec。 X.501、「ディレクトリ:」 「モデル」、1993。
[7] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, December 1994.
[7] バーナーズ・リーとT.とMasinter、L.とM.McCahill、「Uniform Resource Locator(URL)」、RFC1738、1994年12月。
[8] ITU-T Rec. X.511, "The Directory: Abstract Service Definition",
1993.
[8] ITU-T Rec。 X.511、「ディレクトリ:」 「抽象的なサービス定義」、1993。
[9] Howes, T., and M. Smith, "The LDAP URL Format", RFC 2255,
December 1997.
1997年12月の[9] ハウズ、T.とM.スミス、「LDAP URL形式」RFC2255。
[10] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[10] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、RFC2119、1997年3月。
[11] ITU-T Rec. X.690, "Specification of ASN.1 encoding rules: Basic,
Canonical, and Distinguished Encoding Rules", 1994.
[11] ITU-T Rec。 X.690、「ASN.1コード化の仕様は統治します」。 「基本的で、正準で、顕著な符号化規則」、1994。
[12] Meyers, J., "Simple Authentication and Security Layer",
RFC 2222, October 1997.
[12] メイヤーズ、J.、「簡易認証とセキュリティは層にする」RFC2222、1997年10月。
[13] Universal Multiple-Octet Coded Character Set (UCS) -
Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 :
1993.
[13]の普遍的な複数の八重奏コード化文字集合(UCS)--構造と基本多言語水準、ISO/IEC10646-1: 1993.
[14] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
10646", RFC 2044, October 1996.
[14]Yergeau、1996年10月のF.、「UTF-8、ユニコードとISO10646の変化形式」RFC2044。
10. Authors' Addresses
10. 作者のアドレス
Mark Wahl Critical Angle Inc. 4815 W Braker Lane #502-385 Austin, TX 78759 USA
マークウォール臨界角株式会社4815W Braker Laneテキサス78759#502-385オースチン(米国)
Phone: +1 512 372-3160 EMail: M.Wahl@critical-angle.com
以下に電話をしてください。 +1 512 372-3160 メールしてください: M.Wahl@critical-angle.com
Wahl, et. al. Standards Track [Page 42] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[42ページ]RFC2251LDAPv3 December 1997
Tim Howes Netscape Communications Corp. 501 E. Middlefield Rd., MS MV068 Mountain View, CA 94043 USA
ティムハウズネットスケープ・コミュニケーションズ501E.Middlefield MS MV068マウンテンビュー、カリフォルニア94043通り(米国)
Phone: +1 650 937-3419 EMail: howes@netscape.com
以下に電話をしてください。 +1 650 937-3419 メールしてください: howes@netscape.com
Steve Kille Isode Limited The Dome, The Square Richmond TW9 1DT UK
スティーブKille Isodeはドーム、正方形のリッチモンドTW9 1DTイギリスを制限しました。
Phone: +44-181-332-9091 EMail: S.Kille@isode.com
以下に電話をしてください。 +44-181-332-9091 メールしてください: S.Kille@isode.com
Wahl, et. al. Standards Track [Page 43] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[43ページ]RFC2251LDAPv3 December 1997
Appendix A - Complete ASN.1 Definition
付録A--完全なASN.1定義
Lightweight-Directory-Access-Protocol-V3 DEFINITIONS
IMPLICIT TAGS ::=
ライト級ディレクトリアクセスプロトコルV3定義、内在しているタグ:、:=
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 },
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; } , コントロール0Controls OPTIONAL; }
MessageID ::= INTEGER (0 .. maxInt)
MessageID:、:= 整数(0maxInt)
maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
maxInt整数:、:= 2147483647 -- (2^^31 - 1) --
LDAPString ::= OCTET STRING
LDAPString:、:= 八重奏ストリング
LDAPOID ::= OCTET STRING
LDAPOID:、:= 八重奏ストリング
LDAPDN ::= LDAPString
LDAPDN:、:= LDAPString
RelativeLDAPDN ::= LDAPString
RelativeLDAPDN:、:= LDAPString
AttributeType ::= LDAPString
AttributeType:、:= LDAPString
AttributeDescription ::= LDAPString
AttributeDescription:、:= LDAPString
Wahl, et. al. Standards Track [Page 44] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[44ページ]RFC2251LDAPv3 December 1997
AttributeDescriptionList ::= SEQUENCE OF
AttributeDescription
AttributeDescriptionList:、:= AttributeDescriptionの系列
AttributeValue ::= OCTET STRING
AttributeValue:、:= 八重奏ストリング
AttributeValueAssertion ::= SEQUENCE {
attributeDesc AttributeDescription,
assertionValue AssertionValue }
AttributeValueAssertion:、:= 系列attributeDesc AttributeDescription、assertionValue AssertionValue
AssertionValue ::= OCTET STRING
AssertionValue:、:= 八重奏ストリング
Attribute ::= SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
以下を結果と考えてください:= 系列AttributeDescription、vals SET OF AttributeValueをタイプしてください。
MatchingRuleId ::= LDAPString
MatchingRuleId:、:= LDAPString
LDAPResult ::= SEQUENCE {
resultCode ENUMERATED {
success (0),
operationsError (1),
protocolError (2),
timeLimitExceeded (3),
sizeLimitExceeded (4),
compareFalse (5),
compareTrue (6),
authMethodNotSupported (7),
strongAuthRequired (8),
-- 9 reserved --
referral (10), -- new
adminLimitExceeded (11), -- new
unavailableCriticalExtension (12), -- new
confidentialityRequired (13), -- new
saslBindInProgress (14), -- new
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),
LDAPResult:、:= SEQUENCE、resultCode ENUMERATED、operationsError(1)、protocolError(2)、timeLimitExceeded(3)、sizeLimitExceeded(4)、compareFalse(5)、compareTrue(6)、authMethodNotSupported(7)、strongAuthRequired(8)--予約された9--紹介(10)--新しいadminLimitExceeded(11)--新しいunavailableCriticalExtension(12)--新しいconfidentialityRequired(13)--成功(0)、新しいsaslBindInProgress(14); 新しい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)
Wahl, et. al. Standards Track [Page 45] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[45ページ]RFC2251LDAPv3 December 1997
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), -- new
-- 72-79 unused --
other (80) },
-- 81-90 reserved for APIs --
matchedDN LDAPDN,
errorMessage LDAPString,
referral [3] Referral OPTIONAL }
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、errorMessage LDAPString、--APIのために予約された81-90--紹介[3]紹介OPTIONAL
Referral ::= SEQUENCE OF LDAPURL
紹介:、:= LDAPURLの系列
LDAPURL ::= LDAPString -- limited to characters permitted in URLs
LDAPURL:、:= LDAPString--URLで受入れられたキャラクタに制限されます。
Controls ::= SEQUENCE OF Control
コントロール:、:= コントロールの系列
Control ::= SEQUENCE {
controlType LDAPOID,
criticality BOOLEAN DEFAULT FALSE,
controlValue OCTET STRING OPTIONAL }
以下を制御してください:= 系列controlType LDAPOID、臨界BOOLEAN DEFAULT FALSE、controlValue OCTET STRING OPTIONAL
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が[3] SaslCredentialsをsaslする
SaslCredentials ::= SEQUENCE {
mechanism LDAPString,
credentials OCTET STRING OPTIONAL }
SaslCredentials:、:= 系列メカニズムLDAPString、信任状OCTET STRING OPTIONAL
BindResponse ::= [APPLICATION 1] SEQUENCE {
BindResponse:、:= [アプリケーション1]系列
Wahl, et. al. Standards Track [Page 46] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[46ページ]RFC2251LDAPv3 December 1997
COMPONENTS OF LDAPResult,
serverSaslCreds [7] OCTET STRING OPTIONAL }
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 AttributeDescriptionList }
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をフィルターにかけます、属性AttributeDescriptionList
Filter ::= CHOICE {
and [0] SET OF Filter,
or [1] SET OF Filter,
not [2] Filter,
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion,
present [7] AttributeDescription,
approxMatch [8] AttributeValueAssertion,
extensibleMatch [9] MatchingRuleAssertion }
以下をフィルターにかけてください:= 選択そして、[2]フィルタ、AttributeValueAssertion(サブストリング[4]SubstringFilter、greaterOrEqual[5]AttributeValueAssertion、lessOrEqual[6]AttributeValueAssertion)が[7]AttributeDescription、approxMatch[8]AttributeValueAssertion、extensibleMatch[9]MatchingRuleAssertionを寄贈するequalityMatch[3]ではなく、[0]SET OF Filter、または[1]SET OF Filter
SubstringFilter ::= SEQUENCE {
type AttributeDescription,
-- at least one must be present
substrings SEQUENCE OF CHOICE {
initial [0] LDAPString,
any [1] LDAPString,
final [2] LDAPString } }
SubstringFilter:、:= 系列AttributeDescriptionをタイプしてください--少なくとも1つは現在のサブストリングSEQUENCE OF CHOICEが[0]LDAPString、どんな[1]LDAPString、決勝[2]LDAPStringにも頭文字をつけるということであるに違いありません。
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
Wahl, et. al. Standards Track [Page 47] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[47ページ]RFC2251LDAPv3 December 1997
SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
objectName LDAPDN,
attributes PartialAttributeList }
SearchResultEntry:、:= [アプリケーション4] 系列objectName LDAPDN、属性PartialAttributeList
PartialAttributeList ::= SEQUENCE OF SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
PartialAttributeList:、:= 系列の系列AttributeDescription、vals SET OF AttributeValueをタイプしてください。
SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL
SearchResultReference:、:= [アプリケーション19] LDAPURLの系列
SearchResultDone ::= [APPLICATION 5] LDAPResult
SearchResultDone:、:= [アプリケーション5] LDAPResult
ModifyRequest ::= [APPLICATION 6] SEQUENCE {
object LDAPDN,
modification SEQUENCE OF SEQUENCE {
operation ENUMERATED {
add (0),
delete (1),
replace (2) },
modification AttributeTypeAndValues } }
ModifyRequest:、:= [アプリケーション6] 系列LDAPDN、変更SEQUENCE OF SEQUENCEが反対する、操作ENUMERATEDは(0) (1)を削除するように言い足して、(2)を取り替えます、変更AttributeTypeAndValues
AttributeTypeAndValues ::= SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
AttributeTypeAndValues:、:= 系列AttributeDescription、vals SET OF AttributeValueをタイプしてください。
ModifyResponse ::= [APPLICATION 7] LDAPResult
ModifyResponse:、:= [アプリケーション7] LDAPResult
AddRequest ::= [APPLICATION 8] SEQUENCE {
entry LDAPDN,
attributes AttributeList }
AddRequest:、:= [アプリケーション8] 系列エントリーLDAPDN、属性AttributeList
AttributeList ::= SEQUENCE OF SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
AttributeList:、:= 系列の系列AttributeDescription、vals SET OF AttributeValueをタイプしてください。
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
Wahl, et. al. Standards Track [Page 48] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[48ページ]RFC2251LDAPv3 December 1997
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,
response [11] OCTET STRING OPTIONAL }
ExtendedResponse:、:= [アプリケーション24] 系列COMPONENTS OF LDAPResult、responseName[10]LDAPOID OPTIONAL、応答[11]OCTET STRING OPTIONAL
END
終わり
Wahl, et. al. Standards Track [Page 49] RFC 2251 LDAPv3 December 1997
etウォール、アル。 標準化過程[49ページ]RFC2251LDAPv3 December 1997
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright(C)インターネット協会(1997)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Wahl, et. al. Standards Track [Page 50]
etウォール、アル。 標準化過程[50ページ]
一覧
スポンサーリンク
