RFC3909 日本語訳

Network Working Group                                        K. Zeilenga
Request for Comments: 3909                           OpenLDAP Foundation
Category: Standards Track                                   October 2004

Zeilengaがコメントのために要求するワーキンググループK.をネットワークでつないでください: 3909年のOpenLDAP財団カテゴリ: 標準化過程2004年10月

             Lightweight Directory Access Protocol (LDAP)
                            Cancel Operation

ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)キャンセル操作

Status of this Memo

この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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2004).

Copyright(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)拡大手術について説明します。 LDAP Abandon操作にもかかわらず、X.511ディレクトリAccessプロトコル(DAP)放棄操作のように、この操作には、結果のしるしを供給する応答があります。

1.  Background and Intent of Use

1. 使用のバックグラウンドと意図

   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]はクライアントが他の操作を中止するのに使用するかもしれないAbandon操作[RFC2251]を提供します。 Abandon操作は、応答を持たないで、また捨てられた操作から応答を全く必要としません。 これらの意味論はAbandon操作の結果のどんな明確なしるしもクライアントに提供しません。

   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ディレクトリAccessプロトコル(DAP)[X.511]は応答を持って、また戻るために捨てられた操作を必要とするAbandon操作にそれが取り消されたのを示す応答を提供します。 LDAPキャンセル操作はDAP Abandon操作に倣われます。

   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キャンセル操作SHOULD、LDAP Abandon操作の代わりに、クライアントが結果のしるしを必要とするときには使用されてください。 この操作は、査問とアップデート操作の両方を中止するのに使用されるかもしれません。

Zeilenga                    Standards Track                     [Page 1]

RFC 3909                 LDAP Cancel Operation              October 2004

Zeilenga標準化過程[1ページ]RFC3909LDAPは操作2004年10月に取り消します。

   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で詳細な制限でBasic Encoding Rules[X.690]を使用することでコード化されることであることを意味します。

   DSA stands for Directory System Agent (or server).
   DSE stands for DSA-specific Entry.

DSAはディレクトリSystemエージェント(または、サーバ)を表します。 DSEはDSA特有のEntryを表します。

   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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14[RFC2119]で説明されるように本書では解釈されることであるべきですか?

2.  Cancel Operation

2. キャンセル操作

   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.

キャンセル操作はLDAP Extended Operation[RFC2251、セクション4.12]がオブジェクト識別子1.3.6.1で.8に.1を特定したと定義されます。 このセクションは、キャンセル要求と応答メッセージの構文を詳しく述べて、追加LDAP resultCodesを定義します。

2.1.  Cancel Request

2.1. キャンセル要求

   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.

キャンセル要求はrequestName分野が1.3に.6の.1の.1の.8とa requestValue分野を含んでいるBERによってコード化されたcancelRequestValue値を含むExtendedRequestです。

      cancelRequestValue ::= SEQUENCE {
          cancelID        MessageID
                          -- MessageID is as defined in [RFC2251]
      }

cancelRequestValue:、:= 系列cancelID MessageID、--MessageIDが[RFC2251]で定義されるようにある

   The cancelID field contains the message ID associated with the
   operation to be canceled.

cancelID分野はIDが取り消されるために操作に関連づけたメッセージを含んでいます。

2.2.  Cancel Response

2.2. 応答を中止してください。

   A Cancel response is an ExtendedResponse where the responseName and
   response fields are absent.

キャンセル応答はresponseNameと応答分野が欠けているExtendedResponseです。

2.3.  Additional Result Codes

2.3. 追加結果コード

   Implementations of this specification SHALL recognize the following
   additional resultCode values:

SHALLが、以下の追加resultCodeが評価すると認めるこの仕様の実装:

      canceled        (118)
      noSuchOperation (119)
      tooLate         (120)
      cannotCancel    (121)

取り消された(118)noSuchOperation(119)tooLate(120)cannotCancel(121)

Zeilenga                    Standards Track                     [Page 2]

RFC 3909                 LDAP Cancel Operation              October 2004

Zeilenga標準化過程[2ページ]RFC3909LDAPは操作2004年10月に取り消します。

3.  Operational Semantics

3. 操作上の意味論

   The function of the Cancel Operation is to request that the server
   cancel an outstanding operation issued within the same session.

キャンセルOperationの機能はサーバが同じセッション中に発行された傑出している操作を中止するよう要求することです。

   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.

クライアントは、cancelIDと共にキャンセルResponseを発行するのによる傑出している操作のcancelationが傑出している操作のメッセージIDにセットしたよう要求します。 キャンセルRequest自身には、異なったメッセージIDがあります。 クライアントSHOULD NOTは複数の回操作のcancelationを要求します。

   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によって特定された傑出している操作を中止できるなら、サーバSHALLはresultCode、およびSHALLが取り消されたresultCodeと共に失敗する取り消された操作を成功があるキャンセルResponseに返します。 さもなければ、キャンセルResponse SHALLは非成功resultCodeとSHALL NOTを傑出している操作に影響を与えさせます(存在しているなら)。

   The protocolError resultCode is returned if the server is unable to
   parse the requestValue or the requestValue is absent,

サーバがrequestValueを分析できないなら、protocolError resultCodeを返すか、またはrequestValueは欠けています。

   The noSuchOperation resultCode is returned if the server has no
   knowledge of the operation requested for cancelation.

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:

特定された操作がcancelationをサポートしないなら、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.

明確に、Abandon、Bind、Start TLS[RFC2830]、Unbind、およびキャンセル操作は「取り消-可能」ではありません。

   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を返すかもしれない、傑出、既に基本的なデータ・ストアにアップデートを遂行した操作を変更してください。

Zeilenga                    Standards Track                     [Page 3]

RFC 3909                 LDAP Cancel Operation              October 2004

Zeilenga標準化過程[3ページ]RFC3909LDAPは操作2004年10月に取り消します。

   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.

サーバSHOULDは、提供することによって、彼らのこの拡大手術のサポートを示します。1.3 .6 .1 .1 'supportedExtension'属性の値としての.8はそれらの根のDSEをタイプします。 サーバは、クライアントがそれを使用するのに権限を与えられるときだけ、この拡大の広告を出すのを選ぶかもしれません。

4.  Security Considerations

4. セキュリティ問題

   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協会の間に発行した操作を中止するのを許容することを意図します。 Proxy Authorization Controlが使用中である時などのある場合では、異なった傑出している操作は異なった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.

いくつかの操作が安全保障上の理由で「取り消-可能」であるはずがありません。 この仕様は、認証、承認、およびセキュリティ層の意味論に複雑さを追加するのを避けるためにBind操作とStart TLS拡大手術のcancelationを禁じます。 適切であるときに、今後の拡大手術、そして/または、コントロールのデザイナーは放棄とcancelationを禁じるべきです。

5.  IANA Considerations

5. IANA問題

   The following values [RFC3383] have been registered by the IANA.

以下の値[RFC3383]はIANAによって示されました。

5.1.  Object Identifier

5.1. オブジェクト識別子

   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はStandards ActionにLDAP Object Identifier1.3を登録しました。.6 .1 .1 .8 本書では定義されるようにLDAPキャンセルOperationを特定するために。

      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

Subject: 詳細のために連絡するLDAP Object Identifier Registration PersonとEメールアドレスのために以下を要求してください。 カート Zeilenga <kurt@OpenLDAP.org 、gt;、仕様: RFC3909作者/変化コントローラ: IESGはコメントします: LDAPキャンセル操作を特定します。

Zeilenga                    Standards Track                     [Page 4]

RFC 3909                 LDAP Cancel Operation              October 2004

Zeilenga標準化過程[4ページ]RFC3909LDAPは操作2004年10月に取り消します。

5.2.  LDAP Protocol Mechanism

5.2. LDAPプロトコルメカニズム

   The IANA has registered upon Standards Action the LDAP Protocol
   Mechanism described in this document.

IANAはStandards Actionに本書では説明されたLDAPプロトコルMechanismを登録しました。

      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

Subject: LDAPはメカニズム登録オブジェクト識別子について議定書の中で述べます: 1.3.6.1.1.8 記述: 詳細のために連絡するLDAPキャンセルOperation PersonとEメールアドレス: カート Zeilenga <kurt@openldap.org 、gt;、用法: 拡大手術仕様: RFC3909作者/変化コントローラ: IESGはコメントします: なし

5.3.  LDAP Result Codes

5.3. LDAP結果コード

   The IANA has registered upon Standards Action the LDAP Result Codes
   described in this document.

IANAはStandards Actionに本書では説明されたLDAP Result Codesを登録しました。

      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

Subject: 詳細のために連絡するLDAP Result Code Registration PersonとEメールアドレス: カート Zeilenga <kurt@OpenLDAP.org 、gt;、結果コードネーム: 取り消された(118)結果Code Name: noSuchOperation(119)結果コードネーム: tooLate(120)結果コードネーム: cannotCancel(121)仕様: RFC3909作者/変化コントローラ: IESG

6.  Acknowledgment

6. 承認

   The LDAP Cancel operation is modeled after the X.511 DAP Abandon
   operation.

LDAPキャンセル操作はX.511 DAP Abandon操作に倣われます。

Zeilenga                    Standards Track                     [Page 5]

RFC 3909                 LDAP Cancel Operation              October 2004

Zeilenga標準化過程[5ページ]RFC3909LDAPは操作2004年10月に取り消します。

7.  References

7. 参照

7.1.  Normative References

7.1. 引用規格

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

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

   [RFC2251]  Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
              Access Protocol (v3)", RFC 2251, December 1997.

[RFC2251]ウォール、M.、ハウズ、T.、およびS.Kille、「ライトウェイト・ディレクトリ・アクセス・プロトコル(v3)」、RFC2251 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)について議定書の中で述べます」。 「トランスポート層セキュリティのための拡大」(RFC2830)は2000がそうするかもしれません。

   [RFC3377]  Hodges, J. and R. Morgan, "Lightweight Directory Access
              Protocol (v3): Technical Specification", RFC 3377,
              September 2002.

[RFC3377] ホッジズ、J.、およびR.モーガン、「軽量のディレクトリアクセスは(v3)について議定書の中で述べます」。 「技術的な仕様」、RFC3377、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/IEC8824-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]国際電気通信連合--電気通信Standardization Sector、「ASN.1コード化の仕様は統治します」。 「規則(BER)、正準な符号化規則(CER)、および顕著な符号化規則(DER)をコード化する基礎」、X.690(1997)(ISO/IEC8825-1も: 1998)。

7.2.  Informative References

7.2. 有益な参照

   [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.、「インターネットはライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)のために数の権威(IANA)に問題を割り当てました」、BCP64、RFC3383、2002年9月。

   [X.511]    International Telecommunication Union - Telecommunication
              Standardization Sector, "The Directory: Abstract Service
              Definition", X.511(1993).

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

8.  Author's Address

8. 作者のアドレス

   Kurt D. Zeilenga
   OpenLDAP Foundation

カートD.Zeilenga OpenLDAP財団

   EMail: Kurt@OpenLDAP.org

メール: Kurt@OpenLDAP.org

Zeilenga                    Standards Track                     [Page 6]

RFC 3909                 LDAP Cancel Operation              October 2004

Zeilenga標準化過程[6ページ]RFC3909LDAPは操作2004年10月に取り消します。

9.  Full Copyright Statement

9. 完全な著作権宣言文

   Copyright (C) The Internet Society (2004).

Copyright(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.

このドキュメントはBCP78と、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.

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

Intellectual Property

知的所有権

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

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

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

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

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

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

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Zeilenga                    Standards Track                     [Page 7]

Zeilenga標準化過程[7ページ]