RFC4521 日本語訳

Network Working Group                                        K. Zeilenga
Request for Comments: 4521                           OpenLDAP Foundation
BCP: 118                                                       June 2006
Category: Best Current Practice

Zeilengaがコメントのために要求するワーキンググループK.をネットワークでつないでください: 4521OpenLDAP財団BCP: 118 2006年6月のカテゴリ: 最も良い現在の習慣

                          Considerations for
        Lightweight Directory Access Protocol (LDAP) Extensions

ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)拡大のための問題

Status of This Memo

このメモの状態

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(2006)。

Abstract

要約

   The Lightweight Directory Access Protocol (LDAP) is extensible.  It
   provides mechanisms for adding new operations, extending existing
   operations, and expanding user and system schemas.  This document
   discusses considerations for designers of LDAP extensions.

ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)は広げることができます。 既存の操作を広げていて、ユーザとシステムschemasを広げて、それは新しい操作を加えるのにメカニズムを提供します。 このドキュメントはLDAP拡張子のデザイナーのために問題について議論します。

Zeilenga                 Best Current Practice                  [Page 1]

RFC 4521                    LDAP Extensions                    June 2006

最も良い現在のZeilengaの練習[1ページ]RFC4521LDAP拡大2006年6月

Table of Contents

目次

   1. Introduction ....................................................3
      1.1. Terminology ................................................3
   2. General Considerations ..........................................4
      2.1. Scope of Extension .........................................4
      2.2. Interaction between extensions .............................4
      2.3. Discovery Mechanism ........................................4
      2.4. Internationalization Considerations ........................5
      2.5. Use of the Basic Encoding Rules ............................5
      2.6. Use of Formal Languages ....................................5
      2.7. Examples ...................................................5
      2.8. Registration of Protocol Values ............................5
   3. LDAP Operation Extensions .......................................6
      3.1. Controls ...................................................6
           3.1.1. Extending Bind Operation with Controls ..............6
           3.1.2. Extending the Start TLS Operation with Controls .....7
           3.1.3. Extending the Search Operation with Controls ........7
           3.1.4. Extending the Update Operations with Controls .......8
           3.1.5. Extending the Responseless Operations with Controls..8
      3.2. Extended Operations ........................................8
      3.3. Intermediate Responses .....................................8
      3.4. Unsolicited Notifications ..................................9
   4. Extending the LDAP ASN.1 Definition .............................9
      4.1. Result Codes ...............................................9
      4.2. LDAP Message Types .........................................9
      4.3. Authentication Methods ....................................10
      4.4. General ASN.1 Extensibility ...............................10
   5. Schema Extensions ..............................................10
      5.1. LDAP Syntaxes .............................................11
      5.2. Matching Rules ............................................11
      5.3. Attribute Types ...........................................12
      5.4. Object Classes ............................................12
   6. Other Extension Mechanisms .....................................12
      6.1. Attribute Description Options .............................12
      6.2. Authorization Identities ..................................12
      6.3. LDAP URL Extensions .......................................12
   7. Security Considerations ........................................12
   8. Acknowledgements ...............................................13
   9. References .....................................................13
      9.1. Normative References ......................................13
      9.2. Informative References ....................................15

1. 序論…3 1.1. 用語…3 2. 一般問題…4 2.1. 拡大の範囲…4 2.2. 拡大の間の相互作用…4 2.3. 発見メカニズム…4 2.4. 国際化問題…5 2.5. 基本的なコード化の使用は統治されます…5 2.6. 形式言語の使用…5 2.7. 例…5 2.8. プロトコル値の登録…5 3. LDAP操作拡張子…6 3.1. コントロール…6 3.1.1. コントロールでひもの操作を広げています…6 3.1.2. コントロールでスタートTLS操作を広げています…7 3.1.3. コントロールで索敵行動を広げています…7 3.1.4. コントロールでアップデート操作を広げています…8 3.1.5. コントロールでResponseless操作を広げています。8 3.2. 操作を広げています…8 3.3. 中間的応答…8 3.4. 求められていない通知…9 4. LDAP ASN.1定義を広げています…9 4.1. 結果コード…9 4.2. LDAPメッセージタイプ…9 4.3. 認証メソッド…10 4.4. ASN.1司令官伸展性…10 5. 図式拡大…10 5.1. LDAP構文…11 5.2. 合っている規則…11 5.3. タイプを結果と考えてください…12 5.4. クラスは反対します…12 6. 他の拡張機能…12 6.1. 記述オプションを結果と考えてください…12 6.2. 承認のアイデンティティ…12 6.3. LDAP URL拡張子…12 7. セキュリティ問題…12 8. 承認…13 9. 参照…13 9.1. 標準の参照…13 9.2. 有益な参照…15

Zeilenga                 Best Current Practice                  [Page 2]

RFC 4521                    LDAP Extensions                    June 2006

最も良い現在のZeilengaの練習[2ページ]RFC4521LDAP拡大2006年6月

1.  Introduction

1. 序論

   The Lightweight Directory Access Protocol (LDAP) [RFC4510] is an
   extensible protocol.

ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)[RFC4510]は広げることができるプロトコルです。

   LDAP allows for new operations to be added and for existing
   operations to be enhanced [RFC4511].

LDAPは、加えられて、既存の操作が機能アップされる[RFC4511]ために新しい操作を考慮します。

   LDAP allows additional schema to be defined [RFC4512][RFC4517].  This
   can include additional object classes, attribute types, matching
   rules, additional syntaxes, and other elements of schema.  LDAP
   provides an ability to extend attribute types with options [RFC4512].

LDAPは、追加図式が定義されるのを[RFC4512][RFC4517]許容します。 これは図式の追加オブジェクトのクラス、属性タイプ、合っている規則、追加構文、および他の原理を含むことができます。 LDAPはオプション[RFC4512]を属性タイプを広げる能力に提供します。

   LDAP supports a Simple Authentication and Security Layer (SASL)
   authentication method [RFC4511][RFC4513].  SASL [RFC4422] is
   extensible.  LDAP may be extended to support additional
   authentication methods [RFC4511].

LDAPは、Simple AuthenticationとSecurity Layer(SASL)が認証方法[RFC4511][RFC4513]であるとサポートします。 SASL[RFC4422]は広げることができます。 LDAPは、追加認証方法が[RFC4511]であるとサポートするために広げられるかもしれません。

   LDAP supports establishment of Transport Layer Security (TLS)
   [RFC4511][RFC4513].  TLS [RFC4346] is extensible.

LDAPはTransport Layer Security(TLS)[RFC4511][RFC4513]の設立をサポートします。 TLS[RFC4346]は広げることができます。

   LDAP has an extensible Uniform Resource Locator (URL) format
   [RFC4516].

LDAPには、広げることができるUniform Resource Locator(URL)形式[RFC4516]があります。

   Lastly, LDAP allows for certain extensions to the protocol's Abstract
   Syntax Notation - One (ASN.1) [X.680] definition to be made.  This
   facilitates a wide range of protocol enhancements, for example, new
   result codes needed to support extensions to be added through
   extension of the protocol's ASN.1 definition.

最後に、LDAPはプロトコルの抽象的なSyntax Notationにおいて、ある拡大を考慮します--される1つ(ASN.1)[X.680]の定義。 これは例えば、新しい結果コードがプロトコルのASN.1定義の拡大で加えられるために拡大をサポートするために必要としたさまざまなプロトコル増進を容易にします。

   This document describes practices that engineers should consider when
   designing extensions to LDAP.

このドキュメントはLDAPに拡大を設計するとき技術者が考えるべきである習慣について説明します。

1.1.  Terminology

1.1. 用語

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14 [RFC2119].  In
   this document, "the specification", as used by BCP 14, RFC 2119,
   refers to the engineering of LDAP extensions.

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14[RFC2119]で説明されるように本書では解釈されることであるべきですか? 本書では、BCP14、RFC2119年までに使用される「仕様」はLDAP拡張子の工学を示します。

   The term "Request Control" refers to a control attached to a client-
   generated message sent to a server.  The term "Response Control"
   refers to a control attached to a server-generated message sent to a
   client.

「コントロールを要求してください」という用語はサーバに送られたメッセージであると生成されたクライアントに愛着しているコントロールについて言及します。「応答制御」という用語はクライアントに送られたサーバで発生しているメッセージに取り付けられたコントロールについて言及します。

Zeilenga                 Best Current Practice                  [Page 3]

RFC 4521                    LDAP Extensions                    June 2006

最も良い現在のZeilengaの練習[3ページ]RFC4521LDAP拡大2006年6月

   DIT stands for Directory Information Tree.
   DSA stands for Directory System Agent, a server.
   DSE stands for DSA-Specific Entry.
   DUA stands for Directory User Agent, a client.
   DN stands for Distinguished Name.

DITはディレクトリ情報Treeを表します。 DSAはディレクトリSystemエージェント、サーバを表します。DSEはDSA特有のEntryを表します。 DUAはディレクトリUserエージェント、クライアントを表します。 DNはDistinguished Nameを表します。

2.  General Considerations

2. 一般問題

2.1.  Scope of Extension

2.1. 拡大の範囲

   Mutually agreeing peers may, within the confines of an extension,
   agree to significant changes in protocol semantics.  However,
   designers MUST consider the impact of an extension upon protocol
   peers that have not agreed to implement or otherwise recognize and
   support the extension.  Extensions MUST be "truly optional"
   [RFC2119].

互いに同輩に同意すると、プロトコル意味論における著しい変化は拡大の境界の中で同意するかもしれません。 しかしながら、デザイナーはそうでなければ、認識して、拡大を実装するか、またはサポートするのに同意していないプロトコル同輩で、拡大の影響を考えなければなりません。 拡大は「本当に、任意でなければならない」[RFC2119]。

2.2.  Interaction between extensions

2.2. 拡大の間の相互作用

   Designers SHOULD consider how extensions they engineer interact with
   other extensions.

デザイナーSHOULDは、彼らが設計する拡大がどのように他の拡大と対話するかを考えます。

   Designers SHOULD consider the extensibility of extensions they
   specify.  Extensions to LDAP SHOULD themselves be extensible.

デザイナーSHOULDはそれらが指定する拡大の伸展性を考えます。 LDAP SHOULDへの拡大自体、広げることができてください。

   Except where it is stated otherwise, extensibility is implied.

それが別の方法で述べられているところを除いて、伸展性は含意されます。

2.3.  Discovery Mechanism

2.3. 発見メカニズム

   Extensions SHOULD provide adequate discovery mechanisms.

拡大SHOULDは適切な発見メカニズムを提供します。

   As LDAP design is based upon the client-request/server-response
   paradigm, the general discovery approach is for the client to
   discover the capabilities of the server before utilizing a particular
   extension.  Commonly, this discovery involves querying the root DSE
   and/or other DSEs for operational information associated with the
   extension.  LDAP provides no mechanism for a server to discover the
   capabilities of a client.

LDAPデザインがサーバクライアント要求/応答パラダイムに基づいているとき、一般的な発見アプローチは特定の拡大を利用する前にクライアントがサーバの能力を発見することです。 一般的に、この発見は、拡大に関連している運用情報のために根のDSE、そして/または、他のDSEsについて質問することを伴います。 サーバがクライアントの能力を発見するように、LDAPはメカニズムを全く提供しません。

   The 'supportedControl' attribute [RFC4512] is used to advertise
   supported controls.  The 'supportedExtension' attribute [RFC4512] is
   used to advertise supported extended operations.  The
   'supportedFeatures' attribute [RFC4512] is used to advertise
   features.  Other root DSE attributes MAY be defined to advertise
   other capabilities.

'supportedControl'属性[RFC4512]は、サポートしているコントロールの広告を出すのに使用されます。 'supportedExtension'属性[RFC4512]は、サポートしている拡大手術の広告を出すのに使用されます。 'supportedFeatures'属性[RFC4512]は、特徴の広告を出すのに使用されます。 他の根のDSE属性は、他の能力の広告を出すために定義されるかもしれません。

Zeilenga                 Best Current Practice                  [Page 4]

RFC 4521                    LDAP Extensions                    June 2006

最も良い現在のZeilengaの練習[4ページ]RFC4521LDAP拡大2006年6月

2.4.  Internationalization Considerations

2.4. 国際化問題

   LDAP is designed to support the full Unicode [Unicode] repertory of
   characters.  Extensions SHOULD avoid unnecessarily restricting
   applications to subsets of Unicode (e.g., Basic Multilingual Plane,
   ISO 8859-1, ASCII, Printable String).

LDAPは、完全なユニコード[ユニコード]がキャラクタのレパートリー制であるとサポートするように設計されています。 拡大SHOULDは、不必要にアプリケーションをユニコード(例えば、基本多言語水準、ISO8859-1、ASCII、Printable String)の部分集合に制限するのを避けます。

   LDAP Language Tag options [RFC3866] provide a mechanism for tagging
   text (and other) values with language information.  Extensions that
   define attribute types SHOULD allow use of language tags with these
   attributes.

LDAP Language Tagオプション[RFC3866]はテキストの、そして、(他)の値に言語情報をタグ付けするのにメカニズムを提供します。 属性タイプSHOULDを定義する拡大がこれらの属性がある言語タグの使用を許します。

2.5.  Use of the Basic Encoding Rules

2.5. 基本的な符号化規則の使用

   Numerous elements of LDAP are described using ASN.1 [X.680] and are
   encoded using a particular subset [Protocol, Section 5.2] of the
   Basic Encoding Rules (BER) [X.690].  To allow reuse of
   parsers/generators used in implementing the LDAP "core" technical
   specification [RFC4510], it is RECOMMENDED that extension elements
   (e.g., extension specific contents of controlValue, requestValue,
   responseValue fields) described by ASN.1 and encoded using BER be
   subjected to the restrictions of [Protocol, Section 5.2].

LDAPの多数の要素は、ASN.1[X.680]を使用することで説明されて、Basic Encoding Rules(BER)[X.690]の特定の部分集合[プロトコル、セクション5.2]を使用することでコード化されます。 LDAP「コア」が技術仕様書[RFC4510]であると実装する際に使用されるパーサ/ジェネレータの再利用を許すために、ASN.1によって説明されて、BERを使用することでコード化された拡大要素(例えば、controlValue、requestValue、responseValue分野の拡大の特定のコンテンツ)が[プロトコル、セクション5.2]の制限にかけられるのは、RECOMMENDEDです。

2.6.  Use of Formal Languages

2.6. 形式言語の使用

   Formal languages SHOULD be used in specifications in accordance with
   IESG guidelines [FORMAL].

形式言語SHOULD、IESGガイドライン[FORMAL]に従って、仕様で使用されてください。

2.7.  Examples

2.7. 例

   Example DN strings SHOULD conform to the syntax defined in [RFC4518].
   Example LDAP filter strings SHOULD conform to the syntax defined in
   [RFC4515].  Example LDAP URLs SHOULD conform to the syntax defined in
   [RFC4516].  Entries SHOULD be represented using LDIF [RFC2849].

SHOULDが[RFC4518]で定義された構文に従わせる例のDNストリング。 例のLDAPはSHOULDが[RFC4515]で定義された構文に従わせるストリングをフィルターにかけます。 例のLDAP URL SHOULDは[RFC4516]で定義された構文に従います。 エントリーSHOULD、LDIF[RFC2849]を使用することで、表されてください。

2.8.  Registration of Protocol Values

2.8. プロトコル値の登録

   Designers SHALL register protocol values of their LDAP extensions in
   accordance with BCP 64, RFC 4520 [RFC4520].  Specifications that
   create new extensible protocol elements SHALL extend existing
   registries or establish new registries for values of these elements
   in accordance with BCP 64, RFC 4520 [RFC4520] and BCP 26, RFC 2434
   [RFC2434].

BCP64、RFC4520[RFC4520]に従って、デザイナーSHALLはそれらのLDAP拡張子のプロトコル値を示します。 BCP64とRFC4520[RFC4520]とBCP26RFC2434[RFC2434]によると、新しい広げることができるプロトコル要素SHALLを作成する仕様は、これらの要素の値のために既存の登録を広げているか、または新しい登録を確立します。

Zeilenga                 Best Current Practice                  [Page 5]

RFC 4521                    LDAP Extensions                    June 2006

最も良い現在のZeilengaの練習[5ページ]RFC4521LDAP拡大2006年6月

3.  LDAP Operation Extensions

3. LDAP操作拡張子

   Extensions SHOULD use controls in defining extensions that complement
   existing operations.  Where the extension to be defined does not
   complement an existing operation, designers SHOULD consider defining
   an extended operation instead.

拡大SHOULDは既存の操作の補足となる拡大を定義する際にコントロールを使用します。 定義されるべき拡大が既存の操作の補足とならないところでは、デザイナーSHOULDは、代わりに拡大手術を定義すると考えます。

   For example, a subtree delete operation could be designed as either
   an extension of the delete operation or as a new operation.  As the
   feature complements the existing delete operation, use of the control
   mechanism to extend the delete operation is likely more appropriate.

例えば、下位木が削除する、拡大として操作を設計できた、操作を削除するか、または新しい操作として。 特徴が存在の補足となるように操作を削除してください、広げる制御機構の使用、削除、操作はおそらくより適切です。

   As a counter (and contrived) example, a locate services operation (an
   operation that would return for a DN a set of LDAP URLs to services
   that may hold the entry named by this DN) could be designed as either
   a search operation or a new operation.  As the feature doesn't
   complement the search operation (e.g., the operation is not contrived
   to search for entries held in the Directory Information Tree), it is
   likely more appropriate to define a new operation using the extended
   operation mechanism.

カウンタ(そして、案出される)として、例、aはサービスの場所を見つけます。索敵行動か新しい操作のどちらかとして操作(DNのためにこのDNがエントリーを命名するように主張するかもしれないサービスに1セットのLDAP URLを返す操作)は設計できました。 特徴が索敵行動の補足とならないとき(例えば操作はディレクトリ情報Treeに保持されたエントリーを捜し求めるために案出されません)、拡大手術メカニズムを使用する新しい操作を定義するのはおそらくより適切です。

3.1.  Controls

3.1. コントロール

   Controls [Protocol, Section 4.1.11] are the RECOMMENDED mechanism for
   extending existing operations.  The existing operation can be a base
   operation defined in [RFC4511] (e.g., search, modify) , an extended
   operation (e.g., Start TLS [RFC4511], Password Modify [RFC3062]), or
   an operation defined as an extension to a base or extended operation.

コントロール[プロトコル、セクション4.1.11]は、既存の操作を広げるためのRECOMMENDEDメカニズムです。 既存の操作が[RFC4511]で定義されたベース操作であるかもしれない、(例えば、探してください、変更、)、拡大手術(例えば、Start TLS[RFC4511]、Password Modify[RFC3062])、ベースへの拡大と定義された操作または拡大手術。

   Extensions SHOULD NOT return Response controls unless the server has
   specific knowledge that the client can make use of the control.
   Generally, the client requests the return of a particular response
   control by providing a related request control.

サーバにクライアントがコントロールを利用できるという特定の知識がない場合、拡大SHOULD NOTはコントロールをResponseに返します。 一般に、クライアントは、関連する要求コントロールを提供することによって、特定の応答制御の復帰を要求します。

   An existing operation MAY be extended to return IntermediateResponse
   messages [Protocol, Section 4.13].

既存の操作は、メッセージ[プロトコル、セクション4.13]をIntermediateResponseに返すために広げられるかもしれません。

   Specifications of controls SHALL NOT attach additional semantics to
   the criticality of controls beyond those defined in [Protocol,
   Section 4.1.11].  A specification MAY mandate the criticality take on
   a particular value (e.g., TRUE or FALSE), where appropriate.

コントロールSHALL NOTの仕様は[プロトコル、セクション4.1.11]で定義されたものを超えて追加意味論をコントロールの臨界に付けます。 仕様は、臨界が特定の値(例えば、TRUEかFALSE)を適切であるところに呈するのを強制するかもしれません。

3.1.1.  Extending Bind Operation with Controls

3.1.1. コントロールでひもの操作を広げています。

   Controls attached to the request and response messages of a Bind
   Operation [RFC4511] are not protected by any security layers
   established by that Bind operation.

Bind Operation[RFC4511]の要求と応答メッセージに取り付けられたコントロールはそのBind操作で確立されたどんなセキュリティ層によっても保護されません。

Zeilenga                 Best Current Practice                  [Page 6]

RFC 4521                    LDAP Extensions                    June 2006

最も良い現在のZeilengaの練習[6ページ]RFC4521LDAP拡大2006年6月

   Specifications detailing controls extending the Bind operation SHALL
   detail that the Bind negotiated security layers do not protect the
   information contained in these controls and SHALL detail how the
   information in these controls is protected or why the information
   does not need protection.

Bindがセキュリティ層を交渉したというBind操作SHALLの詳細を広げるコントロールについて詳述する仕様がこれらのコントロールに含まれた情報を保護しません、そして、SHALLはこれらのコントロールにおける情報がどのように保護されるか、そして、または情報がなぜ保護を必要としないかを詳しく述べます。

   It is RECOMMENDED that designers consider alternative mechanisms for
   providing the function.  For example, an extended operation issued
   subsequent to the Bind operation (hence, protected by the security
   layers negotiated by the Bind operation) might be used to provide the
   desired function.

デザイナーが機能を提供するために代替のメカニズムを考えるのは、RECOMMENDEDです。 例えば、Bind操作(したがって、保護されて、Bind操作で交渉されて、セキュリティは層にされる)にその後で発行された拡大手術は、必要な機能を提供するのに使用されるかもしれません。

   Additionally, designers of Bind control extensions MUST also consider
   how the controls' semantics interact with individual steps of a
   multi-step Bind operation.  Note that some steps are optional and
   thus may require special attention in the design.

また、さらに、Bindコントロール拡張子のデザイナーは、コントロールの意味論がどのように多段階Bind操作の独特のステップと対話するかを考えなければなりません。 数ステップが任意であり、その結果、デザインにおける特別な注意を必要とするかもしれないことに注意してください。

3.1.2.  Extending the Start TLS Operation with Controls

3.1.2. コントロールでスタートTLS操作を広げています。

   Controls attached to the request and response messages of a Start TLS
   Operation [RFC4511] are not protected by the security layers
   established by the Start TLS operation.

Start TLS Operation[RFC4511]の要求と応答メッセージに取り付けられたコントロールはStart TLS操作で確立されたセキュリティ層によって保護されません。

   Specifications detailing controls extending the Start TLS operation
   SHALL detail that the Start TLS negotiated security layers do not
   protect the information contained in these controls and SHALL detail
   how the information in these controls is protected or why the
   information does not need protection.

Start TLSがセキュリティ層を交渉したというStart TLS操作SHALLの詳細を広げるコントロールについて詳述する仕様がこれらのコントロールに含まれた情報を保護しません、そして、SHALLはこれらのコントロールにおける情報がどのように保護されるか、そして、または情報がなぜ保護を必要としないかを詳しく述べます。

   It is RECOMMENDED that designers consider alternative mechanisms for
   providing the function.  For example, an extended operation issued
   subsequent to the Start TLS operation (hence, protected by the
   security layers negotiated by the Start TLS operation) might be used
   to provided the desired function.

デザイナーが機能を提供するために代替のメカニズムを考えるのは、RECOMMENDEDです。 例えば、操作(したがって、保護されて、Start TLS操作で交渉されて、セキュリティは層にされる)が使用されているかもしれないStart TLSにその後で発行された拡大手術は必要な機能を提供しました。

3.1.3.  Extending the Search Operation with Controls

3.1.3. コントロールで索敵行動を広げています。

   The Search operation processing has two distinct phases:

検索操作処理には、2つの異なったフェーズがあります:

      -  finding the base object; and

- ベースオブジェクトを見つけます。 そして

      -  searching for objects at or under that base object.

- オブジェクトにおいて、または、そのベースオブジェクトの下でオブジェクトを捜し求めます。

   Specifications of controls extending the Search Operation should
   clearly state in which phase(s) the control's semantics apply.
   Semantics of controls that are not specific to the Search Operation
   SHOULD apply in the finding phase.

どれが(s) コントロールの意味論の位相を合わせるかでOperationが明確に述べるはずである検索を広げるコントロールの仕様は適用されます。 Operation SHOULDが調査結果フェーズで適用する検索に特定でないコントロールの意味論。

Zeilenga                 Best Current Practice                  [Page 7]

RFC 4521                    LDAP Extensions                    June 2006

最も良い現在のZeilengaの練習[7ページ]RFC4521LDAP拡大2006年6月

3.1.4.  Extending the Update Operations with Controls

3.1.4. コントロールでアップデート操作を広げています。

   Update operations have properties of atomicity, consistency,
   isolation, and durability ([ACID]).

アップデート操作には、最小単位、一貫性、分離、および耐久性([ACID])の特性があります。

      -  atomicity: All or none of the DIT changes requested are made.

- 最小単位: 変化が要求したDITのすべてかいずれも作られていません。

      -  consistency: The resulting DIT state must be conform to schema
         and other constraints.

- 一貫性: 結果として起こるDIT状態は図式と他の規制に従うことであるに違いありません。

      -  isolation: Intermediate states are not exposed.

- 分離: 中間的州は暴露されません。

      -  durability: The resulting DIT state is preserved until
         subsequently updated.

- 耐久性: 結果として起こるDIT状態は次にアップデートするまで保持されます。

   When defining a control that requests additional (or other) DIT
   changes be made to the DIT, these additional changes SHOULD NOT be
   treated as part of a separate transaction.  The specification MUST be
   clear as to whether the additional DIT changes are part of the same
   or a separate transaction as the DIT changes expressed in the request
   of the base operation.

追加していて(他)のDIT変更をDIT、これらの付加的な変化SHOULD NOTにするよう要求するコントロールを定義するときには、別々のトランザクションの一部として扱われてください。 仕様はDIT変化がベース操作の要求で言い表したように追加DIT変化が同じくらいか別々のトランザクションの一部であるかどうかに関して明確であるに違いありません。

   When defining a control that requests additional (or other) DIT
   changes be made to the DIT, the specification MUST be clear as to the
   order in which these and the base changes are to be applied to the
   DIT.

追加していて(他)のDIT変更をDITにするよう要求するコントロールを定義するとき、仕様はこれらと塩基の変化がDITに適用されることになっているオーダーに関して明確であるに違いありません。

3.1.5.  Extending the Responseless Operations with Controls

3.1.5. コントロールでResponseless操作を広げています。

   The Abandon and Unbind operations do not include a response message.
   For this reason, specifications for controls designed to be attached
   to Abandon and Unbind requests SHOULD mandate that the control's
   criticality be FALSE.

AbandonとUnbind操作は応答メッセージを含んでいません。 この理由、AbandonとUnbind要求SHOULDに付けられるように設計されたコントロールのための仕様に関しては、コントロールの臨界がFALSEであることを強制してください。

3.2.  Extended Operations

3.2. 拡大手術

   Extended Operations [Protocol, Section 4.12] are the RECOMMENDED
   mechanism for defining new operations.  An extended operation
   consists of an ExtendedRequest message, zero or more
   IntermediateResponse messages, and an ExtendedResponse message.

拡張Operations[プロトコル、セクション4.12]は、新しい操作を定義するためのRECOMMENDEDメカニズムです。 拡大手術はExtendedRequestメッセージかゼロか、より多くのIntermediateResponseメッセージと、ExtendedResponseメッセージから成ります。

3.3.  Intermediate Responses

3.3. 中間的応答

   Extensions SHALL use IntermediateResponse messages instead of
   ExtendedResponse messages to return intermediate results.

拡大SHALLは中間結果を返すExtendedResponseメッセージの代わりにIntermediateResponseメッセージを使用します。

Zeilenga                 Best Current Practice                  [Page 8]

RFC 4521                    LDAP Extensions                    June 2006

最も良い現在のZeilengaの練習[8ページ]RFC4521LDAP拡大2006年6月

3.4.  Unsolicited Notifications

3.4. 求められていない通知

   Unsolicited notifications [Protocol, Section 4.4] offer a capability
   for the server to notify the client of events not associated with the
   operation currently being processed.

求められていない通知[プロトコル、セクション4.4]はサーバが現在処理される操作に関連づけられなかったイベントについてクライアントに通知する能力を提供します。

   Extensions SHOULD be designed such that unsolicited notifications are
   not returned unless the server has specific knowledge that the client
   can make use of the notification.  Generally, the client requests the
   return of a particular unsolicited notification by performing a
   related extended operation.

求められていない通知は設計されたそのようなものですが、拡大SHOULDはそうです。サーバにクライアントが通知を利用できるという特定の知識がない場合、戻りました。 一般に、クライアントは、関連する拡大手術を実行することによって、特定の求められていない通知の復帰を要求します。

   For example, a time hack extension could be designed to return
   unsolicited notifications at regular intervals that were enabled by
   an extended operation (which possibly specified the desired
   interval).

例えば、拡大手術(ことによると必要な間隔を指定した)で可能にされた一定の間隔で、求められていない通知を返すように時間ハッキング延期を設計できました。

4.  Extending the LDAP ASN.1 Definition

4. LDAP ASN.1定義を広げています。

   LDAP allows limited extension [Protocol, Section 4] of the LDAP ASN.1
   definition [Protocol, Appendix B] to be made.

LDAPはLDAP ASN.1定義[プロトコル、Appendix B]の限られた拡大[プロトコル、セクション4]をさせます。

4.1.  Result Codes

4.1. 結果コード

   Extensions that specify new operations or enhance existing operations
   often need to define new result codes.  The extension SHOULD be
   designed such that a client has a reasonably clear indication of the
   nature of the successful or non-successful result.

新しい操作を指定するか、または既存の操作を機能アップする拡張子は、しばしば新しい結果コードを定義する必要があります。 拡大SHOULD、クライアントにはうまくいくか非好成績の本質の合理的に明確なしるしがあるように、設計されてください。

   Extensions SHOULD use existing result codes to indicate conditions
   that are consistent with the intended meaning [RFC4511][X.511] of
   these codes.  Extensions MAY introduce new result codes [RFC4520]
   where no existing result code provides an adequate indication of the
   nature of the result.

拡大SHOULDは、これらのコードの意図している意味[RFC4511][X.511]と一致した状態を示すのに既存の結果コードを使用します。 拡大はどんな既存の結果コードも結果の本質の適切なしるしを供給しないところで新しい結果コード[RFC4520]を紹介するかもしれません。

   Extensions SHALL NOT disallow or otherwise restrict the return of
   general service result codes, especially those reporting a protocol,
   service, or security problem, or indicating that the server is unable
   or unwilling to complete the operation.

拡大SHALL NOTは操作を完了するために不本意な状態で一般的なサービス結果コード、特にプロトコル、サービス、または警備上の問題を報告するか、またはサーバがそうであることを示すものの復帰を禁じるか、またはそうでなければ、制限します。

4.2.  LDAP Message Types

4.2. LDAPメッセージタイプ

   While extensions can specify new types of LDAP messages by extending
   the protocolOp CHOICE of the LDAPMessage SEQUENCE, this is generally
   unnecessary and inappropriate.  Existing operation extension
   mechanisms (e.g., extended operations, unsolicited notifications, and
   intermediate responses) SHOULD be used instead.  However, there may
   be cases where an extension does not fit well into these mechanisms.

拡大はLDAPMessage SEQUENCEのprotocolOp CHOICEを広げることによって、新しいタイプに関するLDAPメッセージを指定できますが、これは、一般に、不要であって、不適当です。 既存の操作拡張機能(例えば、拡大手術、求められていない通知、および中間的応答)SHOULD、代わりに使用されてください。 しかしながら、ケースが拡大がこれらのメカニズムによく収まらないところにあるかもしれません。

Zeilenga                 Best Current Practice                  [Page 9]

RFC 4521                    LDAP Extensions                    June 2006

最も良い現在のZeilengaの練習[9ページ]RFC4521LDAP拡大2006年6月

   In such cases, a new extension mechanism SHOULD be defined that can
   be used by multiple extensions that have similar needs.

そのような場合新しい拡張機能SHOULD、定義されて、同様の必要性を持っている複数の拡大でそれを使用できるということになってください。

4.3.  Authentication Methods

4.3. 認証方法

   The Bind operation currently supports two authentication methods,
   simple and SASL.  SASL [RFC4422] is an extensible authentication
   framework used by multiple application-level protocols (e.g., BEEP,
   IMAP, SMTP).  It is RECOMMENDED that new authentication processes be
   defined as SASL mechanisms.  New LDAP authentication methods MAY be
   added to support new authentication frameworks.

Bind操作は現在、簡単な状態で2つの認証方法をサポートします。そして、SASL。 SASL[RFC4422]は複数のアプリケーションレベルプロトコル(例えば、BEEP、IMAP、SMTP)によって使用される広げることができる認証フレームワークです。 新しい認証過程がSASLメカニズムと定義されるのは、RECOMMENDEDです。新しいLDAP認証方法は、新しい認証がフレームワークであるとサポートするために加えられるかもしれません。

   The Bind operation's primary function is to establish the LDAP
   association [RFC4513].  No other operation SHALL be defined (or
   extended) to establish the LDAP association.  However, other
   operations MAY be defined to establish other security associations
   (e.g., IPsec).

Bind操作のプライマリ機能はLDAP協会[RFC4513]を設立することです。 いいえ、他の操作SHALL。LDAP協会を証明するために定義されるのと(広げられる。)になってください。 しかしながら、他の操作は、他のセキュリティ協会(例えば、IPsec)を証明するために定義されるかもしれません。

4.4.  General ASN.1 Extensibility

4.4. ASN.1司令官伸展性

   Section 4 of [RFC4511] states the following:

[RFC4511]のセクション4は以下を述べます:

      In order to support future extensions to this protocol,
      extensibility is implied where it is allowed per ASN.1 (i.e.,
      sequence, set, choice, and enumerated types are extensible).  In
      addition, ellipses (...)  have been supplied in ASN.1 types that
      are explicitly extensible as discussed in [RFC4520].  Because of
      the implied extensibility, clients and servers MUST (unless
      otherwise specified) ignore trailing SEQUENCE components whose
      tags they do not recognize.

このプロトコルに今後の拡大をサポートするために、伸展性はそれがASN.1単位で許容されている(すなわち、系列、セット、選択、および列挙型は広げることができます)ところで含意されます。 さらに、[RFC4520]で議論するように明らかに広げることができるASN.1タイプで楕円(…)を供給しました。 暗示している伸展性のために、クライアントとサーバは彼らがタグを認識しない引きずっているSEQUENCEの部品を無視しなければなりません(別の方法で指定されない場合)。

   Designers SHOULD avoid introducing extensions that rely on
   unsuspecting implementations to ignore trailing components of
   SEQUENCE whose tags they do not recognize.

デザイナーSHOULDは、彼らがタグを認識しないSEQUENCEの部品を引きずりながら、無視する疑わない実装を当てにする拡張子を紹介するのを避けます。

5.  Schema Extensions

5. 図式拡大

   Extensions defining LDAP schema elements SHALL provide schema
   definitions conforming with syntaxes defined in [Models, Section
   4.1].  While provided definitions MAY be reformatted (line wrapped)
   for readability, this SHALL be noted in the specification.

LDAP図式要素SHALLを定義する拡大が[セクション4.1のモデル]で定義された構文に従う図式定義を提供します。 定義が読み易さ、このSHALLのために再フォーマットされるかもしれないなら(包装された系列)、有名なコネが仕様であったならゆったり過ごします。

   For definitions that allow a NAME field, new schema elements SHOULD
   provide one and only one name.  The name SHOULD be short.

NAME分野を許容する定義のために、新しい図式要素SHOULDは唯一無二の1つの名前を提供します。 存在という名前SHOULDはショートします。

   Each schema definition allows a DESC field.  The DESC field, if
   provided, SHOULD contain a short descriptive phrase.  The DESC field
   MUST be regarded as informational.  That is, the specification MUST

それぞれの図式定義はDESC分野を許容します。 DESC分野であり、提供するなら、SHOULDは短い描写的である句を含んでいます。 DESC分野を情報と見なさなければなりません。 すなわち、仕様はそうしなければなりません。

Zeilenga                 Best Current Practice                 [Page 10]

RFC 4521                    LDAP Extensions                    June 2006

最も良い現在のZeilengaの練習[10ページ]RFC4521LDAP拡大2006年6月

   be written such that its interpretation is the same with and without
   the provided DESC fields.

解釈が提供されたDESC分野のあるなしにかかわらず同じであるように、書かれてください。

   The extension SHALL NOT mandate that implementations provide the same
   DESC field in the schema they publish.  Implementors MAY replace or
   remove the DESC field.

拡大SHALL NOTは、実装が同じDESC野原をそれらが発表する図式に供給するのを強制します。 作成者は、DESC野原を取り替えるか、または取り除くかもしれません。

   Published schema elements SHALL NOT be redefined.  Replacement schema
   elements (new OIDs, new NAMEs) SHOULD be defined as needed.

図式要素SHALL NOTを発行する、再定義されてください。 交換図式要素(新しいOIDs、新しいNAMEs)SHOULD、必要に応じて定義されてください。

   Schema designers SHOULD reuse existing schema elements, where
   appropriate.  However, any reuse MUST not alter the semantics of the
   element.

図式デザイナーSHOULDは適切であるところで既存の図式要素を再利用します。 しかしながら、どんな再利用も要素の意味論を変更してはいけません。

5.1.  LDAP Syntaxes

5.1. LDAP構文

   Each LDAP syntax [RFC4517] is defined in terms of ASN.1 [X.680].
   Each extension detailing an LDAP syntax MUST specify the ASN.1 data
   definition associated with the syntax.  A distinct LDAP syntax SHOULD
   be created for each distinct ASN.1 data definition (including
   constraints).

それぞれのLDAP構文[RFC4517]はASN.1[X.680]に関して定義されます。 LDAP構文を詳しく述べる各拡大は構文に関連しているASN.1データ定義を指定しなければなりません。 異なったLDAP構文SHOULD、それぞれの異なったASN.1データ定義には、作成されてください(規制を含んでいて)。

   Each LDAP syntax SHOULD have a string encoding defined for it.  It is
   RECOMMENDED that this string encoding be restricted to UTF-8
   [RFC3629] encoded Unicode [Unicode] characters.  Use of Generic
   String Encoding Rules (GSER) [RFC3641][RFC3642] or other generic
   string encoding rules to provide string encodings for complex ASN.1
   data definitions is RECOMMENDED.  Otherwise, it is RECOMMENDED that
   the string encoding be described using a formal language (e.g., ABNF
   [RFC4234]).  Formal languages SHOULD be used in specifications in
   accordance with IESG guidelines [FORMAL].

それぞれのLDAP構文SHOULDには、コード化がそれのために定義したストリングがあります。 このストリングコード化がUTF-8[RFC3629]のコード化されたユニコード[ユニコード]キャラクタに制限されるのは、RECOMMENDEDです。 Generic String Encoding Rules(GSER)[RFC3641][RFC3642]か複雑なASN.1データ定義にストリングencodingsを提供するために規則をコード化する他のジェネリックストリングの使用はRECOMMENDEDです。 さもなければ、ストリングコード化が形式言語(例えば、ABNF[RFC4234])を使用することで説明されるのは、RECOMMENDEDです。 形式言語SHOULD、IESGガイドライン[FORMAL]に従って、仕様で使用されてください。

   If no string encoding is defined, the extension SHALL specify how the
   transfer encoding is to be indicated.  Generally, the extension
   SHOULD mandate use of binary or other transfer encoding option.

ストリングコード化でないのが定義されるなら、拡大SHALLは示される転送コード化がことである方法を指定します。 一般に、拡大SHOULDはオプションをコード化する2進の、または、他の転送の使用を強制します。

5.2.  Matching Rules

5.2. 合っている規則

   Three basic kinds of matching rules (e.g., EQUALITY, ORDERING, and
   SUBSTRING) may be associated with an attribute type.  In addition,
   LDAP provides an extensible matching rule mechanism.

基本的な3種類の合っている規則(例えば、EQUALITY、ORDERING、およびSUBSTRING)は属性タイプに関連しているかもしれません。 さらに、LDAPは広げることができる合っている規則メカニズムを提供します。

   The matching rule specification SHOULD detail which kind of matching
   rule it is and SHOULD describe which kinds of values it can be used
   with.

合っている規則仕様SHOULDは、それがどのちょっと合っている規則であるかを詳しく述べます、そして、SHOULDはどの種類の値と共にそれを使用できるかを説明します。

   In addition to requirements stated in the LDAP technical
   specification, equality matching rules SHOULD be commutative.

要件に加えて、LDAP技術仕様書、規則に合っている平等でSHOULDが交換可能であると述べました。

Zeilenga                 Best Current Practice                 [Page 11]

RFC 4521                    LDAP Extensions                    June 2006

最も良い現在のZeilengaの練習[11ページ]RFC4521LDAP拡大2006年6月

5.3.  Attribute Types

5.3. 属性タイプ

   Designers SHOULD carefully consider how the structure of values is to
   be restricted.  Designers SHOULD consider that servers will only
   enforce constraints of the attribute's syntax.  That is, an attribute
   intended to hold URIs, but that has directoryString syntax, is not
   restricted to values that are URIs.

デザイナーSHOULDは慎重に制限される値の構造がことである方法を考えます。 デザイナーSHOULDは、サーバが属性の構文の規制を実施するだけであると考えます。 すなわち、directoryString構文を持っているURIを保持することを意図する属性はURIである値に制限されません。

   Designers SHOULD carefully consider which matching rules, if any, are
   appropriate for the attribute type.  Matching rules specified for an
   attribute type MUST be compatible with the attribute type's syntax.

デザイナーSHOULDは、属性タイプにとって、もしあればどの合っている規則が適切であるかを慎重に考えます。 属性タイプに指定された合っている規則は属性タイプの構文と互換性があるに違いありません。

   Extensions specifying operational attributes MUST detail how servers
   are to maintain and/or utilize values of each operational attribute.

操作上の属性を指定する拡大はそれぞれの操作上の属性の値を維持する、そして/または、利用するサーバがことである方法を詳しく述べなければなりません。

5.4.  Object Classes

5.4. オブジェクトのクラス

   Designers SHOULD carefully consider whether each attribute of an
   object class is required ("MUST") or allowed ("MAY").

デザイナーSHOULDは、オブジェクトのクラスの各属性が必要である(“MUST")、または許容されているか(「5月」)を慎重に考えます。

   Extensions specifying object classes that allow (or require)
   operational attributes MUST specify how servers are to maintain
   and/or utilize entries belonging to these object classes.

それが許容するオブジェクトのクラスを指定する拡大、(必要である、)、操作上の属性はこれらのオブジェクトのクラスに属すエントリーを維持する、そして/または、利用するサーバがことである方法を指定しなければなりません。

6.  Other Extension Mechanisms

6. 他の拡張機能

6.1.  Attribute Description Options

6.1. 属性記述オプション

   Each option is identified by a string of letters, numbers, and
   hyphens.  This string SHOULD be short.

各オプションは一連の手紙、数、およびハイフンによって特定されます。 これはSHOULDを結びます。短くいてください。

6.2.  Authorization Identities

6.2. 承認のアイデンティティ

   Extensions interacting with authorization identities SHALL support
   the LDAP authzId format [RFC4513].  The authzId format is extensible.

承認アイデンティティSHALLサポートでLDAP authzIdに相互作用させる拡大が[RFC4513]をフォーマットします。 authzId形式は広げることができます。

6.3.  LDAP URL Extensions

6.3. LDAP URL拡張子

   LDAP URL extensions are identified by a short string, a descriptor.
   Like other descriptors, the string SHOULD be short.

LDAP URL拡張子は脆いストリング、記述子によって特定されます。 他の記述子、ストリングSHOULDが好きである、短くいてください。

7.  Security Considerations

7. セキュリティ問題

   LDAP does not place undue restrictions on the kinds of extensions
   that can be implemented.  While this document attempts to outline
   some specific issues that designers need to consider, it is not (and

LDAPは実装することができる拡大の種類に関して過度の制限を課しません。 そしてこのドキュメントが、デザイナーが考える必要があるいくつかの特定の問題について概説するのを試みますが、それが試みるというわけではない、(。

Zeilenga                 Best Current Practice                 [Page 12]

RFC 4521                    LDAP Extensions                    June 2006

最も良い現在のZeilengaの練習[12ページ]RFC4521LDAP拡大2006年6月

   cannot be) all encompassing.  Designers MUST do their own evaluations
   of the security considerations applicable to their extensions.

)、すべて取り囲むことができます。 デザイナーはそれら自身の彼らの拡大に適切なセキュリティ問題の評価をしなければなりません。

   Designers MUST NOT assume that the LDAP "core" technical
   specification [RFC4510] adequately addresses the specific concerns
   surrounding their extensions or assume that their extensions have no
   specific concerns.

デザイナーは、LDAP「コア」技術仕様書[RFC4510]が適切に彼らの拡大を囲む特定の関心を扱うと仮定してはいけませんし、また彼らの拡大にはどんな特定の関心もないと仮定してはいけません。

   Extension specifications, however, SHOULD note whether security
   considerations specific to the feature they are extending, as well as
   general LDAP security considerations, apply to the extension.

ファイル拡張仕様書、しかしながら、SHOULDはそれらが一般的なLDAPセキュリティ問題と同様に広げている特徴に特定のセキュリティ問題が拡大に適用されるかどうかに注意します。

8.  Acknowledgements

8. 承認

   The author thanks the IETF LDAP community for their thoughtful
   comments.

作者は彼らの考え深いコメントについてIETF LDAP共同体に感謝します。

   This work builds upon "LDAP Extension Style Guide" [GUIDE] by Bruce
   Greenblatt.

この仕事は「LDAP拡大スタイルガイド」というブルース・グリーンブラットによる[ガイド]を当てにします。

9.  References

9. 参照

9.1.  Normative References

9.1. 引用規格

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

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。

   [RFC2849]  Good, G., "The LDAP Data Interchange Format (LDIF) -
              Technical Specification", RFC 2849, June 2000.

[RFC2849] いいぞ、G.、「LDAPデータは形式(LDIF)を交換します--技術的な仕様」、RFC2849、6月2000日

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

[RFC3629]Yergeau、F.、「UTF-8、ISO10646の変換形式」STD63、RFC3629、11月2003日

   [RFC3641]  Legg, S., "Generic String Encoding Rules (GSER) for ASN.1
              Types", RFC 3641, October 2003.

[RFC3641]Legg、2003年10月のS.、「ASN.1タイプのためのジェネリックストリング符号化規則(GSER)」RFC3641。

   [RFC3642]  Legg, S., "Common Elements of Generic String Encoding
              Rules (GSER) Encodings", RFC 3642, October 2003.

[RFC3642]Legg、S.、「ジェネリックストリング符号化規則(GSER)Encodingsの一般的なElements」、RFC3642、2003年10月。

   [RFC4512]  Zeilenga, K., "Lightweight Directory Access Protocol
              (LDAP): Directory Information Models", RFC 4512, June
              2006.

[RFC4512] Zeilenga、K.、「軽量のディレクトリアクセスは以下について議定書の中で述べ(LDAP)」。 「ディレクトリ情報モデル」、RFC4512、2006年6月。

Zeilenga                 Best Current Practice                 [Page 13]

RFC 4521                    LDAP Extensions                    June 2006

最も良い現在のZeilengaの練習[13ページ]RFC4521LDAP拡大2006年6月

   [RFC3866]  Zeilenga, K., Ed., "Language Tags and Ranges in the
              Lightweight Directory Access Protocol (LDAP)", RFC 3866,
              July 2004.

[RFC3866] Zeilenga、K.、エド、「軽量のディレクトリアクセスにおける言語タグと範囲は(LDAP)について議定書の中で述べる」RFC3866、7月2004日

   [RFC4234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 4234, October 2005.

[RFC4234] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。

   [RFC4510]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
              (LDAP): Technical Specification Road Map", RFC 4510, June
              2006.

[RFC4510] Zeilenga、K.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「仕様書ロードマップ」、RFC4510、2006年6月。

   [RFC4511]  Sermersheim, J., Ed., "Lightweight Directory Access
              Protocol (LDAP): The Protocol", RFC 4511, June 2006.

[RFC4511] Sermersheim、J.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「プロトコル」、RFC4511、2006年6月。

   [RFC4512]  Zeilenga, K., "Lightweight Directory Access Protocol
              (LDAP): Directory Information Models", RFC 4512, June
              2006.

[RFC4512] Zeilenga、K.、「軽量のディレクトリアクセスは以下について議定書の中で述べ(LDAP)」。 「ディレクトリ情報モデル」、RFC4512、2006年6月。

   [RFC4513]  Harrison, R., Ed., "Lightweight Directory Access Protocol
              (LDAP): Authentication Methods and Security Mechanisms",
              RFC 4513, June 2006.

[RFC4513] ハリソン、R.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「認証方法とセキュリティー対策」、RFC4513、6月2006日

   [RFC4515]  Smith, M., Ed. and T. Howes, "Lightweight Directory Access
              Protocol (LDAP): String Representation of Search Filters",
              RFC 4515, June 2006.

[RFC4515] エドスミス、M.、T.ハウズ、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「検索フィルタのストリング表現」、RFC4515、2006年6月。

   [RFC4516]  Smith, M., Ed. and T. Howes, "Lightweight Directory Access
              Protocol (LDAP): Uniform Resource Locator", RFC 4516, June
              2006.

[RFC4516] エドスミス、M.、T.ハウズ、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「Uniform Resource Locator」、RFC4516、2006年6月。

   [RFC4517]  Legg, S., Ed., "Lightweight Directory Access Protocol
              (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.

[RFC4517] Legg、S.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「構文とマッチングは統治する」RFC4517、2006年6月。

   [RFC4518]  Zeilenga, K., "Lightweight Directory Access Protocol
              (LDAP): String Representation of Distinguished Names", RFC
              4518, June 2006.

[RFC4518] Zeilenga、K.、「軽量のディレクトリアクセスは以下について議定書の中で述べ(LDAP)」。 「分類名のストリング表現」、RFC4518、2006年6月。

   [RFC4520]  Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
              Considerations for the Lightweight Directory Access
              Protocol (LDAP)", BCP 64, RFC 4520, June 2006.

[RFC4520]Zeilenga、K.、「インターネットはライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)のために数の権威(IANA)に問題を割り当てました」、BCP64、RFC4520、2006年6月。

   [RFC4422]  Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
              Authentication and Security Layer (SASL)", RFC 4422, June
              2006.

エド[RFC4422]メリニコフ、A.、K.Zeilenga、エド、「簡易認証とセキュリティは(SASL)を層にする」RFC4422、6月2006日

Zeilenga                 Best Current Practice                 [Page 14]

RFC 4521                    LDAP Extensions                    June 2006

最も良い現在のZeilengaの練習[14ページ]RFC4521LDAP拡大2006年6月

   [Unicode]  The Unicode Consortium, "The Unicode Standard, Version
              3.2.0" is defined by "The Unicode Standard, Version 3.0"
              (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
              as amended by the "Unicode Standard Annex #27: Unicode
              3.1" (http://www.unicode.org/reports/tr27/) and by the
              "Unicode Standard Annex #28: Unicode 3.2"
              (http://www.unicode.org/reports/tr28/).

[ユニコード] ユニコードConsortium、「ユニコード規格、バージョン、3.2、0インチ、定義される、「ユニコード規格、修正されるバージョン3インチ(読書、MA、アディソン-ウエスリー、2000ISBN0-201-61633-5)、「ユニコード規格別館#27:」 「ユニコード規格別館#28:」 ユニコード3.2インチ( http://www.unicode.org/reports/tr28/ )。

   [FORMAL]   IESG, "Guidelines for the use of formal languages in IETF
              specifications",
              <http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-
              specs.txt>, 2001.

[FORMAL]IESG、「IETF仕様に基づく形式言語の使用のためのガイドライン」、<中の疑似なコードhttp://www.ietf.org/IESG/STATEMENTS/specs.txt>、2001。

   [X.511]    International Telecommunication Union - Telecommunication
              Standardization Sector, "The Directory: Abstract Service
              Definition", X.511(1993) (also ISO/IEC 9594-3:1993).

[X.511]国際電気通信連合--電気通信標準化セクター、「ディレクトリ:」 「抽象的なサービス定義」、X.511(1993)(ISO/IEC9594-3も: 1993)。

   [X.680]    International Telecommunication Union - Telecommunication
              Standardization Sector, "Abstract Syntax Notation One
              (ASN.1) - Specification of Basic Notation", X.680(2002)
              (also ISO/IEC 8824-1:2002).

[X.680]国際電気通信連合--電気通信標準化セクター、「構文記法1(ASN.1)を抜き取ってください--基本的な記法の仕様」、X.680(2002)(ISO/IEC8824-1も: 2002)。

   [X.690]    International Telecommunication Union - Telecommunication
              Standardization Sector, "Specification of ASN.1 encoding
              rules: Basic Encoding Rules (BER), Canonical Encoding
              Rules (CER), and Distinguished Encoding Rules (DER)",
              X.690(2002) (also ISO/IEC 8825-1:2002).

[X.690]国際電気通信連合--電気通信Standardization Sector、「ASN.1コード化の仕様は統治します」。 「規則(BER)、正準な符号化規則(CER)、および顕著な符号化規則(DER)をコード化する基礎」、X.690(2002)(ISO/IEC8825-1も: 2002)。

9.2.  Informative References

9.2. 有益な参照

   [ACID]     Section 4 of ISO/IEC 10026-1:1992.

1992年のISO/IEC10026-1:[酸性]のセクション4。

   [GUIDE]    Greenblatt, B., "LDAP Extension Style Guide", Work in
              Progress.

[誘導します] グリーンブラット、B.、「LDAP拡大スタイルガイド」が進行中で働いています。

   [RFC3062]  Zeilenga, K., "LDAP Password Modify Extended Operation",
              RFC 3062, February 2001.

[RFC3062] Zeilenga、K.、「LDAPパスワードは拡大手術を変更する」RFC3062、2001年2月。

   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.

[RFC4346] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。

Author's Address

作者のアドレス

   Kurt D. Zeilenga
   OpenLDAP Foundation

カートD.Zeilenga OpenLDAP財団

   EMail: Kurt@OpenLDAP.org

メール: Kurt@OpenLDAP.org

Zeilenga                 Best Current Practice                 [Page 15]

RFC 4521                    LDAP Extensions                    June 2006

最も良い現在のZeilengaの練習[15ページ]RFC4521LDAP拡大2006年6月

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(2006)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。

Acknowledgement

承認

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Zeilenga                 Best Current Practice                 [Page 16]

Zeilengaの最も良い現在の習慣[16ページ]