Network Working Group K. Zeilenga
Request for Comments: 3909 OpenLDAP Foundation
Category: Standards Track October 2004
Lightweight Directory Access Protocol (LDAP)
Cancel Operation
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This specification describes a Lightweight Directory Access Protocol (LDAP) extended operation to cancel (or abandon) an outstanding operation. Unlike the LDAP Abandon operation, but like the X.511 Directory Access Protocol (DAP) Abandon operation, this operation has a response which provides an indication of its outcome.
この仕様は、LDAP（Lightweight Directory Access Protocol）のキャンセル（または放棄）する操作を拡張し、優れた操作について説明しています。 LDAPとは異なり、操作を放棄ますが、X.511ディレクトリアクセスプロトコル（DAP）のような操作を放棄、この操作は、その結果の表示を提供する応答を有します。
The Lightweight Directory Access Protocol (LDAP) [RFC3377] provides an Abandon operation [RFC2251] which clients may use to cancel other operations. The Abandon operation does not have a response and requires no response from the abandoned operation. These semantics provide the client with no clear indication of the outcome of the Abandon operation.
ライトウェイトディレクトリアクセスプロトコル（LDAP）[RFC3377]は、クライアントが他の操作を取り消すために使用することができる放棄操作[RFC2251]を提供します。放棄操作が応答を持っており、捨てられた操作からの応答を必要としません。これらのセマンティクスは中止操作の結果の明確な兆候をクライアントに提供します。
The X.511 Directory Access Protocol (DAP) [X.511] provides an Abandon operation which has a response and also requires the abandoned operation to return a response indicating it was canceled. The LDAP Cancel operation is modeled after the DAP Abandon operation.
X.511ディレクトリアクセスプロトコル（DAP）[X.511]は、応答を有する放棄動作を提供し、また、それがキャンセルされた旨の応答を返すように放棄された操作を必要とします。 DAPが操作を放棄した後、LDAPキャンセル操作がモデル化されています。
The LDAP Cancel operation SHOULD be used instead of the LDAP Abandon operation when the client needs an indication of the outcome. This operation may be used to cancel both interrogation and update operations.
LDAPキャンセル操作は、クライアントが結果の表示を必要とするときの動作を放棄代わりにLDAPを使用するべきです。この動作は、両方の問い合わせおよび更新操作をキャンセルするために使用することができます。
Protocol elements are described using ASN.1 [X.680] with implicit tags. The term "BER-encoded" means the element is to be encoded using the Basic Encoding Rules [X.690] under the restrictions detailed in Section 5.1 of [RFC2251].
プロトコル要素は、暗黙的なタグでASN.1 [X.680]を使用して記載されています。用語「BERエンコードは」要素は[RFC2251]のセクション5.1に詳述制約下基本符号化規則[X.690]を使用して符号化されるべきであることを意味します。
DSA stands for Directory System Agent (or server). DSE stands for DSA-specific Entry.
DSAは、ディレクトリシステムエージェント（またはサーバー）の略です。 DSEは、DSA固有のエントリを表します。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14 [RFC2119]に記載されているように解釈されます。
The Cancel operation is defined as an LDAP Extended Operation [RFC2251, Section 4.12] identified by the object identifier 1.3.6.1.1.8. This section details the syntax of the Cancel request and response messages and defines additional LDAP resultCodes.
キャンセル操作は、オブジェクト識別子1.3.6.1.1.8によって特定された操作の拡張LDAP [RFC2251、4.12]のように定義されます。このセクションでは、キャンセル要求メッセージと応答メッセージの構文を詳述し、追加のLDAP resultCodesを定義します。
The Cancel request is an ExtendedRequest with the requestName field containing 1.3.6.1.1.8 and a requestValue field which contains a BER-encoded cancelRequestValue value.
要求を取り消し1.3.6.1.1.8とBERエンコードcancelRequestValue値を含むrequestValueフィールドを含むrequestNameフィールドとのExtendedRequestあります。
cancelRequestValue ::= SEQUENCE {
cancelID MessageID
-- MessageID is as defined in [RFC2251]
}
The cancelID field contains the message ID associated with the operation to be canceled.
cancelIDフィールドが解除される動作に関連するメッセージIDを含んでいます。
A Cancel response is an ExtendedResponse where the responseName and response fields are absent.
キャンセル応答はresponseName及び応答フィールドが存在しないExtendedResponseあります。
Implementations of this specification SHALL recognize the following additional resultCode values:
この仕様の実装は、以下の追加のresultCode値を認識しなければなりません：
canceled (118) noSuchOperation (119) tooLate (120) cannotCancel (121)
（118）noSuchOperation（119）TooLate（120）cannotCancel（121）が解除
The function of the Cancel Operation is to request that the server cancel an outstanding operation issued within the same session.
キャンセル操作の機能は、サーバが同一セッション内で発行された優れた操作をキャンセルすることを要求することです。
The client requests the cancelation of an outstanding operation by issuing a Cancel Response with a cancelID set to the message ID of the outstanding operation. The Cancel Request itself has a distinct message ID. Clients SHOULD NOT request the cancelation of an operation multiple times.
クライアントは、優れた操作のメッセージIDに設定されcancelIDとキャンセル応答を発行することにより、優れた操作のキャンセルを要求します。キャンセル要求自体は、別個のメッセージIDを有しています。クライアントは、操作を複数回のキャンセルを要求すべきでありません。
If the server is willing and able to cancel the outstanding operation identified by the cancelId, the server SHALL return a Cancel Response with a success resultCode, and the canceled operation SHALL fail with canceled resultCode. Otherwise the Cancel Response SHALL have a non-success resultCode and SHALL NOT have an impact upon the outstanding operation (if it exists).
サーバが喜んとcancelIdで識別される優れた操作を取り消すことができる場合、サーバは成功のresultCodeとキャンセルレスポンスを返すものとし、キャンセル操作がキャンセルのresultCodeで失敗しないものとします。それ以外の場合はキャンセル応答は非成功のresultCodeを有するものとし、優れた操作（存在する場合）の際に影響を与えてはなりません。
The protocolError resultCode is returned if the server is unable to parse the requestValue or the requestValue is absent,
サーバがrequestValueを解析することができませんかrequestValueが存在しない場合はProtocolErrorのresultCodeは、返されます
The noSuchOperation resultCode is returned if the server has no knowledge of the operation requested for cancelation.
サーバーは、キャンセルのために要求された操作の知識を持たない場合noSuchOperationのresultCodeが返されます。
The cannotCancel resultCode is returned if the identified operation does not support cancelation or the cancel operation could not be performed. The following classes of operations are not cancelable:
特定された操作はキャンセルをサポートしていない場合cannotCancelのresultCodeが返されるか、キャンセル操作を行うことができませんでした。操作の以下のクラスはキャンセルできない、次のとおりです。
- operations which have no response,
- 応答を持っていない操作、
- operations which create, alter, or destroy authentication and/or authorization associations,
- 作成操作、変更、または認証および/または許可の関連付けを破壊し、
- operations which establish, alter, or tear-down security services, and
- 確立操作、変更、またはティアダウンセキュリティサービス、および
- operations which abandon or cancel other operations.
- 放棄または他の操作を取り消す操作。
Specifically, the Abandon, Bind, Start TLS [RFC2830], Unbind, and Cancel operations are not cancelable.
具体的には、バインド、スタートTLS [RFC2830]、アンバインドを破棄し、キャンセル操作がキャンセルされません。
The Cancel operation cannot be abandoned.
キャンセル操作が放棄さすることはできません。
The tooLate resultCode is returned to indicate that it is too late to cancel the outstanding operation. For example, the server may return tooLate for a request to cancel an outstanding modify operation which has already committed updates to the underlying data store.
tooLateのresultCodeは、優れた操作をキャンセルするには遅すぎであることを示すために返されます。例えば、サーバーは、基礎となるデータストアにすでにコミットされた更新を持つ優秀な変更操作をキャンセルする要求のためのtooLateを返すことがあります。
Servers SHOULD indicate their support for this extended operation by providing 1.3.6.1.1.8 as a value of the 'supportedExtension' attribute type in their root DSE. A server MAY choose to advertise this extension only when the client is authorized to use it.
サーバはそのルートDSEの「supportedExtension」属性型の値として1.3.6.1.1.8を提供することによって、この拡張操作のための彼らのサポートを示すべきです。サーバーは、クライアントがそれを使用することが許可されているだけで、この拡張機能を宣伝するために選ぶかもしれません。
This operation is intended to allow a user to cancel operations they previously issued during the current LDAP association. In certain cases, such as when the Proxy Authorization Control is in use, different outstanding operations may be processed under different LDAP associations. Servers MUST NOT allow a user to cancel an operation belonging to another user.
この操作は、ユーザーは、彼らが以前に現在のLDAP協会の間に発行された操作を取り消すことができるように意図されます。そのようなプロキシ許可制御を使用している場合などの特定のケースでは、異なる未処理の操作が異なるLDAPアソシエーション下で処理することができます。サーバは、ユーザが他のユーザに属する操作をキャンセルするのを許してはなりません。
Some operations should not be cancelable for security reasons. This specification disallows the cancelation of the Bind operation and Start TLS extended operation so as to avoid adding complexity to authentication, authorization, and security layer semantics. Designers of future extended operations and/or controls should disallow abandonment and cancelation when appropriate.
一部の操作は、セキュリティ上の理由で解約すべきではありません。この仕様は、バインド操作のキャンセルを許可しないと、認証、許可、およびセキュリティ層のセマンティクスに複雑にすることを避けるようにスタートTLS操作を拡張しました。適切な場合、将来の拡張操作および/または制御の設計者は、放棄及び解除を禁止すべきです。
The following values [RFC3383] have been registered by the IANA.
次の値[RFC3383]はIANAによって登録されています。
The IANA has registered upon Standards Action the LDAP Object Identifier 1.3.6.1.1.8 to identify the LDAP Cancel Operation as defined in this document.
IANAは標準アクション時に、この文書で定義されたLDAP操作をキャンセル識別するためのLDAPオブジェクト識別子1.3.6.1.1.8を登録しています。
Subject: Request for LDAP Object Identifier Registration Person & email address to contact for further information: Kurt Zeilenga <kurt@OpenLDAP.org> Specification: RFC 3909 Author/Change Controller: IESG Comments: Identifies the LDAP Cancel Operation
件名：詳細のために連絡するLDAPオブジェクト識別子の登録人とEメールアドレスの要求：クルト・Zeilenga <kurt@OpenLDAP.org>仕様：RFC 3909著者/変更コントローラ：IESGはコメント：LDAP操作をキャンセル識別
The IANA has registered upon Standards Action the LDAP Protocol Mechanism described in this document.
IANAは標準アクション時に、この文書で説明するLDAPプロトコルメカニズムを登録しています。
Subject: LDAP Protocol Mechanism Registration Object Identifier: 1.3.6.1.1.8 Description: LDAP Cancel Operation Person & email address to contact for further information: Kurt Zeilenga <kurt@openldap.org> Usage: Extended Operation Specification: RFC 3909 Author/Change Controller: IESG Comments: none
件名：LDAPプロトコルメカニズム登録オブジェクト識別子：1.3.6.1.1.8説明：LDAPの詳細のために連絡する操作人とEメールアドレスをキャンセル：クルトZeilenga <kurt@openldap.org>使用法：拡張動作仕様：RFC 3909著者/変更コントローラ：IESGコメント：なし
The IANA has registered upon Standards Action the LDAP Result Codes described in this document.
IANAは標準アクション時に、この文書で説明するLDAPの結果コードを登録しています。
Subject: LDAP Result Code Registration Person & email address to contact for further information: Kurt Zeilenga <kurt@OpenLDAP.org> Result Code Name: canceled (118) Result Code Name: noSuchOperation (119) Result Code Name: tooLate (120) Result Code Name: cannotCancel (121) Specification: RFC 3909 Author/Change Controller: IESG
件名：LDAP結果コード登録人とEメールアドレスは、詳細のために連絡する：クルトZeilenga <kurt@OpenLDAP.org>コードネームを結果：キャンセル（118）結果コード名：noSuchOperation（119）結果コード名：tooLate（120）結果コードネーム：cannotCancel（121）仕様：RFC 3909著者/変更コントローラ：IESG
The LDAP Cancel operation is modeled after the X.511 DAP Abandon operation.
LDAPキャンセル操作は、X.511のDAP放棄操作の後にモデル化されています。
[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月。
[RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[RFC2251]ワール、M.、ハウズ、T.、およびS. Kille、 "軽量のディレクトリアクセスプロトコル（V3）"、RFC 2251、1997年12月。
[RFC2830] Hodges, J., Morgan, R., and M. Wahl, "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security", RFC 2830, May 2000.
[RFC2830]ホッジス、J.、モルガン、R.、およびM.ワール、 "ライトウェイトディレクトリアクセスプロトコル（v3の）：トランスポート層セキュリティのための拡張"、RFC 2830、2000年5月。
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002.
[RFC3377]ホッジス、J.とR.モルガン、 "ライトウェイトディレクトリアクセスプロトコル（v3の）：技術仕様"、RFC 3377、2002年9月。
[X.680] International Telecommunication Union - Telecommunication Standardization Sector, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
[X.680]国際電気通信連合 - 電気通信標準化部門、 "抽象構文記法1（ASN.1） - 基本的な記法の仕様"、X.680（1997）（また、ISO / IEC 8824から1：1998）。
[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(1997) (also ISO/IEC 8825-1:1998).
[X.690]国際電気通信連合 - 電気通信標準化部門、 "ASN.1エンコーディング規則の仕様：基本符号化規則（BER）、Canonicalの符号化規則（CER）、および顕著な符号化規則（DER）"、X.690（1997 ）（また、ISO / IEC 8825から1：1998）。
[RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
[RFC3383] Zeilenga、K.、 "IANA（Internet Assigned Numbers Authority）のライトウェイトディレクトリアクセスプロトコル（LDAP）に関する考慮事項"、BCP 64、RFC 3383、2002年9月。
[X.511] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory: Abstract Service Definition", X.511(1993).
[X.511]国際電気通信連合 - 電気通信標準化部門、 "ディレクトリ：抽象サービス定義"、X.511（1993）。
Kurt D. Zeilenga OpenLDAP Foundation
クルトD. ZeilengaのOpenLDAP財団
EMail: Kurt@OpenLDAP.org
メールアドレス：Kurt@OpenLDAP.org
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and at www.rfc-editor.org, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、www.rfc-editor.orgで、そこに記載される場合を除き、作者は彼らのすべての権利を保有します。
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 ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 ISOC文書の権利に関するISOCの手順に関する情報は、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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。