RFC4532 日本語訳

Network Working Group                                        K. Zeilenga
Request for Comments: 4532                           OpenLDAP Foundation
Category: Standards Track                                      June 2006

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

              Lightweight Directory Access Protocol (LDAP)
                         "Who am I?" Operation

「Iですか?」ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP) 操作

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.

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

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(2006)。

Abstract

要約

   This specification provides a mechanism for Lightweight Directory
   Access Protocol (LDAP) clients to obtain the authorization identity
   the server has associated with the user or application entity.  This
   mechanism is specified as an LDAP extended operation called the LDAP
   "Who am I?" operation.

ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)クライアントがサーバがユーザかアプリケーション実体に関連づけた承認のアイデンティティを得るように、この仕様はメカニズムを提供します。 LDAP拡大手術が、LDAPを「私はだれですか?」という操作と呼んだので、このメカニズムは指定されます。

1.  Background and Intent of Use

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

   This specification describes a Lightweight Directory Access Protocol
   (LDAP) [RFC4510] operation that clients can use to obtain the primary
   authorization identity, in its primary form, that the server has
   associated with the user or application entity.  The operation is
   called the "Who am I?" operation.

この仕様はクライアントがプライマリフォームでのサーバが持っているユーザかアプリケーション実体に関連しているプライマリ承認のアイデンティティを得るのに使用できるライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)[RFC4510]操作について説明します。 操作は「私はだれですか?」操作と呼ばれます。

   This specification is intended to replace the existing Authorization
   Identity Controls [RFC3829] mechanism, which uses Bind request and
   response controls to request and return the authorization identity.
   Bind controls are not protected by security layers established by the
   Bind operation that includes them.  While it is possible to establish
   security layers using StartTLS [RFC4511][RFC4513] prior to the Bind
   operation, it is often desirable to use security layers established
   by the Bind operation.  An extended operation sent after a Bind
   operation is protected by the security layers established by the Bind
   operation.

この仕様は既存のAuthorization Identity Controls[RFC3829]メカニズムを置き換えるつもりです。(メカニズムは、承認のアイデンティティを要求して、返すのにBind要求と応答制御を使用します)。 ひものコントロールはそれらを含んでいるBind操作で確立されたセキュリティ層によって保護されません。 セキュリティ層を確立するのがBind操作の前にStartTLS[RFC4511][RFC4513]を使用することで可能ですが、Bind操作で確立されたセキュリティ層を使用するのはしばしば望ましいです。 Bind操作がBind操作で確立されたセキュリティ層によって保護された後に拡大手術は発信しました。

Zeilenga                    Standards Track                     [Page 1]

RFC 4532               LDAP "Who am I?" Operation              June 2006

「Iですか?」Zeilenga Standards Track[1ページ]RFC4532LDAP 操作2006年6月

   There are other cases where it is desirable to request the
   authorization identity that the server associated with the client
   separately from the Bind operation.  For example, the "Who am I?"
   operation can be augmented with a Proxied Authorization Control
   [RFC4370] to determine the authorization identity that the server
   associates with the identity asserted in the Proxied Authorization
   Control.  The "Who am I?" operation can also be used prior to the
   Bind operation.

他のケースがサーバが別々にBind操作からクライアントと交際したのが、承認のアイデンティティを要求するのにおいて望ましいところにあります。 例えば、「私はだれですか?」操作は、アイデンティティのサーバ関連がProxied Authorization Controlで断言した承認のアイデンティティを決定するためにProxied Authorization Control[RFC4370]と共に増大できます。 また、Bind操作の前に「私はだれですか?」操作を使用できます。

   Servers often associate multiple authorization identities with the
   client, and each authorization identity may be represented by
   multiple authzId [RFC4513] strings.  This operation requests and
   returns the authzId that the server considers primary.  In the
   specification, the term "the authorization identity" and "the
   authzId" are generally to be read as "the primary authorization
   identity" and the "the primary authzId", respectively.

サーバはしばしば複数の承認のアイデンティティをクライアントに関連づけます、そして、それぞれの承認のアイデンティティは複数のauthzId[RFC4513]ストリングによって表されるかもしれません。 この操作は、サーバがプライマリであると考えるauthzIdを要求して、返します。 そして、「承認のアイデンティティ」という用語と「authzId」による一般に、仕様では、「プライマリ承認のアイデンティティ」としての読書であることになっている、それぞれ「プライマリauthzId。」

1.1.  Conventions Used in This Document

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

   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.  The "Who am I?" Operation

2. 「私はだれですか?」 操作

   The "Who am I?" operation is defined as an LDAP Extended Operation
   [RFC4511] identified by the whoamiOID Object Identifier (OID).  This
   section details the syntax of the operation's whoami request and
   response messages.

「私はだれですか?」操作はwhoamiOID Object Identifier(OID)によって特定されたLDAP Extended Operation[RFC4511]と定義されます。 このセクションは操作のwhoami要求と応答メッセージの構文を詳しく述べます。

      whoamiOID ::= "1.3.6.1.4.1.4203.1.11.3"

whoamiOID:、:= "1.3.6.1.4.1.4203.1.11.3"

2.1.  The whoami Request

2.1. whoami Request

   The whoami request is an ExtendedRequest with a requestName field
   containing the whoamiOID OID and an absent requestValue field.  For
   example, a whoami request could be encoded as the sequence of octets
   (in hex):

whoami要求はrequestName分野がwhoamiOID OIDと欠けているrequestValue分野を含んでいるExtendedRequestです。 例えば、八重奏(十六進法における)の系列としてwhoami要求をコード化できました:

      30 1e 02 01 02 77 19 80  17 31 2e 33 2e 36 2e 31
      2e 34 2e 31 2e 34 32 30  33 2e 31 2e 31 31 2e 33

30 1e02 01 02 77 19 80 17 31 2e33 2e36 2e31 2e34 2e31 2e34 32 30 33 2e31 2e31 31 2e33

Zeilenga                    Standards Track                     [Page 2]

RFC 4532               LDAP "Who am I?" Operation              June 2006

「Iですか?」Zeilenga Standards Track[2ページ]RFC4532LDAP 操作2006年6月

2.2.  The whoami Response

2.2. whoami Response

   The whoami response is an ExtendedResponse where the responseName
   field is absent and the response field, if present, is empty or an
   authzId [RFC4513].  For example, a whoami response returning the
   authzId "u:xxyyz@EXAMPLE.NET" (in response to the example request)
   would be encoded as the sequence of octets (in hex):

whoami応答は、responseName分野が欠けていて、存在しているなら応答分野が人影がないExtendedResponseかauthzId[RFC4513]です。 例えば、「u: xxyyz@EXAMPLE.NET 」(例の要求に対応した)をauthzIdに返すwhoami応答は八重奏(十六進法における)の系列としてコード化されるでしょう:

      30 21 02 01 02 78 1c 0a  01 00 04 00 04 00 8b 13
      75 3a 78 78 79 79 7a 40  45 58 41 4d 50 4c 45 2e
      4e 45 54

30 21 02 01 02 78 1c 0a01 00 04 00 04 00 8b13 75 3a78 78 79 79 7a40 45 58 41 4d50 4c45 2e 4e45 54

3.  Operational Semantics

3. 操作上の意味論

   The "Who am I?" operation provides a mechanism, a whoami Request, for
   the client to request that the server return the authorization
   identity it currently associates with the client.  It also provides a
   mechanism, a whoami Response, for the server to respond to that
   request.

「私はだれですか?」操作はメカニズムを提供します、whoami Request、サーバがそれが現在クライアントに関連づける承認のアイデンティティを返すよう要求するクライアントのために。 また、それは、サーバがその要求に応じるようにメカニズム、whoami Responseを提供します。

   Servers indicate their support for this extended operation by
   providing a whoamiOID object identifier as a value of the
   'supportedExtension' attribute type in their root DSE.  The server
   SHOULD advertise this extension only when the client is willing and
   able to perform this operation.

サーバは、それらの根のDSEの'supportedExtension'属性タイプの値としてwhoamiOIDオブジェクト識別子を提供することによって、彼らのこの拡大手術のサポートを示します。 クライアントが望んでいてこの操作を実行できるときだけ、サーバSHOULDはこの拡大の広告を出します。

   If the server is willing and able to provide the authorization
   identity it associates with the client, the server SHALL return a
   whoami Response with a success resultCode.  If the server is treating
   the client as an anonymous entity, the response field is present but
   empty.  Otherwise, the server provides the authzId [RFC4513]
   representing the authorization identity it currently associates with
   the client in the response field.

サーバが望んでいてそれが関連づける承認のアイデンティティにクライアントを提供できるなら、サーバSHALLは成功resultCodeとwhoami Responseを返します。 サーバが匿名の実体としてクライアントを扱っているなら、応答分野は、現在ですが、人影がありません。 さもなければ、サーバは、それが現在応答分野のクライアントに関連づける承認のアイデンティティを表しながら、authzId[RFC4513]を提供します。

   If the server is unwilling or unable to provide the authorization
   identity it associates with the client, the server SHALL return a
   whoami Response with an appropriate non-success resultCode (such as
   operationsError, protocolError, confidentialityRequired,
   insufficientAccessRights, busy, unavailable, unwillingToPerform, or
   other) and an absent response field.

サーバが不本意であるか、またはそれが関連づける承認のアイデンティティにクライアントを提供できないなら、サーバSHALLは適切な非成功resultCode(operationsError、protocolError、confidentialityRequired、insufficientAccessRights、忙しくて、入手できないunwillingToPerformなどのように何らかの)と欠けている応答分野があるwhoami Responseを返します。

   As described in [RFC4511] and [RFC4513], an LDAP session has an
   "anonymous" association until the client has been successfully
   authenticated using the Bind operation.  Clients MUST NOT invoke the
   "Who am I?" operation while any Bind operation is in progress,
   including between two Bind requests made as part of a multi-stage

[RFC4511]と[RFC4513]で説明されるように、LDAPセッションにはクライアントがBind操作を使用することで首尾よく認証されるまで、「匿名」の協会があります。 どんなBind操作も進行している間、クライアントは「私はだれですか?」操作を呼び出してはいけません、2の間にマルチステージの一部としてされたBind要求を含んでいて

Zeilenga                    Standards Track                     [Page 3]

RFC 4532               LDAP "Who am I?" Operation              June 2006

「Iですか?」Zeilenga Standards Track[3ページ]RFC4532LDAP 操作2006年6月

   Bind operation.  Where a whoami Request is received in violation of
   this absolute prohibition, the server should return a whoami Response
   with an operationsError resultCode.

操作を縛ってください。 whoami Requestがこの絶対禁止を違反して受け取られるところに、サーバはoperationsError resultCodeとwhoami Responseを返すべきです。

4.  Extending the "Who am I?" Operation with Controls

4. 「Iはだれですか?」を広げること。 コントロールとの操作

   Future specifications may extend the "Who am I?" operation using the
   control mechanism [RFC4511].  When extended by controls, the "Who am
   I?" operation requests and returns the authorization identity the
   server associates with the client in a particular context indicated
   by the controls.

将来の仕様は、制御機構[RFC4511]を使用することで「私はだれですか?」操作を広げるかもしれません。 コントロールで広げられると、「私はだれですか?」操作は、特定の文脈のクライアントのサーバ関連がコントロールで示した承認のアイデンティティを要求して、返します。

4.1.  Proxied Authorization Control

4.1. 承認コントロールをProxiedしました。

   The Proxied Authorization Control [RFC4370] is used by clients to
   request that the operation it is attached to operate under the
   authorization of an assumed identity.  The client provides the
   identity to assume in the Proxied Authorization request control.  If
   the client is authorized to assume the requested identity, the server
   executes the operation as if the requested identity had issued the
   operation.

Proxied Authorization Control[RFC4370]は、それが付けられている操作が偽の別人の承認の下で作動するよう要求するのにクライアントによって使用されます。 クライアントはProxied Authorization要求コントロールで仮定するアイデンティティを提供します。 クライアントが要求されたアイデンティティを仮定するのに権限を与えられるなら、まるで要求されたアイデンティティが操作を発行したかのようにサーバは操作を実行します。

   As servers often map the asserted authzId to another identity
   [RFC4513], it is desirable to request that the server provide the
   authzId it associates with the assumed identity.

サーバがしばしば別のアイデンティティ[RFC4513]に断言されたauthzIdを写像するので、サーバがそれが関連づけるauthzIdに偽の別人を提供するよう要求するのは望ましいです。

   When a Proxied Authorization Control is be attached to the "Who am
   I?"  operation, the operation requests the return of the authzId the
   server associates with the identity asserted in the Proxied
   Authorization Control.  The authorizationDenied (123) result code is
   used to indicate that the server does not allow the client to assume
   the asserted identity.

Proxied Authorization Controlがそうであるときには「私はだれですか?」操作に付けられてください、そして、操作はアイデンティティのサーバ関連がProxied Authorization Controlで断言したauthzIdの復帰を要求します。 authorizationDenied(123)結果コードは、クライアントがサーバで断言されたアイデンティティを仮定できないのを示すのに使用されます。

5.  Security Considerations

5. セキュリティ問題

   Identities associated with users may be sensitive information.  When
   they are, security layers [RFC4511][RFC4513] should be established to
   protect this information.  This mechanism is specifically designed to
   allow security layers established by a Bind operation to protect the
   integrity and/or confidentiality of the authorization identity.

ユーザに関連しているアイデンティティは機密情報であるかもしれません。 それらがそうときに、セキュリティ層[RFC4511][RFC4513]は、この情報を保護するために確立されるべきです。 このメカニズムは、Bind操作で確立されたセキュリティ層が承認のアイデンティティの保全、そして/または、秘密性を保護するのを許容するように明確に設計されています。

   Servers may place access control or other restrictions upon the use
   of this operation.  As stated in Section 3, the server SHOULD
   advertise this extension when it is willing and able to perform the
   operation.

サーバはアクセスコントロールか他の制限をこの操作の使用に置くかもしれません。 望んでいて操作を実行できるとき、セクション3に述べられているように、サーバSHOULDはこの拡大の広告を出します。

   As with any other extended operations, general LDAP security
   considerations [RFC4510] apply.

いかなる他の拡大手術のようにも、一般的なLDAPセキュリティ問題[RFC4510]は適用されます。

Zeilenga                    Standards Track                     [Page 4]

RFC 4532               LDAP "Who am I?" Operation              June 2006

「Iですか?」Zeilenga Standards Track[4ページ]RFC4532LDAP 操作2006年6月

6.  IANA Considerations

6. IANA問題

   The OID 1.3.6.1.4.1.4203.1.11.3 is used to identify the LDAP "Who am
   I?" extended operation.  This OID was assigned [ASSIGN] by the
   OpenLDAP Foundation, under its IANA-assigned private enterprise
   allocation [PRIVATE], for use in this specification.

OID、1.3 .6 .1 .4 .1 .4203 .1 .11 .3は「私はだれですか?」というLDAP拡大手術を特定するのにおいて使用されています。 [ASSIGN]はOpenLDAP財団によってこのOIDに割り当てられました、IANAによって割り当てられた私企業配分[兵士]で、この仕様に基づく使用のために。

   Registration of this protocol mechanism [RFC4520] has been completed
   by the IANA.

このプロトコルメカニズム[RFC4520]の登録はIANAによって終了しました。

   Subject: Request for LDAP Protocol Mechanism Registration
   Object Identifier: 1.3.6.1.4.1.4203.1.11.3
   Description: Who am I?
   Person & email address to contact for further information:
        Kurt Zeilenga <kurt@openldap.org>
   Usage: Extended Operation
   Specification: RFC 4532
   Author/Change Controller: IESG
   Comments: none

Subject: LDAPプロトコルメカニズム登録オブジェクト識別子のために以下を要求してください。 1.3.6.1.4.1.4203.1.11.3 記述: 私はだれですか? 詳細のために連絡する人とEメールアドレス: カート Zeilenga <kurt@openldap.org 、gt;、用法: 拡大手術仕様: RFC4532作者/変化コントローラ: IESGはコメントします: なし

7.  Acknowledgement

7. 承認

   This document borrows from prior work in this area, including
   "Authentication Response Control" [RFC3829] by Rob Weltman, Mark
   Smith, and Mark Wahl.

このドキュメントはこの領域での先の仕事から借ります、ロブWeltman、マーク・スミス、およびマーク・ウォールが「認証応答制御」[RFC3829]を含んでいて。

   The LDAP "Who am I?" operation takes it's name from the UNIX
   whoami(1) command.  The whoami(1) command displays the effective user
   ID.

LDAP「私はだれですか?」はUNIX whoami(1)コマンドからの操作が、分かる名前です。 whoami(1)コマンドは実効ユーザーIDを表示します。

8.  References

8. 参照

8.1.  Normative References

8.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月。

   [RFC4370] Weltman, R., "Lightweight Directory Access Protocol (LDAP)
             Proxied Authorization Control", RFC 4370, February 2006.

[RFC4370] Weltman、R.、「ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)Proxied承認コントロール」、RFC4370、2006年2月。

   [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
             (LDAP): Technical Specification Road Map", RFC 4510, June
             2006.

[RFC4510] Zeilenga、K.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「仕様書ロードマップ」、RFC4510、2006年6月。

   [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
             Protocol (LDAP): The Protocol", RFC 4511, June 2006.

[RFC4511] Sermersheim、J.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「プロトコル」、RFC4511、2006年6月。

Zeilenga                    Standards Track                     [Page 5]

RFC 4532               LDAP "Who am I?" Operation              June 2006

「Iですか?」Zeilenga Standards Track[5ページ]RFC4532LDAP 操作2006年6月

   [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol
             (LDAP): Authentication Methods and Security Mechanisms",
             RFC 4513, June 2006.

[RFC4513] ハリソン、R.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「認証方法とセキュリティー対策」、RFC4513、6月2006日

8.2.  Informative References

8.2. 有益な参照

   [RFC3829] Weltman, R., Smith, M., and M. Wahl, "Lightweight Directory
             Access Protocol (LDAP) Authorization Identity Request and
             Response Controls", RFC 3829, July 2004.

[RFC3829] Weltman、R.、スミス、M.、およびM.ウォール、「ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)承認アイデンティティ要求と応答は制御します」、RFC3829、2004年7月。

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

   [ASSIGN]  OpenLDAP Foundation, "OpenLDAP OID Delegations",
             http://www.openldap.org/foundation/oid-delegate.txt.

[割り当てます] OpenLDAP財団、「OpenLDAP OID委譲」、 http://www.openldap.org/foundation/oid-delegate.txt 。

   [PRIVATE] IANA, "Private Enterprise Numbers",
             http://www.iana.org/assignments/enterprise-numbers.

[個人的]のIANA、「私企業番号」、 http://www.iana.org/assignments/enterprise-numbers 。

Author's Address

作者のアドレス

   Kurt D. Zeilenga
   OpenLDAP Foundation

カートD.Zeilenga OpenLDAP財団

   EMail: Kurt@OpenLDAP.org

メール: Kurt@OpenLDAP.org

Zeilenga                    Standards Track                     [Page 6]

RFC 4532               LDAP "Who am I?" Operation              June 2006

「Iですか?」Zeilenga Standards Track[6ページ]RFC4532LDAP 操作2006年6月

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(2006)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントは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 provided by the IETF
   Administrative Support Activity (IASA).

RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Zeilenga                    Standards Track                     [Page 7]

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