[要約] RFC 4521は、LDAP拡張機能に関する考慮事項をまとめたものであり、LDAPプロトコルの拡張性を向上させるためのガイドラインを提供しています。要約: RFC 4521はLDAP拡張機能に関するガイドラインです。 目的: LDAPプロトコルの拡張性を向上させるための考慮事項を提供します。
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
軽量ディレクトリアクセスプロトコル（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.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
Lightweight Directory Access Protocol（LDAP）は拡張可能です。新しい操作を追加し、既存の操作を拡張し、ユーザーとシステムのスキーマを拡大するメカニズムを提供します。このドキュメントでは、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.
Lightweight Directory Access 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では、プロトコルの抽象的な構文表記（1つの（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.
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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の多数の要素は、asn.1 [x.680]を使用して記載されており、基本エンコードルール（ber）[x.690]の特定のサブセット[プロトコル、セクション5.2]を使用してエンコードされます。LDAPの「コア」技術仕様[RFC4510]の実装に使用されるパーサー/ジェネレーターの再利用を許可するには、ASN.1によって記述された拡張要素（ControlValue、RequestValue、ResponseValueフィールド）の拡張要素（例：[プロトコル、セクション5.2]の制限を受ける。
Formal languages SHOULD be used in specifications in accordance with IESG guidelines [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拡張のプロトコル値を登録するものとします。新しい拡張可能なプロトコル要素を作成する仕様は、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.
カウンター（および不自然な）の例として、Locate Services操作（この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]（例：検索、変更）で定義された基本操作、拡張操作（例：Start 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].
既存の操作を拡張して、中間体験界[プロトコル、セクション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]で定義されているものを超えて、コントロールの臨界に追加のセマンティクスを添付してはなりません。仕様は、必要に応じて、特定の値（たとえば、真または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.
バインド操作を拡張するコントロールの詳細な仕様は、バインド交渉されたセキュリティレイヤーがこれらのコントロールに含まれる情報を保護しないことを詳述し、これらのコントロールの情報がどのように保護されているか、または情報が保護を必要としない理由を詳述するものとします。
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.
Start 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交渉セキュリティレイヤーがこれらのコントロールに含まれる情報を保護しないことを詳述し、これらのコントロールの情報がどのように保護されているか、または情報が保護を必要としない理由を詳述するものとします。
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.
放棄および非バインド操作には、応答メッセージが含まれていません。このため、放棄およびアンバインドリクエストに添付されるように設計されたコントロールの仕様は、コントロールの臨界性が虚偽であることを義務付ける必要があります。
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]は、新しい操作を定義するための推奨メカニズムです。拡張操作は、拡張レクエストメッセージ、ゼロ以上の中間患者メッセージ、および拡張された応答メッセージで構成されています。
Extensions SHALL use IntermediateResponse messages instead of ExtendedResponse messages to return intermediate results.
拡張機能は、中間結果を返すために、拡張応答メッセージの代わりに中間型メッセージを使用するものとします。
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.
未承諾通知[Protocol、セクション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では、LDAP ASN.1定義[プロトコル、付録B]の限定的な拡張[プロトコル、セクション4]を行うことができます。
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シーケンスのプロトコロップ選択を拡張することにより、新しいタイプの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.
BIND操作は現在、2つの認証方法、Simpleと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).
BIND操作の主な機能は、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タイプで楕円（...）が提供されています。暗黙の拡張性のため、クライアントとサーバーは（特に指定されていない限り）タグが認識されないトレーリングシーケンスコンポーネントを無視する必要があります。
Designers SHOULD avoid introducing extensions that rely on unsuspecting implementations to ignore trailing components of SEQUENCE whose tags they do not recognize.
設計者は、疑いを持たない実装に依存している拡張機能の導入を避けて、タグが認識されていないシーケンスの後続コンポーネントを無視する必要があります。
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.
名前フィールドを許可する定義の場合、新しいスキーマ要素は1つの名前のみを1つだけ提供する必要があります。名前は短いはずです。
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構文には、それに対して定義されている文字列エンコードが必要です。この文字列エンコードは、UTF-8 [RFC3629]エンコードされたUnicode [Unicode]文字に制限することをお勧めします。一般的な文字列エンコードルール（GSER）[RFC3641] [RFC3642]または複雑なASN.1データ定義の文字列エンコーディングを提供する他の汎用文字列エンコードルールの使用が推奨されます。それ以外の場合は、正式な言語（ABNF [RFC4234]など）を使用して、文字列エンコードを記述することをお勧めします。正式な言語は、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.
3つの基本的な種類のマッチングルール（例：平等、注文、およびサブストリング）は、属性タイプに関連付けられている場合があります。さらに、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.
設計者は、値の構造がどのように制限されるかを慎重に検討する必要があります。設計者は、サーバーが属性の構文の制約のみを実施することを考慮する必要があります。つまり、urisを保持することを目的とした属性ですが、それはdirectorystring構文を備えており、urisである値に制限されていません。
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.
操作属性を指定する拡張機能は、各動作属性の値を維持および/または利用するためのサーバーの詳細を詳述する必要があります。
Designers SHOULD carefully consider whether each attribute of an object class is required ("MUST") or allowed ("MAY").
設計者は、オブジェクトクラスの各属性が必要（「必須」）または許可（「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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Good、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] Legg、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] Legg、S。、「一般的な文字列エンコーディングルール（GSER）エンコーディングの共通要素」、RFC 3642、2003年10月。
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006.
[RFC4512] Zeilenga、K。、「Lightweight Directory Access Protocol（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.、ed。、「Lightweight Directory Access Protocol（LDAP）の言語タグと範囲」、RFC 3866、2004年7月。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234] Crocker、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。、ed。、「Lightweight Directory Access Protocol（LDAP）：技術仕様ロードマップ」、RFC 4510、2006年6月。
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511] Sermersheim、J.、ed。、「Lightweight Directory Access Protocol（LDAP）：The Protocol」、RFC 4511、2006年6月。
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006.
[RFC4512] Zeilenga、K。、「Lightweight Directory Access Protocol（LDAP）：ディレクトリ情報モデル」、RFC 4512、2006年6月。
[RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006.
[RFC4513] Harrison、R.、ed。、「Lightweight Directory Access Protocol（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. Howes、「Lightweight Directory Access Protocol（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. Howes、「Lightweight Directory Access Protocol（LDAP）：ユニフォームリソースロケーター」、RFC 4516、2006年6月。
[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
[RFC4517] Legg、S.、ed。、「Lightweight Directory Access Protocol（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。、「Lightweight Directory Access Protocol（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。、「Internet Assigned Numbers Authority（IANA）Lightwight Directory Access Protocol（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] Melnikov、A.、ed。K. Zeilenga編、「Simple Authentication and Security Layer（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 Consortium、「Unicode Standard、バージョン3.2.0」は、「Unicode Standard、バージョン3.0」（Reading、MA、Addison-Wesley、2000。ISBN0-201-61633-5）で定義されています。「Unicode Standard Annex＃27：Unicode 3.1」（http://www.unicode.org/reports/tr27/）および「Unicode Standard Annex＃28：Unicode 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.
[正式] 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）、標準エンコードルール（CER）、および区別されたエンコードルール（der）」、X.690（2002）（ISO/IEC 8825-1：2002）。
[ACID] Section 4 of ISO/IEC 10026-1:1992.
[酸] ISO/IEC 10026-1：1992のセクション4。
[GUIDE] Greenblatt, B., "LDAP Extension Style Guide", Work in Progress.
[ガイド] Greenblatt、B。、「LDAP拡張スタイルガイド」、進行中の作業。
[RFC3062] Zeilenga, K., "LDAP Password Modify Extended Operation", RFC 3062, February 2001.
[RFC3062] Zeilenga、K。、「LDAPパスワードの変更拡張操作」、RFC 3062、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. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.1」、RFC 4346、2006年4月。
Author's Address
著者の連絡先
Kurt D. Zeilenga OpenLDAP Foundation
Kurt D. Zeilenga OpenLdap Foundation
EMail: Kurt@OpenLDAP.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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）によって提供されます。