Network Working Group K. Zeilenga
Request for Comments: 4521 OpenLDAP Foundation
BCP: 118 June 2006
Category: Best Current Practice
Considerations for
Lightweight Directory Access Protocol (LDAP) Extensions
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).
著作権（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（Lightweight Directory Access Protocol）は、拡張可能です。これは、新たな動作を追加すること、既存の操作を拡張し、ユーザとシステムのスキーマを拡張するためのメカニズムを提供します。このドキュメントでは、LDAP拡張の設計者のための考慮事項について説明します。
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
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は、簡易認証セキュリティー層（SASL）認証方式[RFC4511] [RFC4513]をサポートしています。 SASL [RFC4422]は拡張可能です。 LDAPは、追加の認証方法[RFC4511]をサポートするように拡張することができます。
LDAP supports establishment of Transport Layer Security (TLS) [RFC4511][RFC4513]. TLS [RFC4346] is extensible.
LDAPは、トランスポート層セキュリティ（TLS）[RFC4511] [RFC4513]の設立をサポートしています。 TLS [RFC4346]は拡張可能です。
LDAP has an extensible Uniform Resource Locator (URL) format [RFC4516].
LDAPは、拡張可能なユニフォームリソースロケータ（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プロトコルの抽象構文記法に特定の拡張子をすることができます - ワン（ASN.1）[X.680]の定義がなされます。これは、例えば、プロトコルのASN.1定義の拡張を介して追加する拡張をサポートするために必要な新しい結果コードをプロトコルの拡張機能の広い範囲を容易にします。
This document describes practices that engineers should consider when designing extensions to LDAP.
このドキュメントでは、LDAPへの拡張を設計する際にエンジニアが検討すべきプラクティスについて説明します。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14 [RFC2119]に記載されているように解釈されます。 BCP 14、RFC 2119で使用されるように本書では、「仕様」は、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.
用語「リクエスト・コントロールは、」サーバーに送信されたクライアントが生成したメッセージに添付されたコントロールを指します。用語「応答コントロールは、」クライアントに送信され、サーバが生成したメッセージに添付コントロールを指します。
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は、ディレクトリ情報ツリーの略です。 DSAは、ディレクトリシステムエージェント、サーバーの略です。 DSEは、DSA固有のエントリを表します。 DUAはディレクトリユーザエージェント、クライアントの略です。 DNは識別名を表します。
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]「本当にオプション」でなければなりません。
Designers SHOULD consider how extensions they engineer interact with other extensions.
設計者は、彼らが他の拡張機能との対話エンジニアリングどのように機能拡張を検討してください。
Designers SHOULD consider the extensibility of extensions they specify. Extensions to LDAP SHOULD themselves be extensible.
設計者は、彼らが指定した拡張子の拡張性を考慮すべきです。 LDAPへの拡張は、それ自体が拡張可能であるべきです。
Except where it is stated otherwise, extensibility is implied.
それは、特に明記されている場合を除き、拡張性が暗示されます。
Extensions SHOULD provide adequate discovery mechanisms.
拡張機能は、適切な検出メカニズムを提供する必要があります。
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及び/又は他のDSE群を照会することを含みます。 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属性は、他の機能を通知するように定義することができます。
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は、文字の完全なUnicode [UNICODE]レパートリーをサポートするように設計されています。拡張機能は、Unicode（例えば、基本多言語面、ISO 8859-1、ASCII、印刷可能な文字列）のサブセットにアプリケーションを制限し、不必要に避けるべきです。
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言語タグオプション[RFC3866]言語情報とテキスト（およびその他）の値をタグ付けするためのメカニズムを提供します。属性タイプを定義する拡張機能は、これらの属性を持つ言語タグの使用を許可する必要があります。
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の多数の要素は[X.680] ASN.1を使用して記載されており、特定のサブセットの基本符号化規則の[プロトコル、セクション5.2]（BER）[X.690]を使用して符号化されます。 LDAP「コア」技術仕様[RFC4510]を実施する際に使用されるパーサー/発電機の再利用を可能にするために、それは（例えば、拡張特定controlValue、requestValue、responseValueフィールドの内容）ASN.1によって記述とはBERを使用して符号化さその拡張要素が推奨されています[プロトコル、セクション5.2]の制約を受けること。
Formal languages SHOULD be used in specifications in accordance with IESG guidelines [FORMAL].
正式言語は[FORMAL] IESGガイドラインに従って仕様で使用されるべきです。
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].
例えばDN文字列は[RFC4518]で定義された構文に準拠すべきです。例LDAPフィルタ文字列は、[RFC4515]で定義された構文に準拠している必要があります。例LDAP URLは、[RFC4516]で定義された構文に準拠している必要があります。エントリはLDIF [RFC2849]を使用して表現されるべきです。
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].
設計者は、BCP 64、RFC 4520 [RFC4520]に従って、そのLDAP拡張のプロトコル値を登録SHALL。新しい拡張可能なプロトコル要素を作成仕様は、既存のレジストリを拡張またはBCP 64、RFC 4520 [RFC4520]とBCP 26、RFC 2434 [RFC2434]に従って、これらの要素の値のための新しいレジストリを確立しなければなりません。
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.
拡張機能は、既存事業を補完する拡張を定義する際にコントロールを使用すべきです。定義する拡張機能は、既存の操作を補完していない場合は、設計者は、代わりに拡張操作を定義する検討すべきです。
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.
カウンタ（および不自然）の例としては、探しサービスオペレーション（このDNによって指定されたエントリを保持することができるサービスにDNのLDAP URLのセットを返す操作）は、検索操作または新規のどちらかとして設計することができます操作。検索操作を補完していない機能として（例えば、操作はディレクトリ情報ツリーで開催されたエントリを検索することが不自然ではない）、それはおそらく、より適切な拡張操作機構を使用して、新しい操作を定義することです。
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]は既存の操作を拡張するための推奨メカニズムです。既存の動作（例えば、検索、修正）[RFC4511]で定義されたベース動作、拡張演算することができる（例えば、スタートTLS [RFC4511]、パスワード変更[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.
サーバは、クライアントがコントロールを使用することができることを具体的な知識を持っていない限り、拡張機能は、応答コントロールを返すべきではありません。一般的に、クライアントは、関連する要求制御を提供することにより、特定の応答制御の返還を要求します。
An existing operation MAY be extended to return IntermediateResponse messages [Protocol, Section 4.13].
既存の操作はIntermediateResponseメッセージ[プロトコル、4.13]を返すように拡張することができます。
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.
コントロールの仕様は、[プロトコル、セクション4.1.11]で定義されたものを超えコントロールの重要性に追加のセマンティクスを添付しないものとします。仕様は、適切な場合、（例えば、TRUEまたはFALSE）特定の値をとる臨界を強制するかもしれません。
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.
バインド操作の要求メッセージと応答メッセージに取り付けられたコントロール[RFC4511]は、そのバインド操作によって確立された任意のセキュリティ層によって保護されていません。
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.
バインド操作を拡張するコントロールを詳述仕様は、バインドはセキュリティ層を交渉していることの詳細は、これらのコントロールの情報が保護されているか、なぜ情報が保護を必要としませんどのようにこれらのコントロールに含まれている情報および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.
設計者が機能を提供するための代替メカニズムを検討することが推奨されます。例えば、拡張された動作は、所望の機能を提供するために使用されるかもしれない（したがって、バインド操作によってネゴシエートセキュリティ層によって保護された）バインド操作の後に発行されます。
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.
また、バインドコントロールの拡張の設計者はまた、コントロールのセマンティクスは、多段階のバインド操作の個々のステップと対話する方法を検討しなければなりません。いくつかのステップはオプションであり、したがって、設計に特別な注意を必要とするかもしれないことに注意してください。
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.
スタートTLS操作の要求メッセージと応答メッセージに添付コントロール[RFC4511]はスタート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.
スタートTLS操作を拡張するコントロールを詳述仕様がスタートTLSは、セキュリティ層を交渉していることの詳細は、これらのコントロールの情報が保護されているか、なぜ情報が保護を必要としませんどのようにこれらのコントロールに含まれている情報および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.
設計者が機能を提供するための代替メカニズムを検討することが推奨されます。例えば、拡張された動作は、所望の機能を提供するために使用されるかもしれない（したがって、スタートTLS操作によってネゴシエートセキュリティ層によって保護された）スタートTLS操作に続いて発行されました。
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.
検索操作を拡張するコントロールの仕様は明らかにコントロールのセマンティクスが適用される相（複数可）に明記してください。検索操作に固有のものではありませんコントロールのセマンティクスは、発見段階で適用されるべきです。
Update operations have properties of atomicity, consistency, isolation, and durability ([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に行うことが要求する制御を定義する場合、これらの追加の変更が別のトランザクションの一部として扱われるべきではありません。仕様は、追加の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に適用される順序についての明確でなければなりません。
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.
放棄し、アンバインド操作は、応答メッセージが含まれていません。このため、要求を放棄し、バインドを解除するために取り付けられるように設計されたコントロールの仕様は、コントロールの重要性がFALSEであること義務付けるべきです。
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.
拡張操作[プロトコル、4.12]は、新しい操作を定義するための推奨メカニズムです。拡張操作は、のExtendedRequestメッセージ、ゼロ以上IntermediateResponseメッセージ、およびExtendedResponseメッセージから成ります。
Extensions SHALL use IntermediateResponse messages instead of ExtendedResponse messages to return intermediate results.
拡張機能は、中間結果を返すために、代わりにExtendedResponseメッセージのメッセージをIntermediateResponse使用しなければなりません。
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.
拡張機能は、サーバーは、クライアントが通知を利用することができることを具体的な知識を持っていない限り、未承諾の通知が返されないように設計しなければなりません。一般的に、クライアントは、関連する拡張操作を行うことで、特定の迷惑通知のリターンを要求します。
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).
例えば、時間ハック拡張は、（おそらく、所望の間隔を指定された）拡張操作によって有効にされた一定の間隔で任意通知を返すように設計することができます。
LDAP allows limited extension [Protocol, Section 4] of the LDAP ASN.1 definition [Protocol, Appendix B] to be made.
LDAPは、限られた延長[プロトコル、第4章]のLDAP ASN.1定義の[プロトコル、付録B]を製造することを可能にします。
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.
新しい操作を指定するか、既存事業を強化する拡張機能は、多くの場合、新しい結果コードを定義する必要があります。拡張機能は、クライアントが成功または非成功した結果の性質を合理的に明確な指標を有するように設計する必要があります。
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.
拡張機能は、これらのコードの意図する意味[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.
拡張機能は許可しないか、そうでない場合は特に、プロトコル、サービス、またはセキュリティ上の問題を報告する、またはサーバーが操作を完了することができないか、不本意であることを示す、一般的なサービスの結果コードの戻りを制限ないものとします。
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メッセージの新しいタイプを指定することができますが、これは一般的に不要と不適切です。既存の動作拡張メカニズム（例えば、拡張操作、未承諾の通知、及び中間応答）が代わりに使用されるべきです。しかし、拡張子がこれらのメカニズムの中にうまく適合しない場合があります。
In such cases, a new extension mechanism SHOULD be defined that can be used by multiple extensions that have similar needs.
このような場合には、新しい拡張機構は、同様のニーズを持つ複数の拡張機能で使用できるように定義する必要があります。
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.
バインド操作は、現在、2つの認証方式、シンプルとSASLをサポートしています。 SASL [RFC4422]は、複数のアプリケーションレベルのプロトコル（例えば、BEEP、IMAP、SMTP）で使用される拡張可能認証フレームワークです。新しい認証プロセスはSASLメカニズムとして定義することが推奨されます。新しい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).
バインド操作の主な機能は、LDAP協会[RFC4513]を確立することです。他の動作は、LDAPアソシエーションを確立するために定義されていない（または拡張）とします。しかし、その他の動作は、他のセキュリティアソシエーション（例えば、IPsec）を確立するように定義することができます。
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.
デザイナーは、タグ、彼らが認識しないSEQUENCEの末尾の要素を無視するように、疑うことを知らないの実装に依存している拡張を導入することは避けてください。
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スキーマ要素を定義する拡張機能は[モデル、セクション4.1]で定義された構文に準拠スキーマ定義を提供しなければなりません。提供された定義は、読みやすくするために（ラップライン）を再フォーマットすることができるが、これは仕様書に明記するものとします。
For definitions that allow a NAME field, new schema elements SHOULD provide one and only one name. The name SHOULD be short.
NAMEフィールドを許可する定義については、新しいスキーマ要素は、唯一の名前を提供する必要があります。名前は短くしてください。
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 be written such that its interpretation is the same with and without the provided DESC fields.
それぞれのスキーマ定義は、DESCフィールドを可能にします。 DESCフィールドは、提供されている場合、短い説明句を含むべきです。 DESCフィールドは、情報提供とみなさなければなりません。つまり、仕様は、その解釈が設け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.
拡張子は、実装は、彼らが公開スキーマに同じDESC場を提供することを義務付けないものとします。実装者は、交換またはDESCフィールドを削除することができます。
Published schema elements SHALL NOT be redefined. Replacement schema elements (new OIDs, new NAMEs) SHOULD be defined as needed.
公開されたスキーマ要素を再定義することはないものとします。必要に応じて交換用のスキーマ要素（新しいOIDが、新しい名前）を定義する必要があります。
Schema designers SHOULD reuse existing schema elements, where appropriate. However, any reuse MUST not alter the semantics of the element.
スキーマの設計者は、適切な既存のスキーマ要素を、再利用する必要があります。しかし、いずれの再利用は、要素のセマンティクスを変更してはいけません。
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構文は、（制約を含む）各個別の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）。ユニコード[UNICODE]の文字をエンコードされたこの文字列のエンコーディングがUTF-8 [RFC3629]に制限することが推奨されます。一般的な文字列符号化規則（GSER）[RFC3641]、[RFC3642]または他の一般的な文字列の符号化規則の使用が推奨され、複雑なASN.1データ定義の文字列エンコーディングを提供します。そうでなければ、それは文字列エンコーディング形式言語を用いて記述することが推奨されている（例えば、ABNF [RFC4234]）。正式言語は[FORMAL] IESGガイドラインに従って仕様で使用されるべきです。
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.
何文字列エンコーディングが定義されていない場合、エクステンションは、転送符号化が示されるべきである方法を指定します。一般的に、拡張子はバイナリまたは他の転送エンコードオプションの使用を強制すべきです。
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.
マッチングルール（例えば、平等、順序付け、および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.
マッチングルール仕様そのマッチングルールの種類があり、それを一緒に使用することができる値の種類を記述するべきで詳細にすべきです。
In addition to requirements stated in the LDAP technical specification, equality matching rules SHOULD be commutative.
LDAP技術仕様書に記載された要件に加え、平等マッチングルールは可換であるべきです。
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.
設計者は慎重値の構造を制限する方法を検討すべきです。設計者は、サーバーのみ、属性の構文の制約を適用することを検討すべきです。それは、URIを保持するための属性ですが、それはURIのある値に限定されるものではなく、directoryString構文を持っています。
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.
設計者は慎重にマッチングされたルールを検討する必要があり、もしあれば、属性タイプに適しています。属性タイプに指定したマッチングルールは属性タイプの構文と互換性がなければなりません。
Extensions specifying operational attributes MUST detail how servers are to maintain and/or utilize values of each operational attribute.
サーバがどのように操作属性のMUSTの詳細を指定する拡張機能の維持および/または各操作属性の値を利用します。
Designers SHOULD carefully consider whether each attribute of an object class is required ("MUST") or allowed ("MAY").
設計者は慎重にオブジェクトクラスの各属性が必要（「MUST」）または（「MAY」）を許可するかどうかを検討すべきです。
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.
操作属性を許可する（または必要）オブジェクトクラスを指定する拡張機能は、サーバの維持および/またはこれらのオブジェクトクラスに属するエントリを活用する方法を指定しなければなりません。
Each option is identified by a string of letters, numbers, and hyphens. This string SHOULD be short.
各オプションは、文字、数字、ハイフンの文字列で識別されます。この文字列は短くしてください。
Extensions interacting with authorization identities SHALL support the LDAP authzId format [RFC4513]. The authzId format is extensible.
承認アイデンティティとの相互作用拡張機能は、LDAP authzidは形式[RFC4513]をサポートするもの。 authzidはフォーマットは拡張可能です。
LDAP URL extensions are identified by a short string, a descriptor. Like other descriptors, the string SHOULD be short.
LDAPのURLの拡張子が短い文字列、記述子によって識別されます。他の記述子と同じように、文字列は短くしてください。
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 cannot be) all encompassing. Designers MUST do their own evaluations of the security considerations applicable to their extensions.
LDAPを実現することができる拡張の種類に過度の制限を課しません。この文書は、設計者が考慮する必要があるいくつかの特定の問題を概説しようとするが、それはすべて網羅されていない（とすることはできません）。設計者は、その拡張子に適用されるセキュリティ上の考慮事項の独自の評価を行う必要があります。
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.
拡張仕様は、しかし、彼らは拡張されている機能だけでなく、一般的なLDAPセキュリティの考慮事項に固有のセキュリティ上の考慮事項は、拡張機能に適用されるかどうかに注意してください。
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拡張スタイルガイド」[ガイド]上に構築されています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical Specification", RFC 2849, June 2000.
[RFC2849]グッド、G.、 "LDAPデータ交換フォーマット（LDIF） - 技術仕様"、RFC 2849、2000年6月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[RFC3641] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1 Types", RFC 3641, October 2003.
[RFC3641]レッグ、S.、 "ASN.1タイプのための一般的な文字列の符号化規則（GSER）"、RFC 3641、2003年10月。
[RFC3642] Legg, S., "Common Elements of Generic String Encoding Rules (GSER) Encodings", RFC 3642, October 2003.
[RFC3642]レッグ、S.、 "一般的な文字列符号化規則の共通要素（GSER）エンコーディング"、RFC 3642、2003年10月。
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006.
[RFC4512] Zeilenga、K.、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：ディレクトリ情報モデル"、RFC 4512、2006年6月。
[RFC3866] Zeilenga, K., Ed., "Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP)", RFC 3866, July 2004.
[RFC3866] Zeilenga、K.、エド。、RFC 3866、2004年7月 "のLDAP（Lightweight Directory Access Protocol）における言語タグと範囲"。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
[RFC4510] Zeilenga、K.、エド、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：技術仕様ロードマップ"。、RFC 4510、2006年6月。
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511] Sermersheim、J.、エド、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：プロトコル"、RFC 4511、2006年6月。
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006.
[RFC4512] Zeilenga、K.、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：ディレクトリ情報モデル"、RFC 4512、2006年6月。
[RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006.
[RFC4513]ハリソン、R.、エド、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：認証方法とセキュリティメカニズム"。、RFC 4513、2006年6月。
[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）：検索フィルタの文字列表現」、RFC 4515、2006年6月。
[RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator", RFC 4516, June 2006.
[RFC4516]スミス、M.、エド。そして、T.ハウズ、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：ユニフォームリソースロケータ"、RFC 4516、2006年6月。
[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
[RFC4517]レッグ、S.、エド、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：構文と一致規則"、RFC 4517、2006年6月。
[RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4518, June 2006.
[RFC4518] Zeilenga、K.、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：識別名の文字列表現"、RFC 4518、2006年6月。
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
[RFC4520] Zeilenga、K.、 "IANA（Internet Assigned Numbers Authority）のライトウェイトディレクトリアクセスプロトコル（LDAP）に関する考慮事項"、BCP 64、RFC 4520、2006年6月。
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422]メルニコフ、A.編。そして、K. Zeilenga、エド。、 "簡易認証セキュリティー層（SASL）"、RFC 4422、2006年6月。
[Unicode] The Unicode Consortium, "The Unicode Standard, Version 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the "Unicode Standard Annex #27: Unicode 3.1" (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/).
[UNICODE]ユニコードコンソーシアム、 "Unicode標準は、バージョン3.2.0" は、 "Unicode規格、バージョン3.0"（読書、MA、アディソン・ウェズリー、2000 ISBN 0-201-61633-5）などによって定義されます改正 "Unicode標準の附属書＃27：ユニコード3.1"（http://www.unicode.org/reports/tr27/）とで "Unicode標準の附属書＃28：Unicodeの3.2"（のhttp：//www.unicode .ORG /レポート/ 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/pseudo-code-in-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 / IEC 9594から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 / IEC 8824から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]国際電気通信連合 - 電気通信標準化部門、 "ASN.1エンコーディング規則の仕様：基本符号化規則（BER）、Canonicalの符号化規則（CER）、および顕著な符号化規則（DER）"、X.690（2002 ）（また、ISO / IEC 8825から1：2002）。
[ACID] Section 4 of ISO/IEC 10026-1:1992.
[ACID] ISO / IEC 10026から1のセクション4：1992。
[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.、RFC 3062、2001年2月 "LDAPパスワード変更拡張操作を"。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.1"、RFC 4346、2006年4月。
Author's Address
著者のアドレス
Kurt D. Zeilenga OpenLDAP Foundation
クルトD. ZeilengaのOpenLDAP財団
EMail: Kurt@OpenLDAP.org
メールアドレス：Kurt@OpenLDAP.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。