原文:ftp://ftp.rfc-editor.org/in-notes/rfc2251.txt
原文との対訳として読みたい方へ:このページをローカルに保存して、スタイルシートの original クラスの display 属性を none から block に変更してみてください。



Network Working Group
Request for Comments: 2251
Category: Standards Track



M. Wahl
T. Howes
Netscape Communications Corp.
S. Kille
Isode Limited
December 1997

Lightweight Directory Access Protocol (v3)

1. Status of this Memo 1. この文書の位置付け

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. この文書はインターネットコミュニティのためのインターネット標準トラックプロトコルを規定しており、改良のための議論と提案を求めている。このプロトコルの標準化の状態と状況に付いては "Internet Official Protocol Standards" (STD 1) の最新版を参照してほしい。この文書の配布に制限はない。

Copyright Notice 著作権通知

Copyright (C) The Internet Society (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: この制限にもかかわらず、この仕様は RFC 2026 の セクション 4.4.1 にしたがって、IESG により推奨標準として承認された。その理由は以下の通りである:

Readers are hereby warned that until mandatory authentication mechanisms are standardized, clients and servers written according to this specification which make use of update functionality are UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL. これらにより読者は、強制的な認証メカニズムが標準化されるまでは、この仕様に沿って書かれた更新機能を使用するクライアントとサーバーとが相互運用できる可能性が低いことと、認証が容認し難いほどに低いレベルまで下げられた場合にのみ相互運用が可能であることとに注意しなければならない。

Implementors are hereby discouraged from deploying LDAPv3 clients or servers which implement the update functionality, until a Proposed Standard for mandatory authentication in LDAPv3 has been approved and published as an RFC. またこれらにより実装者は、LDAPv3 における強制的な認証のための推奨標準が承認され RFC として公開されるまでは、この更新機能を実装した LDAPv3 クライアントやサーバーの展開を推奨されない。

Table of Contents 目次


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 のモデルをサポートする一方で、X.500 Directory Access Protocol (DAP) のリソース要件を課さないディレクトリアクセスを提供するように設計されている。具体的に言うとこのプロトコルは、ディレクトリへの読み取り/書き込みの対話式アクセスを提供する管理アプリケーションやブラウザアプリケーションをターゲットにしている。また 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", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY"は、それぞれ RFC 2119 [10] で説明されている通りに解釈される。

Key aspects of this version of LDAP are: このバージョンの LDAP の重要な側面は以下の通り:

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. このプロトコルにおいて何らかの応答が定義されている場合には、サーバーは常にその応答を返すことを要求されるが、クライアントまたはサーバーのどちらかの側で同期して動作することを求める要件はないことに注意してほしい。クライアント・サーバー間で複数の操作の要求と応答とがどのような順序で交換されてもよいが、その場合クライアントが、応答を必要とするすべての要求に対する応答を最終的には受け取ることが条件である。

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 では、クライアントに参照を返すプロトコルサーバーに対する備えがなかった。しかしながらこのバージョンは、パフォーマンスの改善と分散処理とのために、サーバーがクライアントに他のサーバーへの参照を返すことを許可している。これによりサーバーは、操作を進めるために他サーバーと連携する作業から開放される。

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. この文書で定義される主なプロトコル操作はディレクトリ抽象化サービス X.500(1997) の完全なサブセットにマッピングできるため、DAP によって綺麗に提供できることに注意してほしい。しかしながら、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 プロトコルは、ディレクトリ情報ツリー(DIT:Directory Information Tree)へのアクセスを連携して提供するサーバーが一台または複数存在すると仮定する。ディレクトリ情報ツリーは複数のエントリから構成される。エントリは名前を持つ。これは相対識別名(RDN:relative distinguished name)を形成するエントリに由来するひとつ以上の属性値であり、その兄弟エントリの中でユニークでなければならない(MUST)。特定のエントリからそのツリーのルート直下までの一連のエントリの相対識別名を連結したものは、そのエントリの識別名(DN:Distinguished Name)となり、ツリー内でユニークになる。識別名は例えば次のようなものである。

      CN=Steve Kille, O=Isode Limited, 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. キャッシュやシャドウを実行するサーバーは、オリジナルのサーバーがデータに課していたすべてのアクセスコントロールの制約に違反しないことを保証しなければならない(MUST)。

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-固有エントリ(DSE:DSA-specific Entry)であり、いかなる名前付けコンテキストの一部でもない。各々のサーバーはルート 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 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. エントリは属性の集合から構成される。属性はひとつ以上の関連する値を持つ型である。属性の型は短い記述名と OID(オブジェクト識別子)とによって識別される。属性の型は、ひとつのエントリ内にその型の属性値が 2 つ以上存在できるかどうか、値が従わなければならない文法、その属性の値に対して行える検索の種類、およびその他の機能を決定する。

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"). 属性の一例は "mail" である。この属性にはひとつ以上の値が存在してもよく、それは 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. スキーマは、属性の型の定義とオブジェクトクラスの定義、および、エントリの属性に対して(比較操作において)フィルタや属性値アサーションをサーバーが一致させる方法と、追加や修正の操作を許可するかどうかをサーバーが判断するための他の情報との集合である。LDAP と共に使用するためのスキーマの定義は [5] と [6] とに記述されている。他の文書で追加のスキーマ要素が定義されてもよい。

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 属性を持たなければならない(MUST)。objectClass 属性は、システムとユーザースキーマとがエントリに許可される属性を決定するオブジェクトクラスを特定する。クライアントはこの属性の値を変更してもよいが、objectClass 属性を削除することはできない。サーバーは、エントリの基本構造クラスが変更されるのを防ぐため(例えば "人" を "国" に変更できないようにするため)に、属性の変更を制限してもよい。エントリを生成したり、エントリに 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. 操作属性と呼ばれる一部の属性はディレクトリシステム自体を管理するためにサーバーによって使用され、明示的に名前で要求されない限り検索結果として返されることはない。"mail" のような(操作ではない)属性は、サーバーによって強制されるスキーマと文法制限とを持つが、一般にサーバーはその値を利用しない。

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. オブジェクトクラスの定義によって許可されているか、そのエントリを制御するスキーマ(後述のサブスキーマで特定される)か、サーバーに操作属性として知られており管理目的で利用されるのではない限り、サーバーは、クライアントがエントリに属性を追加することを許可してはならない(MUST NOT)。[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] で定義されている以下の操作属性を(他の操作属性に加えて)持つことができる(MAY)。これらの属性はサーバーによって自動的に保守されるものであり、クライアントによる変更はできない:

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) のモデルに従うサーバーは X.500 サブスキーマメカニズムを使用してサブスキーマを実装するべきであり(SHOULD)、そのためこれらのサブスキーマは通常のエントリではない。LDAP クライアントは、X.500 サブスキーマの他の特徴をサーバーが実装していると仮定しないべきである(SHOULD NOT)。存在させてもよい属性とオブジェクトクラスとをクライアントが見つけられるように、エントリを管理したりクライアントにそれらのエントリの変更を許可したりするサーバーは、これらのサブスキーマエントリへのアクセス手段を実装および提供しなければならない(MUST)。この機能は、他のサーバーでも実装することが強く推奨される。

The following four attributes MUST be present in all subschema entries: 以下の 4 つの属性は、すべてのサブスキーマエントリに存在しなければならない(MUST):

These are defined in [5]. Other attributes MAY be present in subschema entries, to reflect additional supported capabilities. These include matchingRules, matchingRuleUse, dITStructureRules, dITContentRules, nameForms and ldapSyntaxes. これらは [5] で定義されている。追加サポートされた機能を反映するために、その他の属性がサブスキーマに存在してもよい(MAY)。それらには 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. クライアントがスキーマ情報のキャッシュを保守できるように、サーバーはサブスキーマ内で属性 createTimestamp と modifyTimestamp とを提供するべきである(SHOULD)。

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=subschema)" のフィルタを持つ検索を要求することによってのみでなければならない(MUST)。(これにより 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 の観点から LDAP を X.500 のアクセスメカニズムとして定義する。このサービスを提供する LDAP サーバーは、X.500(1993) の一連の ITU 勧告にしたがって動作しなければならない(MUST)。しかしながらこのサービスを提供するにあたり LDAP サーバーは、どの X.500 プロトコルを使用することも要求されない。例えば LDAP は、LDAP で使用される X.500 の データとサービスモデルとが 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 サーバーは、自分自身に関する情報と、各サーバー固有の他の情報とを提供しなければならない(MUST)。これはルート DSE (DSA 固有エントリ)内に位置する属性のグループとして表され、長さゼロの 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 で定義されている。他の文書で追加の属性が定義されてもよい。

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. サーバーがエントリを管理しておらず、スキーマ情報の場所も知らない場合、ルート DSE に subschemaSubentry 属性は存在しない。サーバーがひとつ以上のスキーマ規則の下でディレクトリエントリを管理している場合、ルート DSE に subschemaSubentry 属性の値がいくつか存在してもよい。

4. Elements of Protocol 4. プロトコルの要素

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 プロトコルは抽象構文記法 1 (ASN.1)を使用して記述され、通常は ASN.1 基本エンコード規則(ASN.1 Basic Encoding Rules)[11] のサブセットを使用して転送される。このプロトコルの将来の拡張をサポートするために、クライアントとサーバーは自身が認識できないタグを持つ SEQUENCE エンコードの要素を無視しなければならない(MUST)。

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 で説明されている Bind Request の一部として、自身がサポートするバージョンを提示する。クライアントがバインドを送信しなかった場合、サーバーはそのクライアントがバージョン 3 をサポートしていると仮定しなければならない(MUST)(バージョン 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 またはそれ以降を実装するサーバーは、この属性を提供しなければならない(MUST)。バージョン 2 だけを実装しているサーバーはこの属性を提供しなくてもよい。

4.1. Common Elements 4.1. 共通要素

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(プロトコルデータユニット)のフォーマット、およびプロトコル操作で使用されるデータ型の定義を説明する。

4.1.1. Message Envelope 4.1.1. メッセージエンベロープ

For the purposes of protocol exchanges, all protocol operations are encapsulated in a common envelope, the LDAPMessage, which is defined as follows: プロトコル交換のために、すべてのプロトコル操作は共通エンベロープ LDAPMessage にカプセル化される。その定義は以下の通り:

        LDAPMessage ::= SEQUENCE {
                messageID       MessageID,
                protocolOp      CHOICE {
                        bindRequest     BindRequest,
                        bindResponse    BindResponse,
                        unbindRequest   UnbindRequest,
                        searchRequest   SearchRequest,
                        searchResEntry  SearchResultEntry,
                        searchResDone   SearchResultDone,
                        searchResRef    SearchResultReference,
                        modifyRequest   ModifyRequest,
                        modifyResponse  ModifyResponse,
                        addRequest      AddRequest,
                        addResponse     AddResponse,
                        delRequest      DelRequest,
                        delResponse     DelResponse,
                        modDNRequest    ModifyDNRequest,
                        modDNResponse   ModifyDNResponse,
                        compareRequest  CompareRequest,
                        compareResponse CompareResponse,
                        abandonRequest  AbandonRequest,
                        extendedReq     ExtendedRequest,
                        extendedResp    ExtendedResponse },
                 controls       [0] Controls OPTIONAL }

        MessageID ::= INTEGER (0 .. maxInt)

        maxInt INTEGER ::= 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 の役割は、全てのプロトコル交換において必要とされる共通フィールドを持つエンベロープを提供することである。今のところ messageID と controls とだけが共通フィールドである。

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. クライアントから受信した PDU が、 LDAPMessage の SEQUENCE タグを認識できないか、messageID を解析できないか、protocolOp のタグをリクエストとして認識できないか、エンコード構造またはデータフィールド長が不正であることが分かった場合、サーバーはセクション 4.4.1 で説明されている切断通知(resultCode は protocolError)を返し、即座に接続を閉じなければならない(MUST)。その他の理由でサーバーがクライアントから受信したリクエストを解析できない場合、サーバーはそのリクエストに対し、resultCode に protocolError をセットした適切な応答を返さなければならない(MUST)。

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 で定義される。

4.1.1.1. Message ID 4.1.1.1. メッセージ ID (Message 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. リクエストの messageID は、そのメッセージを含む LDAP セッション中の他のすべてのリクエストと異なる値を持たなければならない(MUST)。

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. クライアントは以前のリクエストに対する最終応答を受け取らない限り、同じ接続内で以前のリクエストと同じ messageID を持つリクエストを送信してはならない(MUST NOT)。さもなければ動作は未定義となる。典型的なクライアントは各々のリクエスト毎にカウンタを増加させる。

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. abandonResuest はレスポンスを持たないため、abandonRequest に続いて呼び出された別のリクエストに対する応答をサーバーから受信しない限り、クライアントはその abandonRequest やそれによって中止された操作の messageID を再利用してはならない(MUST NOT)。

4.1.2. String Types 4.1.2. 文字列型(String Types)

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 型の文字列は OCTET STRING 型としてエンコードされるが、LDAPString は UTF-8 アルゴリズム [14] にしたがってエンコードされた ISO 10646 [13] 文字セット(ユニコードの上位セット)が使用されていることを表すための表記法である。URF-8 アルゴリズムにおいて ASCII (0x000〜0x007F) と同じ文字は、単一バイトの同じ ASCII 文字で表現されることに注意してほしい。その他のバイト値は任意の文字の可変長エンコードを形成するために使用される。

        LDAPString ::= OCTET STRING

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. LDAPIOD は、この文字列に許される値が(UTF-8 エンコードされた) OBJECT IDENTIFIER のドット区切りの 10 進表現であることを表すための表記法である。

        LDAPOID ::= OCTET STRING

For example,

        1.3.6.1.4.1.1466.1.2.3

4.1.3. Distinguished Name and Relative Distinguished Name 4.1.3. 識別名(Distinguished Name)と相対識別名(Relative Distinguished Name)

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> ::= <name>

        <relative-distinguished-name> ::= <name-component>

where <name> and <name-component> are as defined in [4]. <name> と <name-component> は [4] で定義されている通りである。

        LDAPDN ::= 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. 相対識別名の構成要素の中に現れることができるのは属性型だけである。オプションの属性記述(次セクション)を識別名の特定に使用してはならない(MUST NOT)。

4.1.4. Attribute Type 4.1.4. 属性型(Attribute Type)

An AttributeType takes on as its value the textual string associated with that AttributeType in its specification. 属性型(AttributeType)はその値として、その仕様における属性型に関連するテキスト文字列を持つ。

        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 を持つ。この識別子は例えば "2.5.4.10" のような、構成要素をピリオドで区切った 10 進数値として書くことができる。

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.) また仕様は、ひとつの属性型にひとつまたは複数のテキスト名を割り当ててよい。名前は文字で始まり、ASCII 文字、数字、ハイフンのみで構成されなければならない(MUST)。大文字・小文字は区別されない。(これらの ASCII 文字は、その UTF-8 エンコードが 0x00 から 0x7F の単独バイトである ISO 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. サーバーが属性型のためのテキスト名を持つ場合、検索結果に返される属性にはテキスト名を使用しなければならない(MUST)。属性型のためのテキスト名が存在しない場合にのみ、ドット区切り 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 つの異なる仕様(どちらもスタンダードトラック RFC ではない)が同じ名前を選択する可能性があるため、属性型のテキスト名はユニークではない。

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. エントリを管理またはシャドウしているサーバーは、attributeTypes 属性を使用して、サブスキーマエントリにおいて自身がサポートしている全ての属性型をリストするべきである(SHOULD)。属性の無制限集合をサポートするサーバーは、少なくとも 'objectClass' 属性のための attributeType 値を含むべきである(SHOULD)。クライアントは OBJECT IDENTIFIER と属性型に関連する他の情報とを取得するために、サブスキーマエントリから attributeTypes 値を取得してもよい(MAY)。

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. 属性記述(Attribute Description)

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 も大文字・小文字を別されない。

        AttributeDescription ::= LDAPString

A value of AttributeDescription is based on the following BNF: AttributeDescription の値は以下の BNF に基づく:

        <AttributeDescription> ::= <AttributeType> [ ";" <options> ]

        <options>  ::= <option> | <option> ";" <options>

        <option>   ::= <opt-char> <opt-char>*

        <opt-char> ::=  ASCII-equivalent letters, numbers and hyphen

Examples of valid AttributeDescription: 有効な AttributeDescription の例:

        cn
        userCertificate;binary

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. この文書ではひとつのオプション "binary" が定義されている。IETF スタンダードトラックと実験的 RFC とにおいて追加オプションが定義されてもよい。"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. ひとつ以上のオプションを持つ AttributeDescription は、オプションを持たない属性型のサブタイプとして扱われる。AttributeDescription 中に現れるオプションは互いに排他的ではない。実装は、昇順にソートされた <オプション(options)> リストを生成しなければなない(MUST)。またサーバーは、同じ AttributeType とオプションとを持つどの 2 つの AttributeDescription も同等に扱わなければならない(MUST)。サーバーは、実装されていないオプションを持つ 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" は、ゼロ個以上の属性型のリストを記述する。(要素数ゼロのリストは Search リクエストにおいて特別な意味を持つ。)

        AttributeDescriptionList ::= SEQUENCE OF
                AttributeDescription
4.1.5.1. Binary Option 4.1.5.1. バイナリオプション(Binary Option)

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. AttributeDescription の中に "バイナリ(binary)" オプションが現れた場合、それは [5] において属性のために定義されているすべての文字列ベースのエンコード表現を上書きし、代わりにその属性は、基本エンコード規則(Basic Encoding Rules)[11] を使用してエンコードされたバイナリ値として変換される。バイナリ値の構文は、属定型定義の "SYNTAX" 部に見られる 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. "バイナリ(binary)" オプションの有無はプロトコルにおける属性値の変換にのみ影響し、サーバーは単一フォーマットの中に任意の属性を保存する。クライアントがサーバーにバイナリフォーマットの属性を返すことを要求したが、サーバーがそのフォーマットを生成できない場合、サーバーはそれを認識できない属性型として扱わなければならない(MUST)。同じように、クライアントがバイナリオプションを付けずに名前によって属性を要求した場合、クライアントはサーバーからその属性がバイナリフォーマットで返されることを期待してはならない(MUST NOT)。

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 データ型の属性と共に使用されることを意図しており、その型の値の構造はクライアントによって必要とされる。この種の文法の例は、"Certificate" や "CertificateList" である。

4.1.6. Attribute Value 4.1.6. 属性値(Attribute Value)

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 型のフィールドは、"バイナリ(binary)" オプションがその AttributeValue と共に AttributeDescription に現れるかどうかによって、AttributeValue データ型の文字列エンコード、またはエンコード済みバイナリ値を含む OCTET STRING のどちらかをその値として持つ。

The definition of string encodings for different syntaxes and types may be found in other documents, and in particular [5]. 異なる構文と型とのための文字列エンコードの定義は、他の文書(具体的には [5])に見つけられるだろう。

        AttributeValue ::= OCTET STRING

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. 任意の印刷不可能な構文を持つ属性が定義されてよい。値の構文が未知の場合、実装はその値を ASN.1 として単純に解読を試みてはならない(MUST NOT)し、表示してはならない(MUST NOT)。実装は元のエントリのサブスキーマを探し、そこから attributeTypes の値を取得しようと試みてもよい。

Clients MUST NOT send attribute values in a request which are not valid according to the syntax defined for the attributes. クライアントはリクエストにおいて、その属性のために定義された構文にしたがっていない無効な属性値を送信してはならない(MUST NOT)。

4.1.7. Attribute Value Assertion 4.1.7. 属性値アサーション(Attribute Value Assertion)

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 }

        AssertionValue ::= OCTET STRING

If the "binary" option is present in attributeDesc, this signals to the server that the assertionValue is a binary encoding of the assertion value. "バイナリ(binary)" オプションが 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] で説明されている文字列値を持つすべてのユーザー属性の場合、アサーション値の構文は値の構文と同じである。Compare Request と検索フィルタとにおいてクライアントは、ユーザー属性値をアサーション値として使用してよい。

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. しかしながらアサーションの構文は、他の属性のため、または不一致規則のための値の構文(これらは値の一部だけを含むアサーションの構文を持つことができる)とは異なってもよいことに注意してほしい。例に付いては X.501 [6] のセクション 20.2.1.8 を参照してほしい。

4.1.8. Attribute 4.1.8. 属性(Attribute)

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.) ひとつの属性は、ひとつの型と、ひとつ以上のその型の値から構成される。(属性が保存されるときには少なくともひとつの値を持たなければならない(MUST)が、アクセスコントロールによる制限のため、プロトコルにおいて転送される場合には空になる可能性がある。これはセクション 4.5.2 の PartialAttributeList 型の部分で説明されている。)

        Attribute ::= SEQUENCE {
                type    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 集合内での属性値の順序は未定義かつ実装依存であるので、それに依存してはならない(MUST NOT)。

4.1.9. Matching Rule Identifier 4.1.9. 一致規則識別子(Matching Rule Identifier)

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 をサーバーがどのように比較するべきかを表す手段である。一致規則はアサーション値の構文と、サーバー上で実行されるべき処理とを定義する。

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". LDAP プロトコルにおいて X.501(1993) の一致規則は、OBJECT IDENTIFIER の印刷可能表現で識別される。これは [5] で与えられる文字列のひとつ、または各要素をピリオドで区切った 10 進数値として表され、例えば "caseIgnoreIA5Match" や "1.3.6.1.4.1.453.33.33" となる。

        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 属性を使用してリストしなければならない(MUST)。またサーバーはそこで matchingRuleUse 属性を使用して、使用可能な一致規則の属性型ごとにリストするべきである(MUST)。さらに多くの情報は [5] のセクション 4.4 で与えられる。

4.1.10. Result Message 4.1.10. 結果メッセージ(Result Message)

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),

                             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),
                             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 }
        LDAPResult ::= SEQUENCE {
                resultCode      ENUMERATED {
                             success                      (0),
                             operationsError              (1),
                             protocolError                (2),
                             timeLimitExceeded            (3),
                             sizeLimitExceeded            (4),
                             compareFalse                 (5),
                             compareTrue                  (6),

                             authMethodNotSupported       (7),
                             strongAuthRequired           (8),
                                        -- 9 は予約済み --
                             referral                     (10),  -- 新規
                             adminLimitExceeded           (11),  -- 新規
                             unavailableCriticalExtension (12),  -- 新規
                             confidentialityRequired      (13),  -- 新規
                             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),
                             invalidCredentials           (49),
                             insufficientAccessRights     (50),
                             busy                         (51),
                             unavailable                  (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 は未使用 --
                             other                        (80) },
                             -- 81-90 は API のために予約済み --
                matchedDN       LDAPDN,
                errorMessage    LDAPString,
                referral        [3] Referral 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. success、compareFalse、compareTrue を除く全ての resultCode は、操作が完全には終了していないことを意味するものとして扱われる。

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. 大部分の resultCode は X.511 のエラーデータ種別に由来する問題示唆を元にしている。16 から 21 の resultCode は AttributeProblem、32・33・34・36 は NameProblem、48・49・50 は SecurityProblem、51 から 54 は ServiceProblem、64・69・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, 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. この構造体の errorMessage フィールドは、サーバーの判断により、可読テキストのエラー診断結果を返すために使用することができる(文末制御文字とページフォーマット文字とは避けるべきである)。このエラー診断結果は標準化されていないため、実装はここで返された値に依存してはならない(MUST NOT)。サーバーがテキストの診断結果を返すことを選択しなかった場合、LDAPResult の errorMessage フィールドは長さゼロの文字列を含まなければならない(MUST)。

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. resultCode が noSuchObject、 aliasProblem、 invalidDNSyntax、 aliasDereferencingProblem の何れか場合、matchedDN フィールドには、そのディレクトリ内で一致した最下位エントリ(オブジェクトまたはエイリアス)の名前がセットされる。エントリへの位置付けを試みる間にエイリアスの逆参照が無かった場合、提示された名前が切り捨てられた形となり、エイリアスが逆参照された場合、X.511 [8] のセクション 12.5 で定義されている通りの結果名(resulting name)になる。他の resultCode の場合、matchedDN フィールドには長さゼロの文字列がセットされる。

4.1.11. Referral 4.1.11. 参照(Referral)

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. referral エラーは、通信中のサーバーがそのリクエストの目的エントリを持っていないことを表す。referral フィールドは LDAPResult.resultCode フィールドの値が referral の場合にのみ LDAPResult の中に現れ、その他の結果コードの場合には現れない。referral フィールドには、LDAP またはその他のプロトコル経由でアクセスできる他のサーバー(またはサーバーの集合)への参照が含まれる。すべての操作要求の応答において referral を返すことができる(応答を持たないアンバインドや破棄を除く)。referral の中には少なくともひとつの URL が現れなければならない(MUST)。

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 検索に対して、referral が返されることはない。代わりに、継続参照(continuation references:セクション 4.5.3 で説明されている)が返される。

        Referral ::= SEQUENCE OF LDAPURL  -- one or more

        LDAPURL ::= LDAPString -- limited to characters permitted in URLs
        Referral ::= SEQUENCE OF LDAPURL  -- ひとつ以上

        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.) クライアントが操作の進行を望む場合、どれかひとつのサーバーに連絡することによって、その referral に従わなければならない(MUST)。これら全ての URL は、処理を進行するために使用される能力を等しく持たなければならない(MUST)。(複数のサーバーがこれを達成するメカニズムはこの文書の範囲外である。)

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 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. LDAP プロトコルを実装するサーバーのための URL は [9] にしたがって書かれる。エイリアスが逆参照される場合、新しい目的オブジェクト名を持つ <dn" 部が URL に現れなければならない(MUST)。この "dn" 部が現れる場合、クライアントは操作を進行するための次のリクエストの中でその名前を使わなければならない(MUST)。この "dn" 部が現れない場合、クライアントは元のリクエストと同じ名前を使用することになるだろう。一部のサーバー(例えば分散インデックスに参加しているサーバー)は、Search Operation のための参照において異なるフィルタを提供してもよい。URL のフィルタ部が LDAPURL の中に現れた場合、クライアントはその検索を進行するための次のリクエストでそのフィルタを使用しなければならない(MUST)。またそのフィルタ部が現れない場合、クライアントはその検索に使用したものと同じフィルタを使わなければならない(MUST)。新しいリクエストのその他の点は、その参照を生成したリクエストと同じでもあっても、異なっていてもよい。

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 として正当ではない可能性があるため、RFC 1738 [7] の % による手法を使ってエスケープされなければならない(MUST)ことに注意してほしい。

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. 制御(Controls)

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. control は拡張情報を指定するための手段である。リクエストの一部として送信される controls はそのリクエストにのみ適用され、保存はされない。

        Controls ::= SEQUENCE OF Control

        Control ::= SEQUENCE {
                controlType             LDAPOID,
                criticality             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 フィールドは、その control を一意に識別する OBJECT IDENTIFIER の UTF-8 エンコードされたドット区切り 10 進表現でなければならない(MUST)。これにより control の名前の衝突が回避される。

The criticality field is either TRUE or FALSE. criticality フィールドは 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. サーバーが controlType を認識し、それが操作に対して適切であれば、サーバーはその操作を実行するときにその control を使用する。

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. サーバーが controlType を認識せず、criticality フィールドが TRUE の場合、サーバーはその操作を実行してはならず(MUST NOT)、代わりに resultCode に unsupportedCriticalExtension を返さなければならない(MUST)。

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. control がその操作に対して適切ではなく、criticality フィールドが TRUE の場合、サーバーはその操作を実行してはならず(MUST NOT)、代わりに resultCode に unsupportedCriticalExtension を返さなければならない(MUST)。

If the control is unrecognized or inappropriate but the criticality field is FALSE, the server MUST ignore the control. control が認識されない、または不適切であるが、criticality フィールドが FALSE の場合、サーバーはその control を無視しなければならない(MUST)。

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 はその control に関連する任意の情報を含み、形式はその control のために定義されたものとなる。サーバーは controlValue のオクテット文字列(ゼロバイトも含む)の任意の内容を扱う準備ができていなければならない(MUST)。その controlType に関連する値の情報が存在しない場合にのみ、controlValue は存在しない。

This document does not define any controls. Controls may be defined in other documents. The definition of a control consists of: この文書はいかなる control も定義しない。別の文書で control が定義されてもよい。control の定義は以下の要素から構成される:

Servers list the controls which they recognize in the supportedControl attribute in the root DSE. サーバーはルート DSE の supportedControl 属性の中で、自身が認識する control をリストする。

4.2. Bind Operation 4.2. Bind Operation(バインド操作)

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 }

        AuthenticationChoice ::= CHOICE {
                simple                  [0] OCTET STRING,
                                         -- 1 and 2 reserved
                sasl                    [3] SaslCredentials }

        SaslCredentials ::= SEQUENCE {
                mechanism               LDAPString,
                credentials             OCTET STRING OPTIONAL }
        BindRequest ::= [APPLICATION 0] SEQUENCE {
                version                 INTEGER (1 .. 127),
                name                    LDAPDN,
                authentication          AuthenticationChoice }

        AuthenticationChoice ::= CHOICE {
                simple                  [0] OCTET STRING,
                                         -- 1 と 2 は予約済み
                sasl                    [3] SaslCredentials }

        SaslCredentials ::= SEQUENCE {
                mechanism               LDAPString,
                credentials             OCTET STRING OPTIONAL }

Parameters of the Bind Request are: 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 Request の外部の要因による影響を受けてもよい(MAY)。

4.2.1. Sequencing of the Bind Request 4.2.1. Bind Request の流れ

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 を複数回呼び出す必要があるだろう。バインド処理を取り消したいクライアントは、任意の段階でアンバインドを行い下層接続を切断してよい(MAY)。クライアントは複数段階のバインドの一部として実行される 2 つの Bind Request の間に操作を呼び出してはならない(MUST NOT)。

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 の mechanism フィールドに異なる値を持つ BindRequest、または 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 mechanism フィールドに空文字を持つ BindRequest をクライアントが送信した場合、サーバーは resultCode として authMethodNotSupported を持つ BindResponse を返さなければならない(MUST)。これによりクライアントは、同じ 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 を送る必要はない。クライアントは任意の操作を要求してよく、サーバーはそれらを認証されていないものとして扱わなければならない(MUST)。ディレクトリの検索や変更の前にクライアントがバインドすることを要求するサーバーは、Bind Request または Unbind Request または Extended Request 以外のリクエストを、"operationsError" によって拒否してもよい(MAY)。

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 を受け取った場合、そのクライアントはその後 BindRequest を送信してもよい。それにも失敗するか、クライアントが現在の接続ではバインドしないことを選択する場合、クライアントは接続を閉じて開き直し、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. 証明書を変更するために、クライアントはひとつの接続において複数の Bind Request を送信してよい(MAY)。後からのバインド処理は、その接続で未解決の操作をすべて破棄する効果を持つ。(これによりサーバーの実装が簡単になる。) 先のバインドでの認証はそれ以降無視される。したがってバインドに失敗すると、その接続は匿名として扱われることになる。SASL 転送の暗号化または完全性のメカニズムが取り決められており、かつそのメカニズムがある認証から別の認証への証明書の変更をサポートしていない場合、クライアントは代わりに新しい接続を確立しなければならない(MUST)。

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. 単純認証オプションは、authentication フィールドに平文パスワードのみを含む最低限の認証機能を提供する。下層において認証または暗号化が実行されていない場合、公開されたネットワーク上での平文パスワードの使用は推奨されないことに注意してほしい("セキュリティ考察" セクションを参照)。

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. 認証が実行されない場合、単純認証オプションが選択されなければならず(MUST)、パスワードは長さゼロとなる。(これはしばしば 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] と共に利用されるために定義された任意のメカニズムを可能にする。mechanism フィールドはそのメカニズムの名前を含む。credentials フィールドは認証に使用される任意のデータを含み、OCTET STRING にラップされる。 LDAP は SASL を使用する一部のインターネットアプリケーションプロトコルとは異なりテキストベースではないため、証明書に対する 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 が success の BindResponse をサーバーが送信し、クライアントがそれを受信した後、それらは効果を現す。

The client can request that the server use authentication information from a lower layer protocol by using the SASL EXTERNAL mechanism. クライアントは SASL EXTERNAL メカニズムを使用することにより、サーバーに下層プロトコルの認証情報を使用するよう要求することができる。

4.2.3. Bind Response 4.2.3. Bind Response(バインド応答)

The Bind Response is defined as follows. Bind Response の定義は以下の通り。

        BindResponse ::= [APPLICATION 1] SEQUENCE {
             COMPONENTS OF LDAPResult,
             serverSaslCreds    [7] OCTET STRING OPTIONAL }

BindResponse consists simply of an indication from the server of the status of the client's request for authentication. BindResponse は、クライアントからの認証要求の状態を表すサーバーからの示唆で構成される。

If the bind was successful, the resultCode will be success, otherwise it will be one of: バインドに成功した場合 resultCode は success となり、そうでない場合は以下の何れかとなる:

If the server does not support the client's requested protocol version, it MUST set the resultCode to protocolError. クライアントの要求したプロトコルバージョンをサポートしないサーバーは、resultCode に protocolError をセットしなければならない(MUST)。

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 応答をクライアントが受け取った場合、サーバーはそれ以上の操作を受け付けようとしないため、クライアントは接続を閉じなければならない(MUST)。(これは過去のバージョンの LDAP との互換性のためである。過去のバージョンではバインドが常に最初の操作であり、交渉は存在しなかった。)

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 は、通信中のサーバーの認証、または "チャレンジレスポンス(challenge-response)" 認証の実行をクライアントに許可するために、SASL の定義するバインドメカニズムの一部として使用される。クライアントがパスワード選択に縛られている場合、または SASL メカニズムがサーバーからクライアントに情報を返すよう要求しない場合、このフィールドは結果を含まないべきである。

4.3. Unbind Operation 4.3. Unbind Operation(アンバインド操作)

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

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 が extendedResp の LDAPMessage として生成される。ExtendedResponse の responseName フィールドが提示される。LDAPIOD 値はこの通知に対してユニークでなければならず、その他の状況で使用されてはならない(MUST)。

One unsolicited notification is defined in this document. この文書では未承諾通知がひとつだけ定義されている。

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 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. この通知は、エラー状態のためにサーバーが接続を切断しようとしていることをクライアントに通知するために使用される。これはクライアントによる Unbind Request への応答ではなく、サーバーはセクション 4.3 の手続きに従わなければならない(MUST)ことに注意してほしい。この通知はエラー状態と一時的なネットワーク障害とをクライアントが区別する手助けとなることを目的としている。ネットワーク障害によって接続が切れた場合、クライアントはディレクトリを変更したすべての未解決のリクエストが成功または失敗したと仮定してはならない(MUST NOT)。

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、response フィールドは無し、resultCode は切断の理由を表すために使用される。

The following resultCode values are to be used in this notification: この通知では以下の resultCode の値が使用される:

4.5. Search Operation 4.5. Search Operation(検索操作)

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. Search Operation によりクライアントは、サーバーに代行検索を要求することができる。この操作は、単独のエントリ、またはある特定のエントリの直下、またはエントリのサブツリー全体から属性を読み取るために使用することができる。

4.5.1. Search Request 4.5.1. Search Request(検索要求)

The Search Request is defined as follows: Search Request の定義は以下の通り:

        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 }

        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 }

        SubstringFilter ::= SEQUENCE {
                type            AttributeDescription,
                -- at least one must be present
                substrings      SEQUENCE OF CHOICE {
                        initial [0] LDAPString,
                        any     [1] LDAPString,
                        final   [2] LDAPString } }

        MatchingRuleAssertion ::= SEQUENCE {
                matchingRule    [1] MatchingRuleId OPTIONAL,
                type            [2] AttributeDescription OPTIONAL,
                matchValue      [3] AssertionValue,
                dnAttributes    [4] BOOLEAN DEFAULT FALSE }
        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 }

        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 }

        SubstringFilter ::= SEQUENCE {
                type            AttributeDescription,
                -- 最低ひとつは必要
                substrings      SEQUENCE OF CHOICE {
                        initial [0] LDAPString,
                        any     [1] LDAPString,
                        final   [2] LDAPString } }

        MatchingRuleAssertion ::= SEQUENCE {
                matchingRule    [1] MatchingRuleId OPTIONAL,
                type            [2] AttributeDescription OPTIONAL,
                matchValue      [3] AssertionValue,
                dnAttributes    [4] BOOLEAN DEFAULT FALSE }

Parameters of the Search Request are: Search Request のパラメータは以下の通り:

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. X.500 の "list" のような操作は objectClass 属性の存在を確認するフィルタを持つ一段階の LDAP Search Operation の要求で模倣できること、X.500 の "read" のような操作は同じフィルタを持つベースオブジェクトの LDAP Search Operation で模倣できることに注意してほしい。X.500 へのゲートウェイを提供するサーバーは、Read 操作や List 操作を使用する必要はないが、X.500 の検索操作と同じセマンティクスを提供しなければならないのであれば、それらを使用することを選択してもよい。

4.5.2. Search Result 4.5.2. Search Result(検索結果)

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. Search Request の受け取りによりサーバーが実行した検索の結果は、Search Response 内で返される。Search Response は SearchResultEntry、 SearchResultReference、 ExtendedResponse、 SearchResultDone の何れかのデータ型を含む LDAP メッセージである。

        SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
                objectName      LDAPDN,
                attributes      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.)

        SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL
        -- at least one LDAPURL element must be present

        SearchResultDone ::= [APPLICATION 5] LDAPResult
        SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
                objectName      LDAPDN,
                attributes      PartialAttributeList }

        PartialAttributeList ::= SEQUENCE OF SEQUENCE {
                type    AttributeDescription,
                vals    SET OF AttributeValue }
        -- 実装者は PartialAttributeList の要素数がゼロ(そのエントリの
        -- どの属性も要求されなかった場合、または要素が返されなかった
        -- 場合)でもよいこと、vals 集合の要素数がゼロ(型のみが要求され
        -- た場合、または全ての値が結果から除かれた場合)でもよいことに
        -- 注意すべきである。

        SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL
        -- 少なくともひとつの LDAPURL の要素がなければならない

        SearchResultDone ::= [APPLICATION 5] LDAPResult

Upon receipt of a Search Request, a server will perform the necessary search of the DIT. Search 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 を含めてゼロ個以上の応答が存在してよい。さらに、検索中にサーバーによって調べられなかった領域ごとに、SearchResultReference を含むゼロ個以上の応答が存在してもよい。SearchResultEntry および SearchResultReference の PDU はどちらが先に到着してもよい。サーバーによって返される全ての 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 内で返される各エントリは、必要であれば関連する値も含め、Search Request の属性フィールドで指定された全ての属性を含んでいる。返される属性は、アクセスコントロールやその他の管理ポリシーの影響を受ける。属性によってはバイナリ形式で返されてもよい(バイナリオプションを持つ応答において 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 属性の中に現れる可能性がある。たとえアクセスコントロールで許可されていたとしても、クライアントは全ての属性を変更可能であると仮定してはならない(MUST NOT)。

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 応答は、クライアントによって要求された control に関連する情報を返すために予約されている。これらはこの文書の将来のバージョンで定義されてもよい。

4.5.3. Continuation References in the Search Result 4.5.3. Search Result における継続参照

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. baseObject を参照するエントリに位置付けはできたが、baseObject 上またはその下位のすべてのエントリを検索することはできなかった場合、サーバーは操作を続けるための別のサーバー集合への参照を含むひとつ以上の SearchResultReference を返すことができる。baseObject への位置付けができず、したがってどのエントリも検索できなかった場合、サーバーはいかなる SearchResultReference も返してはならない(MUST NOT)。その場合サーバーは、resultCode に referral を含む SearchResultDone を返す。

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. 下位の名前付けコンテキストを保持するサーバー群からインデックス情報が提供されない場合、SearchResultReferende 応答は検索フィルタの影響を受けず、スコープ内であれば常に返される。

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. SearchResultReference は Referral と同じデータ型である。LDAP プロトコルを実装するサーバーのための URL は [9] にしたがって書かれる。URL 中の <dn> 部は、新しいターゲットのオブジェクト名を伴って必ず指定されなければならない(MUST)。クライアントは次のリクエストでその名前を使用しなければならない(MUST)。ある種のサーバー(例えば、分散インデックス交換システムの一部を構成するサーバー)は、SearchResultReference の URL 内で異なるフィルタを提供する。LDAP URL 内で URL のフィルタ部が指定された場合、クライアントが検索を進めるためにはその次のリクエストで新しいフィルタを使用しなければならない(MUST)。フィルタ部が無かった場合、クライアントは同じフィルタを再び使用することになるだろう。新しい検索リクエストのその他の点は、継続参照を生成した検索と同じであっても、異なっていてもよい。

Other kinds of URLs may be returned so long as the operation could be performed using that protocol. 他の種類の URL が返されてもよいが、その操作がそのプロトコルを使用して実行可能な場合に限られる。

The name of an unexplored subtree in a SearchResultReference need not be subordinate to the base object. SearchResultReference において検索されていないサブツリーの名前は、ベースオブジェクトの下位である必要はない。

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. 検索を完結させるためには、クライアントは返された SearchResultReference ごとに新しい Search Operation を実行しなければならない(MUST)。セクション 4.11 で説明されている Abandon Operation はクライアント・サーバー間の接続上を送られた特定の操作に対してのみ適用され、したがってクライアントが異なるサーバーに対して複数の未解決の Search Operation を保持している場合、個々の操作ごとに破棄を実行しなければならない(MUST)ことに注意してほしい。

4.5.3.1. Example 4.5.3.1. 例

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 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: 例として、接続中のサーバー (hosta) がエントリ "O=MNN,C=WW" と "CN=Manager,O=MNN,C=WW" とを持っていると仮定する。そのサーバーは、LDAP 機能を持つサーバー (hostb)・(hostc) のどちらかが "OU=People,O=MNN,C=WW" を保持していることと、LDAP 機能を持つサーバー (hostd) がサブツリー "OU=Roles,O=MNN,C=WW" を保持していることを知っているとする。"O=MNN,C=WW" のサブツリーの検索をそのサーバーに要求した場合、以下の内容が返されるだろう:

     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: クライアント実装者は、SearchResultReference にしたがった結果、新たな SearchResultReference が生成される可能性があることに注意するべきである。上の例を続けると、クライアントがサーバー (hostb) に接続し、"OU=People,O=MNN,C=WW" のサブツリーの検索を発行した場合、そのサーバーは以下のような応答を返すだろう:

     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. 接続しているサーバーがその検索のためのベースオブジェクトを保持していない場合、そのサーバーはクライアントに参照を返す。例えば、クライアントが hosta に "O=XYZ,C=US" のサブツリー検索を要求した場合、そのサーバーは参照を含む SearchResultDone のみを返してもよい。

     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: Modify Operation によりクライアントは、サーバーにエントリの更新を要求することができる。Modify Request の定義は以下の通り:

        ModifyRequest ::= [APPLICATION 6] SEQUENCE {
                object          LDAPDN,
                modification    SEQUENCE OF SEQUENCE {
                        operation       ENUMERATED {
                                                add     (0),
                                                delete  (1),
                                                replace (2) },
                        modification    AttributeTypeAndValues } }

        AttributeTypeAndValues ::= SEQUENCE {
                type    AttributeDescription,
                vals    SET OF AttributeValue }

Parameters of the Modify Request are: Modify Request のパラメータは以下の通り:

The result of the modify attempted by the server upon receipt of a Modify Request is returned in a Modify Response, defined as follows: Modify Request の受信によってサーバーが試みた更新の結果は、以下のように定義される Modify Response の中で返される:

        ModifyResponse ::= [APPLICATION 7] LDAPResult

Upon receipt of a Modify Request, a server will perform the necessary modifications to the DIT. Modify Request を受信すると、サーバーは DIT に必要な変更を加える。

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. サーバーはクライアントに、DIT 更新の成功か失敗か、どちらかの理由を表す単独の Modify Response を返す。Modify Request における更新リストの適用には原子性の要件があるため、クライアントは、何らかの更新エラーを表す Modify Response を受信した場合にはいかなる DIT の更新も実行されておらず、Modify Operation の成功を表す Modify Response を受信した場合にはすべての更新要求が実行されたと期待してよい。接続障害が発生した場合、その更新が実行されたかどうかは不定となる。

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. あるエントリからそれが持つ識別名(その値はそのエントリの相対識別名である)を削除する目的で Modify Operation を使用することはできない。そのような操作を実行しようとした場合、サーバーは notAllowedOnRDN のエラーを返す。セクション 4.9 で説明されている Modify DN Operation は、エントリの名前を変更するために使用される。

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. ある属性型のための等価検索フィルタが定義されていない場合、クライアントは "delete" を使用してそのエントリから個々の属性値を削除しようと試みてはならず(MUST NOT)、代わりに "replace" を使用しなければならない(MUST)。

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. LDAP の構造は単純化されているため、LDAP の ModifyRequest の更新を、DAP の ModifyEntry 操作の EntryModifications に直接マッピングすることはできない。したがって LDAP-DAP ゲートウェイの様々な実装が、その変更操作を異なる手段で表現する可能性があることに注意してほしい。更新に成功した場合、そのエントリに対する操作の最終的な結果は一致しなければならない(MUST)。

4.7. AddOperation 4.7. AddOperation(追加操作)

The Add Operation allows a client to request the addition of an entry into the directory. The Add Request is defined as follows: Add Operation によりクライアントは、ディレクトリへのエントリの追加を要求することができる。Add Request の定義は以下の通り:

        AddRequest ::= [APPLICATION 8] SEQUENCE {
                entry           LDAPDN,
                attributes      AttributeList }

        AttributeList ::= SEQUENCE OF SEQUENCE {
                type    AttributeDescription,
                vals    SET OF AttributeValue }

Parameters of the Add Request are: Add Request のパラメータは以下の通り:

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. AddRequest の entry フィールド内で指定されたエントリは、後続の AddRequest に現れてはならない(MUST NOT)。追加されるエントリの親は必ず存在しなければならない(MUST)。例えばクライアントが "CN=JS,O=Foo,C=US" を追加しようとしているが、"O=Foo,C=US" というエントリは存在せず、"C=US" というエントリは存在する場合、サーバーは "C=US" を含む matchedDN を持つ noSuchObject エラーを返すだろう。親エントリは存在するがそのサーバーの保持する名前付けコンテキストではない場合、サーバーはその親エントリを保持しているサーバーへの参照を返すべきである(SHOULD)。

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. サーバー実装は、ディレクトリ内でエントリを位置付ける場所を制限するべきではない(SHOULD NOT)。サーバーによっては、ディレクトリに追加できるエントリのクラスを管理者が制限することを許可してもよい(MAY)。

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: Add Request を受信すると、サーバーは要求された追加の実行を試みる。追加を試みた結果は以下のように定義される AddResponse 内でクライアントに返される:

        AddResponse ::= [APPLICATION 9] LDAPResult

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: Delete Operation によりクライアントは、ディレクトリからのエントリ削除を要求することができる。Delete Request の定義は以下の通り:

        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. Delete Request は削除されるエントリの識別名から構成される。サーバーが削除対象のエントリ名を解決する際にエイリアスの逆参照を行わないこと、および、この操作で削除できるのは末端のエントリ(つまり下位エントリを持たないエントリ)のみであることに注意してほしい。

The result of the delete attempted by the server upon receipt of a Delete Request is returned in the Delete Response, defined as follows: Delete Request の受信によってサーバーが試みた削除の結果は、以下のように定義される Delete Response 内で返される。

        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. Delete Request を受信すると、サーバーは要求されたエントリの削除を試みる。その結果は Delete Response 内でクライアントに返される。

4.9. Modify DN Operation 4.9. Modify DN Operation(DN 更新操作)

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: Modify DN Operation によりクライアントは、ディレクトリ内のエントリの名前の最左(最下位)の構成要素を変更、またはエントリのサブツリーをディレクトリ内の新しい位置に移動することができる。Modify DN Request の定義は以下の通り:

        ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
                entry           LDAPDN,
                newrdn          RelativeLDAPDN,
                deleteoldrdn    BOOLEAN,
                newSuperior     [0] LDAPDN OPTIONAL }

Parameters of the Modify DN Request are: Modify DN Request のパラメータは以下の通り:

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: Modify DN Request の受信によりサーバーが試みた名前変更の結果は、以下のように定義される Modify DN Response 内で返される:

        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. Modify DN Request を受信すると、サーバーはその名前変更を試みる。その結果は 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 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. 例えば、"entry" パラメータ内で指定されたパラメータが "cn=John Smith,c=US" で、newrdn パラメータが "cn=John Cougar Smith"、newSuperior パラメータが無しの場合、その操作はエントリを "cn=John Cougar Smith,c=US" に改名しようと試みていることになる。その名前のエントリが既に存在する場合、エラーコード 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. deleteoldrdn パラメータが TRUE の場合、古い RDN を形成していた値はエントリーから削除される。deleteoldrdn パラメータが FALSE の場合、古い RDN を形成していた値は、そのエントリの区別できない属性値として保持される。deleteoldrdn パラメータの内容がそのエントリのスキーマに不一致を引き起こす場合、サーバーはその操作を実行せず、エラーコードを返す。

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. X.500 では、ModifyDN Operation が影響を与えるのは単独のサーバー内に含まれるエントリのみに制限されていることに注意してほしい。LDAP サーバーが DAP にマップされている場合にこの制限が適用され、エラーが発生した場合には resultCode として affectsMultipleDSAs が返される。一般にクライアントは、複数サーバー間でエントリやサブツリーの任意の移動を実行できると期待してはならない(MUST NOT)。

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: Compare Operation によりクライアントは、ディレクトリ内のエントリと共に提供されるアサーションを比較することができる。Compare Request の定義は以下の通り:

        CompareRequest ::= [APPLICATION 14] SEQUENCE {
                entry           LDAPDN,
                ava             AttributeValueAssertion }

Parameters of the Compare Request are: Compare Request のパラメータは以下の通り:

The result of the compare attempted by the server upon receipt of a Compare Request is returned in the Compare Response, defined as follows: Compare Request の受信によりサーバーが試みた比較の結果は、以下のように定義される Compare Response 内で返される:

        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. Compare Request を受信すると、サーバーは要求された比較の実行を試みる。その結果は Compare Response 内でクライアントに返される。比較の結果とエラーとが共に同じ構造体で返されることに注意してほしい。

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. ディレクトリシステムによっては、特定の属性(例えば userPassword)の値に対し、比較はできるが読み取りはできないアクセスコントロールを定めている可能性があること注意してほしい。検索の結果においてそのような種類の属性には空の値が返されてもよい。

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: Abandon Operation によりクライアントは、サーバーに未解決の操作を破棄するように要求することができる。Abandon Request の定義は以下の通り:

        AbandonRequest ::= [APPLICATION 16] MessageID

The MessageID MUST be that of a an operation which was requested earlier in this connection. MessageID はその接続で以前に要求された操作の MessageID でなければならない(MUST)。

(The abandon request itself has its own message id. This is distinct from the id of the earlier operation being abandoned.) (Abandon Request 自身もメッセージ ID を持っており、破棄される操作の ID とは区別される。)

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. Abandon Operation に応答は定義されていない。Abandon Operation を送信した時点で、クライアントは Abandon Request 内の Message ID によって識別される操作が破棄されたことを期待してよい。Search Operation の応答を送信中にサーバーが Abandon Request を受信した場合、サーバーは中断されたリクエストに応えるエントリの送信を直ちに停止しなければならず(MUST)、SearchResponseDone を送信してはならない(MUST NOT)。当然ながら、サーバーは適切に暗号化された LDAPMessage PDU のみが送信されたことを保証しなければならない(MUST)。

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). クライアントは同じ操作に対して複数の Abandon Request を送信してはならない(MUST NOT)。また、破棄を要求した時点ですでに送信中の可能性があるため、破棄した操作からの結果を受信する準備をしていなければならない(MUST)。

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. サーバーは、認識できない MessageID に対する Abandon Request、破棄できない操作に対する Abandon Request、既に破棄された操作に対する Abandon Request を破棄しなければならない(MUST)。

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. 利用不可能なサービス(例えばデジタル署名とその結果)のために、LDAP のこのバージョンでは、付加操作の定義を可能にする拡張メカニズムが追加された。

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. Extended Operation によりクライアントは、事前に定義した文法とセマンティクスとを使って要求を行い、その応答を受け取ることが可能になる。文法と動作は RFC において定義されるか、特定の実装のためにプライベートに定義することができる。各リクエストはそれに割り当てられたユニークな OBJECT IDENTIFIER を持たなければならない(MUST)。

        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. requestName はその要求に対応する OBJECT IDENTIFIER のドット区切り 10 進表現である。requestValue はその要求によって定義される形式の情報で、OBJECT STRING 内部にカプセル化される。

The server will respond to this with an LDAPMessage containing the ExtendedResponse. サーバーは ExtendedResponse を含む LDAPMessage でこれに応答する。

        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. サーバーが requestName を認識できない場合、resultCode に protocolError を持つ LDAPResult の response フィールドのみのを返さなければならない(MUST)。

5. Protocol Element Encodings and Transfer 5. プロトコル要素のエンコードと転送

One underlying service is defined here. Clients and servers SHOULD implement the mapping of LDAP over TCP described in 5.2.1. ここでは下位サービスがひとつ定義される。クライアントとサーバーは 5.2.1 で説明されている LDAP over TCP のマッピングを実装するべきである(SHOULD)。

5.1. Mapping Onto BER-based Transport Services 5.1. BER ベースのトランスポートサービスへのマッピング

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: LDAP のプロトコル要素は、ASN.1[3] の Basic Encoding Rules (BER)[11] を使用してエンコードされた上で交換される。しかしながら BER の特定の要素を使用することに関連する高いオーバーヘッドのため、LDAP プロトコル要素の BER エンコードには以下の制限が追加される:

These restrictions do not apply to ASN.1 types encapsulated inside of OCTET STRING values, such as attribute values, unless otherwise noted. 特に明記しない限り、これらの制限は OCTET STRING 値の内部にカプセル化された ASN.1 の型には適用されない。

5.2. Transfer Protocols 5.2. 通信プロトコル

This protocol is designed to run over connection-oriented, reliable transports, with all 8 bits in an octet being significant in the data stream. このプロトコルは、データストリーム内で 1 オクテットの 8 ビットすべてが有効なコネクション指向の信頼できるトランスポート上で動作するように設計されている。

5.2.1. Transmission Control Protocol (TCP) 5.2.1. 伝送制御プロトコル (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. LDAPMessage の PDU は TCP のバイトストリームに直接マッピングされる。TCP 上で動作するサーバー実装は、割り当て済みポート 389 でプロトコルリスナーを提供することを推奨される。サーバーは異なるポート番号でリスナーを提供してもよい(MAY)。クライアントは任意の有効な TCP ポート上でのサーバーとの通信をサポートしなければならない(MUST)。

6. Implementation Guidelines 6. 実装ガイドライン

This document describes an Internet protocol. この文書はインターネットプロトコルを説明している。

6.1. Server Implementations 6.1. サーバー実装

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. サーバーは、すべての必須の属性型名を認識する能力を持ち、[5] の文法規約を実装しなければならない(MUST)。サーバーは追加の属性型名を認識してもよい(MAY)。

6.2. Client Implementations 6.2. クライアント実装

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. 参照を要求するクライアントは、サーバー間でループしないことを保証しなければならない(MUST)。クライアントは、同じターゲットエントリ名・スコープ・フィルタを持つ同じリクエストを、同じサーバーに繰り返し送信てはならない(MUST NOT)。クライアントは操作のために発生した参照処理ごとにインクリメントされるカウンタを使用してもよく、そのようなクライアントは、ルートとリーフのエントリ間で少なくとも 10 階層の名前付けコンテキストを持つ DIT を処理できなければならない(MUST)。

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. サーバーに関する前述の合意がない場合、クライアントは、セクション 6.1 で言及されているスキーマの範囲を超える特別なスキーマをサーバーがサポートしていると仮定するべきではない(SHOULD NOT)。異なるスキーマであれば、同じ名前でも異なる属性型を持つことができる。クライアントは、サーバーのルート DSE またはサーバーによって保持されているエントリのどちらかの subschemaSubentry 属性によって参照されるサブスキーマエントリを取得することができる。

7. Security Considerations 7. セキュリティ考察

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. コネクション指向の通信を使用する場合、このプロトコルのこのバージョンは、任意の SASL メカニズム [12] はもちろん、LDAP v2 認証メカニズムや平文パスワードによる単純認証のための機能も提供する。SASL により、完全性および機密性のサービスを交渉できる。

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. 下層のトランスポートサービスが信頼性を保証できず、認証されない参加者にパスワードが開示される可能性がある場合、平文パスワードの使用はまったく推奨されない。

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. SASL を使用する場合、BindRequest の name フィールドは更新に対して保護されないことに注意するべきである。すなわち、証明書による取り決めを通してクライアントの識別名(LDAPDN)が合意されている場合、それは保護されていない name フィールド内のすべての値に優先するということである。

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. サーバーは特定の認証済みクライアント以外への検索結果にエントリや属性を返すことを禁止するアクセスコントロールポリシーを持ってもよいため、LDAP 経由で取得した属性やエントリをキャッシュする実装は、その情報が複数のクライアントに提供される場合でも、アクセスコントロールが維持されることを保証しなければならない(MUST)。例えばキャッシュは、そのキャッシュされたリクエストを発行したクライアントに対してのみ、その結果情報を提供できるだろう。

8. Acknowledgements 8. 謝辞

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. この文書は Wengyik Yeong, Tim Howes, Steve Kille による RFC 1777 のアップデートである。この文書内に含まれる設計のアイデアは、ASID やその他の IETF ワーキンググループで議論されたものに基づいている。これらのワーキンググループの個人の貢献者に深く感謝する。

9. Bibliography 9. 参考文献

[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.

[3] ITU-T Rec. X.680, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", 1994.

[4] Kille, S., Wahl, M., and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997.

[5] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997.

[6] ITU-T Rec. X.501, "The Directory: Models", 1993.

[7] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.

[8] ITU-T Rec. X.511, "The Directory: Abstract Service Definition", 1993.

[9] Howes, T., and M. Smith, "The LDAP URL Format", RFC 2255, December 1997.

[10] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.

[11] ITU-T Rec. X.690, "Specification of ASN.1 encoding rules: Basic, Canonical, and Distinguished Encoding Rules", 1994.

[12] Meyers, J., "Simple Authentication and Security Layer", RFC 2222, October 1997.

[13] Universal Multiple-Octet Coded Character Set (UCS) - Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 : 1993.

[14] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996.

10. Authors' Addresses 10. 作者の連絡先

   Mark Wahl
   Critical Angle Inc.
   4815 W Braker Lane #502-385
   Austin, TX 78759
   USA

   Phone:  +1 512 372-3160
   EMail:  M.Wahl@critical-angle.com

   Tim Howes
   Netscape Communications Corp.
   501 E. Middlefield Rd., MS MV068
   Mountain View, CA 94043
   USA

   Phone:  +1 650 937-3419
   EMail:   howes@netscape.com

   Steve Kille
   Isode Limited
   The Dome, The Square
   Richmond
   TW9 1DT
   UK

   Phone:  +44-181-332-9091
   EMail:  S.Kille@isode.com

Appendix A - Complete ASN.1 Definition 付録 A - 完全な ASN.1 定義

        Lightweight-Directory-Access-Protocol-V3 DEFINITIONS
        IMPLICIT TAGS ::=

        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 }

        MessageID ::= INTEGER (0 .. maxInt)

        maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --

        LDAPString ::= OCTET STRING

        LDAPOID ::= OCTET STRING

        LDAPDN ::= LDAPString

        RelativeLDAPDN ::= LDAPString

        AttributeType ::= LDAPString

        AttributeDescription ::= LDAPString

        AttributeDescriptionList ::= SEQUENCE OF
                AttributeDescription

        AttributeValue ::= OCTET STRING

        AttributeValueAssertion ::= SEQUENCE {
                attributeDesc   AttributeDescription,
                assertionValue  AssertionValue }

        AssertionValue ::= OCTET STRING

        Attribute ::= SEQUENCE {
                type    AttributeDescription,
                vals    SET OF AttributeValue }

        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),
                             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 }
        LDAPResult ::= SEQUENCE {
                resultCode      ENUMERATED {
                             success                      (0),
                             operationsError              (1),
                             protocolError                (2),
                             timeLimitExceeded            (3),
                             sizeLimitExceeded            (4),
                             compareFalse                 (5),
                             compareTrue                  (6),
                             authMethodNotSupported       (7),
                             strongAuthRequired           (8),
                                        -- 9 予約済み --
                             referral                     (10),  -- 新規
                             adminLimitExceeded           (11),  -- 新規
                             unavailableCriticalExtension (12),  -- 新規
                             confidentialityRequired      (13),  -- 新規
                             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),
                             invalidCredentials           (49),
                             insufficientAccessRights     (50),
                             busy                         (51),
                             unavailable                  (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 未使用 --
                             other                        (80) },
                             -- 81-90 は API のために予約済み --
                matchedDN       LDAPDN,
                errorMessage    LDAPString,
                referral        [3] Referral OPTIONAL }
        Referral ::= SEQUENCE OF 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 }

        BindRequest ::= [APPLICATION 0] SEQUENCE {
                version                 INTEGER (1 .. 127),
                name                    LDAPDN,
                authentication          AuthenticationChoice }
        AuthenticationChoice ::= CHOICE {
                simple                  [0] OCTET STRING,
                                         -- 1 and 2 reserved
                sasl                    [3] SaslCredentials }
        AuthenticationChoice ::= CHOICE {
                simple                  [0] OCTET STRING,
                                         -- 1 と 2 は予約済み
                sasl                    [3] SaslCredentials }
        SaslCredentials ::= SEQUENCE {
                mechanism               LDAPString,
                credentials             OCTET STRING OPTIONAL }

        BindResponse ::= [APPLICATION 1] SEQUENCE {

             COMPONENTS OF LDAPResult,
             serverSaslCreds    [7] OCTET STRING OPTIONAL }

        UnbindRequest ::= [APPLICATION 2] NULL

        SearchRequest ::= [APPLICATION 3] SEQUENCE {
                baseObject      LDAPDN,
                scope           ENUMERATED {
                        baseObject              (0),
                        singleLevel             (1),
                        wholeSubtree            (2) },
                derefAliases    ENUMERATED {
                        neverDerefAliases       (0),
                        derefInSearching        (1),
                        derefFindingBaseObj     (2),
                        derefAlways             (3) },
                sizeLimit       INTEGER (0 .. maxInt),
                timeLimit       INTEGER (0 .. maxInt),
                typesOnly       BOOLEAN,
                filter          Filter,
                attributes      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 }

        SubstringFilter ::= SEQUENCE {
                type            AttributeDescription,
                -- at least one must be present
                substrings      SEQUENCE OF CHOICE {
                        initial [0] LDAPString,
                        any     [1] LDAPString,
                        final   [2] LDAPString } }

        MatchingRuleAssertion ::= SEQUENCE {
                matchingRule    [1] MatchingRuleId OPTIONAL,
                type            [2] AttributeDescription OPTIONAL,
                matchValue      [3] AssertionValue,
                dnAttributes    [4] BOOLEAN DEFAULT FALSE }

        SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
                objectName      LDAPDN,
                attributes      PartialAttributeList }

        PartialAttributeList ::= SEQUENCE OF SEQUENCE {
                type    AttributeDescription,
                vals    SET OF AttributeValue }

        SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL

        SearchResultDone ::= [APPLICATION 5] LDAPResult

        ModifyRequest ::= [APPLICATION 6] SEQUENCE {
                object          LDAPDN,
                modification    SEQUENCE OF SEQUENCE {
                        operation       ENUMERATED {
                                                add     (0),
                                                delete  (1),
                                                replace (2) },
                        modification    AttributeTypeAndValues } }

        AttributeTypeAndValues ::= SEQUENCE {
                type    AttributeDescription,
                vals    SET OF AttributeValue }

        ModifyResponse ::= [APPLICATION 7] LDAPResult

        AddRequest ::= [APPLICATION 8] SEQUENCE {
                entry           LDAPDN,
                attributes      AttributeList }

        AttributeList ::= SEQUENCE OF SEQUENCE {
                type    AttributeDescription,
                vals    SET OF AttributeValue }

        AddResponse ::= [APPLICATION 9] LDAPResult

        DelRequest ::= [APPLICATION 10] LDAPDN

        DelResponse ::= [APPLICATION 11] LDAPResult

        ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
                entry           LDAPDN,
                newrdn          RelativeLDAPDN,
                deleteoldrdn    BOOLEAN,
                newSuperior     [0] LDAPDN OPTIONAL }

        ModifyDNResponse ::= [APPLICATION 13] LDAPResult

        CompareRequest ::= [APPLICATION 14] SEQUENCE {
                entry           LDAPDN,
                ava             AttributeValueAssertion }

        CompareResponse ::= [APPLICATION 15] LDAPResult

        AbandonRequest ::= [APPLICATION 16] MessageID

        ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
                requestName      [0] LDAPOID,
                requestValue     [1] OCTET STRING OPTIONAL }

        ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
                COMPONENTS OF LDAPResult,
                responseName     [10] LDAPOID OPTIONAL,
                response         [11] OCTET STRING OPTIONAL }

        END

Full Copyright Statement

Copyright (C) The Internet Society (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.

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.