RFC3771 日本語訳

Network Working Group                                        R. Harrison
Request for Comments: 3771                                  Novell, Inc.
Updates: 2251                                                K. Zeilenga
Category: Standards Track                            OpenLDAP Foundation
                                                              April 2004

コメントを求めるワーキンググループR.ハリソンの要求をネットワークでつないでください: 3771のノベルInc.アップデート: 2251年のK.Zeilengaカテゴリ: 標準化過程OpenLDAP財団2004年4月

           The Lightweight Directory Access Protocol (LDAP)
                     Intermediate Response Message

ライトウェイト・ディレクトリ・アクセス・プロトコル(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).  All Rights Reserved.

Copyright(C)インターネット協会(2004)。 All rights reserved。

Abstract

要約

   This document defines and describes the IntermediateResponse message,
   a general mechanism for defining single-request/multiple-response
   operations in Lightweight Directory Access Protocol (LDAP).  The
   IntermediateResponse message is defined in such a way that the
   protocol behavior of existing LDAP operations is maintained.  This
   message is intended to be used in conjunction with the LDAP
   ExtendedRequest and ExtendedResponse to define new single-
   request/multiple-response operations or in conjunction with a control
   when extending existing LDAP operations in a way that requires them
   to return intermediate response information.

このドキュメントは、IntermediateResponseメッセージ(ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)で複数のただ一つの要求/応答操作を定義するための一般的機構)を定義して、説明します。 IntermediateResponseメッセージは既存のLDAP操作のプロトコルの振舞いが維持されるような方法で定義されます。 中間的応答情報を返すのを必要とする方法で既存のLDAP操作を広げるとき、新しいただ一つの複数の要求/応答操作を定義するLDAP ExtendedRequestとExtendedResponseに関連してコントロールに関連してこのメッセージが使用されることを意図します。

Harrison & Zeilenga         Standards Track                     [Page 1]

RFC 3771               LDAP Intermediate Response             April 2004

ハリソンとZeilenga規格は中間的LDAP応答2004年4月にRFC3771を追跡します[1ページ]。

1.  Introduction

1. 序論

   The Lightweight Directory Access Protocol (LDAP), version 3 [RFC3377]
   is an extensible protocol.  Extended operations ([RFC2251] Section
   4.12) are defined to allow for the addition of operations to LDAP,
   without requiring revisions of the protocol.  Similarly, controls
   ([RFC2251] Section 4.1.12) are defined to extend or modify the
   behavior of existing LDAP operations.

ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)、バージョン3[RFC3377]は広げることができるプロトコルです。 拡大手術([RFC2251]セクション4.12)はLDAPにおいて操作の追加を考慮するために定義されます、プロトコルの改正を必要としないで。 同様に、コントロール([RFC2251]セクション4.1.12)は、既存のLDAP操作の振舞いを広げているか、または変更するために定義されます。

   LDAP is a client-request/server-response based protocol.  With the
   exception of the search operation, the entire response to an
   operation request is returned in a single protocol data unit (i.e.,
   LDAP message).  While this single-request/single-response paradigm is
   sufficient for many operations (including all but one of those
   currently defined by [RFC3377]), both intuition and practical
   experience validate the notion that it is insufficient for others.

LDAPはベースのサーバクライアント要求/応答プロトコルです。 索敵行動を除いて、1つのプロトコルデータ単位(すなわち、LDAPメッセージ)で操作要求への全体の応答を返します。 このただ一つのただ一つの要求/応答パラダイムが多くの操作(現在[RFC3377]によって定義されているものの1つ以外のすべてを含んでいる)に十分である間、直観と実用的な経験の両方が他のものにとって、それが不十分であるという概念を有効にします。

   For example, the LDAP delete operation could be extended via a
   subtree control to mean that an entire subtree is to be deleted.  A
   subtree delete operation needs to return continuation references
   based upon subordinate knowledge information contained in the server
   so that the client can complete the operation.  Returning references
   as they are found, instead of with the final result, allows the
   client to perform the operation more efficiently because it does not
   have to wait for the final result to get this continuation reference
   information.

例えば、LDAPは操作を削除します。全体の下位木が削除されることであることを意味する下位木コントロールで広げることができるでしょう。 下位木はクライアントが操作を完了できるようにサーバに含まれた下位の知識情報に基づく継続参照を返す操作の必要性を削除します。 それらが最終的な結果の代わりに見つけられるので参照を返すのに、最終的な結果がこの継続参考情報を得るのを待つ必要はないので、クライアントは、より効率的に操作を実行できます。

   Similarly, an engineer might choose to design the subtree delete
   operation as an extended operation of its own rather than using a
   subtree control in conjunction with the delete operation.  Once
   again, the same continuation reference information is needed by the
   client to complete the operation, and sending the continuation
   references as they are found would allow the client to perform the
   operation more efficiently.

に関連して同様に、技術者が下位木コントロールを使用するよりむしろそれ自身の拡張操作として下位木が削除するデザインに操作を選ぶかもしれない、操作を削除してください。 もう一度、同じ継続参考情報は操作を完了するためにクライアントによって必要とされます、そして、それらが見つけられるので継続参照を送るのはクライアントが、より効率的に操作を実行するのを許容するでしょう。

   Operations that are completed in stages or that progress through
   various states as they are completed might want to send intermediate
   responses to the client, thereby informing it of the status of the
   operation.  For example, an LDAP implementation might define an
   extended operation to create a new replica of an administrative area
   on a server, and the operation is completed in three stages: (1)
   begin creation of replica, (2) send replica data to server, (3)
   replica creation complete.  Intermediate messages might be sent from
   the server to the client at the beginning of each stage with the
   final response for the extended operation being sent after stage (3)
   is complete.

完成するとき様々な州を通ってステージかその進行中で完了している操作は中間的応答をクライアントに送りたがっているかもしれません、その結果、操作の状態についてそれを知らせます。 例えば、LDAP実装は行政区域の新しいレプリカをサーバに作成するために拡大手術を定義するかもしれません、そして、操作は3つの段階で完了しています: (1) (2) レプリカの作成を始めてください、そして、サーバ、(3)レプリカ作成にレプリカデータを完全な状態で送ってください。 それぞれのステージの始めに中間的メッセージをサーバからクライアントにステージ(3)が完全になった後に拡大手術のための最終的な応答を送って送るかもしれません。

Harrison & Zeilenga         Standards Track                     [Page 2]

RFC 3771               LDAP Intermediate Response             April 2004

ハリソンとZeilenga規格は中間的LDAP応答2004年4月にRFC3771を追跡します[2ページ]。

   As LDAP [RFC3377] is currently defined, there is no general LDAP
   message type that can be used to return intermediate results.  A
   single, reusable LDAP message for carrying intermediate response
   information is desired to avoid repeated modification of the
   protocol.  Although the ExtendedResponse message is defined in LDAP,
   it is defined to be the one and only response message to an
   ExtendedRequest message ([RFC2251] Section 4.12), for unsolicited
   notifications ([RFC2251] Section 4.4), and to return intermediate
   responses for the search operation ([RFC3377] Section 4.5.2, also see
   Section 5 below).  The adaptation of ExtendedResponse as a general
   intermediate response mechanism would be problematic.  In particular,
   existing APIs would likely have to be redesigned.  It is believed
   (based upon operational experience) that the addition of a new
   message to carry intermediate result information is easier to
   implement and is less likely to cause interoperability problems with
   existing deployed implementations.

LDAP[RFC3377]が現在定義されるとき、中間結果を返すのに使用できるどんな一般的なLDAPメッセージタイプもありません。 中間的応答情報を運ぶことへの単一の、そして、再利用できるLDAPメッセージがプロトコルの繰り返された変更を避けることが望まれています。 ExtendedResponseメッセージはLDAPで定義されますが、それは、ExtendedRequestメッセージへの唯一無二の応答メッセージになるように定義されます(また、[RFC2251] セクション4.12)は求められていない通知([RFC2251]セクション4.4)と、そして、索敵行動[RFC3377]部4.5の.2のためのリターンの中間的応答に以下のセクション5を見ます)。 一般的な中間的反応機構としてのExtendedResponseの適合は問題が多いでしょう。 特に、既存のAPIはおそらく再設計されなければならないでしょう。 中間結果情報を運ぶ新しいメッセージの追加が実装するのが、より簡単であり、実装であると配布される存在に関する相互運用性問題をより引き起こしそうにないと信じられています(運用経験に基づいています)。

   This document defines and describes the LDAP IntermediateResponse
   message.  This message is intended to be used in conjunction with
   ExtendedRequest and ExtendedResponse to define new single-
   request/multiple-response operations or in conjunction with a control
   when extending existing LDAP operations in a way that requires them
   to return intermediate response information.

このドキュメントは、LDAP IntermediateResponseメッセージを定義して、説明します。 中間的応答情報を返すのを必要とする方法で既存のLDAP操作を広げるとき、新しいただ一つの複数の要求/応答操作を定義するExtendedRequestとExtendedResponseに関連してコントロールに関連してこのメッセージが使用されることを意図します。

   It is intended that the definitions and descriptions of extended
   operations and controls using the IntermediateResponse message will
   define the circumstances in which an IntermediateResponse message can
   be sent by a server and the associated meaning of the
   IntermediateResponse message sent in a particular circumstance.
   Similarly, it is intended that clients will explicitly solicit
   IntermediateResponse messages by issuing operations that specifically
   call for their return.

IntermediateResponseメッセージを使用する拡大手術とコントロールの定義と記述がサーバでIntermediateResponseメッセージを送ることができて、IntermediateResponseメッセージの関連意味が特定の状況を送った事情を定義することを意図します。 同様に、明確に彼らの帰りを求める操作を発行することによってクライアントが明らかにIntermediateResponseメッセージに請求することを意図します。

   The LDAP Content Sync Operation [ZEILENGA] demonstrates one use of
   LDAP Intermediate Response messages.

LDAP Content Sync Operation[ZEILENGA]はLDAP Intermediate Responseメッセージの1つの使用を示します。

2.  Conventions used in this document

2. 本書では使用されるコンベンション

   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 [RFC2119].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?

   The term "request control" is used to describe a control that is
   included in an LDAP request message sent from an LDAP client to an
   LDAP server.

「コントロールを要求する」という用語は、LDAPクライアントからLDAPサーバに送られたLDAP要求メッセージに含まれているコントロールについて説明するのに使用されます。

Harrison & Zeilenga         Standards Track                     [Page 3]

RFC 3771               LDAP Intermediate Response             April 2004

ハリソンとZeilenga規格は中間的LDAP応答2004年4月にRFC3771を追跡します[3ページ]。

3.  The IntermediateResponse Message

3. IntermediateResponseメッセージ

   This document extends the protocolOp CHOICE of LDAPMessage ([RFC2251]
   Section 4.1.1) to include the field:

このドキュメントは分野を含むようにLDAPMessage([RFC2251]セクション4.1.1)のprotocolOp CHOICEを広げています:

           intermediateResponse  IntermediateResponse

intermediateResponse IntermediateResponse

   where IntermediateResponse is defined as:

どこIntermediateResponseは以下と定義されるか。

           IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
                   responseName     [0] LDAPOID OPTIONAL,
                   responseValue    [1] OCTET STRING OPTIONAL }

IntermediateResponse:、:= [アプリケーション25] 系列任意であって、responseValue[1]八重奏ストリング任意の状態で[0] LDAPOIDをresponseNameします。

   IntermediateResponse messages SHALL NOT be returned to the client
   unless the client issues a request that specifically solicits their
   return.  This document defines two forms of solicitation: extended
   operation and request control.

IntermediateResponseはSHALL NOTを通信させます。クライアントが明確に彼らの帰りに請求する要求を出さない場合、クライアントに返します。 このドキュメントは2つの形式の懇願を定義します: 拡大手術と要求は制御されます。

   Although the responseName and responseValue are optional in some
   circumstances, IntermediateResponse messages usually have a
   predefined responseName and a responseValue.  The value of the
   responseName (if present), the syntax of the responseValue (if
   present) and the semantics associated with a particular
   IntermediateResponse message MUST be specified in documents
   describing the extended operation or request control that uses them.
   Sections 3.1 and 3.2 describe additional requirements for the
   inclusion of responseName and responseValue in IntermediateResponse
   messages.

responseNameとresponseValueはいくつかの事情で任意ですが、IntermediateResponseメッセージには、通常、事前に定義されたresponseNameとresponseValueがあります。 responseNameの値(存在しているなら)、responseValueの構文(存在しているなら)、および特定のIntermediateResponseメッセージに関連している意味論は、拡大手術について説明するドキュメントで指定されなければならないか、またはそれらを使用するコントロールを要求しなければなりません。 セクション3.1と3.2はIntermediateResponseメッセージでresponseNameとresponseValueの包含のための追加要件について説明します。

3.1.  Usage with LDAP ExtendedRequest and ExtendedResponse

3.1. LDAP ExtendedRequestとExtendedResponseがある用法

   A single-request/multiple-response operation may be defined using a
   single ExtendedRequest message to solicit zero or more
   IntermediateResponse messages, of one or more kinds, followed by an
   ExtendedResponse message.

複数のただ一つの要求/応答操作がゼロに請求するただ一つのExtendedRequestメッセージを使用することで定義されたかもしれませんか、または、より多くのIntermediateResponseメッセージがExtendedResponseメッセージで1種類以上に続きました。

   An extended operation that defines the return of multiple kinds of
   IntermediateResponse messages MUST provide and document a mechanism
   for the client to distinguish the kind of IntermediateResponse
   message being sent.  This SHALL be accomplished by using different
   responseName values for each type of IntermediateResponse message
   associated with the extended operation or by including identifying
   information in the responseValue of each type of IntermediateResponse
   message associated with the extended operation.

クライアントが送られるIntermediateResponseメッセージの種類を区別するように、複数の種類のIntermediateResponseメッセージの復帰を定義する拡大手術は、メカニズムを提供して、記録しなければなりません。 拡大手術に関連しているIntermediateResponseメッセージの各タイプに異なったresponseName値を使用することによって達成されるか、または包含することによってそれぞれのresponseValueの情報を特定するとタイプされるIntermediateResponseメッセージのこのSHALLは拡大手術と交際しました。

Harrison & Zeilenga         Standards Track                     [Page 4]

RFC 3771               LDAP Intermediate Response             April 2004

ハリソンとZeilenga規格は中間的LDAP応答2004年4月にRFC3771を追跡します[4ページ]。

3.2.  Usage with LDAP Request Controls

3.2. LDAP要求コントロールがある用法

   Any LDAP operation may be extended by the addition of one or more
   controls ([RFC2251] Section 4.1.12).  A control's semantics may
   include the return of zero or more IntermediateResponse messages
   prior to returning the final result code for the operation.  One or
   more kinds of IntermediateResponse messages may be sent in response
   to a request control.

どんなLDAP操作も1つ以上のコントロール([RFC2251]セクション4.1.12)の追加によって広げられるかもしれません。 コントロールの意味論は最終的な結果を返す前のIntermediateResponseメッセージが操作のためにコード化するゼロか以上の復帰を含むかもしれません。 要求コントロールに対応して1種類以上のIntermediateResponseメッセージを送るかもしれません。

   All IntermediateResponse messages associated with request controls
   SHALL include a responseName.  This requirement ensures that the
   client can correctly identify the source of IntermediateResponse
   messages when:

要求コントロールSHALLに関連しているすべてのIntermediateResponseメッセージがresponseNameを含んでいます。 この要件は、クライアントがIntermediateResponseメッセージの源のために正しくいつかを特定できるのを確実にします:

      a) two or more controls using IntermediateResponse messages are
         included in a request for any LDAP operation or

またはIntermediateResponseメッセージを使用するより多くのa)twoコントロールがどんなLDAP操作を求める要求にも含まれている。

      b) one or more controls using IntermediateResponse messages are
         included in a request with an LDAP extended operation that uses
         IntermediateResponse messages.

b) IntermediateResponseメッセージを使用する1つ以上のコントロールが要求にIntermediateResponseメッセージを使用するLDAP拡大手術で含まれています。

   A request control that defines the return of multiple kinds of
   IntermediateResponse messages MUST provide and document a mechanism
   for the client to distinguish the kind of IntermediateResponse
   message being sent.  This SHALL be accomplished by using different
   responseName values for each type of IntermediateResponse message
   associated with the request control or by including identifying
   information in the responseValue of each type of IntermediateResponse
   message associated with the request control.

クライアントが送られるIntermediateResponseメッセージの種類を区別するように、複数の種類のIntermediateResponseメッセージの復帰を定義する要求コントロールは、メカニズムを提供して、記録しなければなりません。 要求コントロールに関連しているIntermediateResponseメッセージの各タイプに異なったresponseName値を使用することによって達成されるか、または包含することによってそれぞれのresponseValueの情報を特定するとタイプされるIntermediateResponseメッセージのこのSHALLは要求コントロールと交際しました。

4.  Advertising Support for IntermediateResponse Messages

4. IntermediateResponseメッセージの広告サポート

   Because IntermediateResponse messages are associated with extended
   operations or controls and LDAP provides a means for advertising the
   extended operations and controls supported by a server (using the
   supportedExtension ([RFC2252] Section 5.2.3) and supportedControl
   ([RFC2252] Section 5.2.4) attributes of the root DSE), there is no
   need for a separate means of advertising support for intermediate
   response messages.

IntermediateResponseメッセージが拡大手術かコントロールに関連していて、LDAPがサーバ(根のDSEのsupportedExtension([RFC2252]セクション5.2.3)とsupportedControl([RFC2252]セクション5.2.4)属性を使用する)で後押しされている拡大手術とコントロールを広告のための手段に提供するので、中間的応答メッセージの広告サポートの別々の手段の必要は全くありません。

5.  Use of IntermediateResponse and ExtendedResponse with Search

5. 検索とのIntermediateResponseとExtendedResponseの使用

   It is noted that ExtendedResponse messages may be sent in response to
   LDAP search operations with controls ([RFC2251] Section 4.5.2).  This
   use of ExtendedResponse messages SHOULD be viewed as deprecated, in
   favor of use of the IntermediateResponse messages.

ExtendedResponseメッセージがコントロール([RFC2251]セクション4.5.2)によるLDAP索敵行動に対応して送られるかもしれないことに注意されます。 ExtendedResponseメッセージSHOULDのこの使用は、推奨しないとして見なされて、IntermediateResponseの使用を支持して通信します。

Harrison & Zeilenga         Standards Track                     [Page 5]

RFC 3771               LDAP Intermediate Response             April 2004

ハリソンとZeilenga規格は中間的LDAP応答2004年4月にRFC3771を追跡します[5ページ]。

6.  Security Considerations

6. セキュリティ問題

   This document describes an enhancement to LDAP.  All security
   considerations of [RFC3377] apply to this document; however, it does
   not introduce any new security considerations to LDAP.

このドキュメントは増進についてLDAPに説明します。 [RFC3377]のすべてのセキュリティ問題がこのドキュメントに適用されます。 しかしながら、それはどんな新しいセキュリティ問題もLDAPに紹介しません。

   Security considerations specific to each extension using this
   protocol mechanism shall be discussed in the technical specification
   detailing the extension.

拡大を詳しく述べる技術仕様書でこのプロトコルメカニズムを使用する各拡大に特定のセキュリティ問題について議論するものとします。

7.  IANA Considerations

7. IANA問題

   Registration of the following value has been completed [RFC3383].

以下の価値の登録は終了しました[RFC3383]。

7.1.  LDAP Message Type

7.1. LDAPメッセージタイプ

   The IANA has registered an LDAP Message Type (25) to identify the
   LDAP IntermediateResponse message as defined in section 3 of this
   document.

IANAは、LDAP IntermediateResponseメッセージを特定するためにこのドキュメントのセクション3で定義されるようにLDAP Message Type(25)を登録しました。

   The following registration template is suggested:

以下の登録テンプレートは示されます:

   Subject: Request for LDAP Message Type Registration
   Person & email address to contact for further information:
      Roger Harrison <roger_harrison@novell.com>
      Specification: RFC3771
      Author/Change Controller: IESG
      Comments: Identifies the LDAP IntermediateResponse Message

Subject: 詳細のために連絡するLDAP Message Type Registration PersonとEメールアドレスのために以下を要求してください。 ロジャー Harrison <roger_harrison@novell.com 、gt;、仕様: RFC3771はコントローラを書くか、または変えます: IESGはコメントします: LDAP IntermediateResponseメッセージを特定します。

8.  Acknowledgments

8. 承認

   The authors would like to acknowledge the members of the IETF LDAP
   Extensions (ldapext) working group mail list who responded to the
   suggestion that a multiple-response paradigm might be useful for LDAP
   extended requests.  Special thanks to two individuals: David Wilbur
   who first introduced the idea on the working group list, and Thomas
   Salter, who succinctly summarized the group's discussion.

作者は、複数の応答パラダイムがLDAPの役に立つかもしれないという提案に応じたIETF LDAP Extensions(ldapext)ワーキンググループメール・リストのメンバーが要求を広げたと認めたがっています。 2人の個人への特別な感謝: 最初にワーキンググループリストで考えを紹介したデヴィッド・ウィルバー、およびトーマスSalter。(そのSalterは簡潔にグループの議論をまとめました)。

9.  References

9. 参照

9.1.  Normative References

9.1. 引用規格

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

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

   [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月。

Harrison & Zeilenga         Standards Track                     [Page 6]

RFC 3771               LDAP Intermediate Response             April 2004

ハリソンとZeilenga規格は中間的LDAP応答2004年4月にRFC3771を追跡します[6ページ]。

   [RFC2252]  Wahl, M., Coulbeck, A., Howes, T. and S.  Kille,
              "Lightweight Directory Access Protocol (v3): Attribute
              Syntax Definitions", RFC 2252, December 1997.

[RFC2252] ウォール、M.、Coulbeck、A.、ハウズ、T.、およびS.Kille、「軽量のディレクトリアクセスは(v3)について議定書の中で述べます」。 「属性構文定義」、RFC2252、1997年12月。

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

[RFC3377] ホッジズ、J.、およびR.モーガン、「軽量のディレクトリアクセスは(v3)について議定書の中で述べます」。 「技術的な仕様」、RFC3377、2002年9月。

   [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月。

9.2.  Informative References

9.2. 有益な参照

   [ZEILENGA] Zeilenga, K., "LDAP Content Synchronization Operation",
              Work in Progress, February 2004.

K.、「LDAPの満足している同期操作」という[ZEILENGA]Zeilengaは進歩、2004年2月に働いています。

10.  Authors' Addresses

10. 作者のアドレス

   Roger Harrison
   Novell, Inc.
   1800 S. Novell Place
   Provo, UT 84606

ロジャーハリソンノベルInc.1800秒間ノベルPlaceプロボ(ユタ)84606

   Phone: +1 801 861 2642
   EMail: roger_harrison@novell.com

以下に電話をしてください。 +1 2642年の801 861メール: roger_harrison@novell.com

   Kurt D. Zeilenga
   OpenLDAP Foundation

カートD.Zeilenga OpenLDAP財団

   EMail: Kurt@OpenLDAP.org

メール: Kurt@OpenLDAP.org

Harrison & Zeilenga         Standards Track                     [Page 7]

RFC 3771               LDAP Intermediate Response             April 2004

ハリソンとZeilenga規格は中間的LDAP応答2004年4月にRFC3771を追跡します[7ページ]。

11.  Full Copyright Statement

11. 完全な著作権宣言文

   Copyright (C) The Internet Society (2004).  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.

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

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

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

Intellectual Property

知的所有権

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

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

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

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

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

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

Acknowledgement

承認

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

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

Harrison & Zeilenga         Standards Track                     [Page 8]

ハリソンとZeilenga標準化過程[8ページ]