Network Working Group K. Zeilenga, Ed.
Request for Comments: 4505 OpenLDAP Foundation
Obsoletes: 2245 June 2006
Category: Standards Track
Anonymous Simple Authentication and Security Layer (SASL) Mechanism
匿名簡易認証セキュリティー層（SASL）メカニズム
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 (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
On the Internet, it is common practice to permit anonymous access to various services. Traditionally, this has been done with a plain-text password mechanism using "anonymous" as the user name and using optional trace information, such as an email address, as the password. As plain-text login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the Simple Authentication and Security Layer (SASL) framework.
インターネットでは、さまざまなサービスへの匿名アクセスを許可するのが一般的です。伝統的に、これはパスワードとして、電子メールアドレスなど、ユーザー名として「匿名」を使用して、オプションのトレース情報を使用して、プレーンテキストのパスワードメカニズムで行われています。プレーンテキストログインコマンドが新しいIETFプロトコルでは許可されていないため、匿名ログインを提供するための新しい方法は、簡易認証セキュリティー層（SASL）フレームワークのコンテキスト内で必要とされています。
This document defines an anonymous mechanism for the Simple Authentication and Security Layer ([SASL]) framework. The name associated with this mechanism is "ANONYMOUS".
この文書では、簡易認証セキュリティー層（[SASL]）フレームワークのための匿名のメカニズムを定義します。このメカニズムに関連付けられている名前は、「匿名」です。
Unlike many other SASL mechanisms, whose purpose is to authenticate and identify the user to a server, the purpose of this SASL mechanism is to allow the user to gain access to services or resources without requiring the user to establish or otherwise disclose their identity to the server. That is, this mechanism provides an anonymous login method.
その目的は、サーバーにユーザーを認証し、特定することである他の多くのSASLメカニズムとは異なり、このSASLメカニズムの目的は、ユーザが確立するユーザーを必要とせずに、サービスやリソースへのアクセスを得るか、そうでない場合に自分のアイデンティティを公開できるようにすることですサーバ。つまり、このメカニズムは、匿名のログイン方法を提供するものです。
This mechanism does not provide a security layer.
このメカニズムはセキュリティレイヤを提供していません。
This document replaces RFC 2245. Changes since RFC 2245 are detailed in Appendix A.
RFC 2245は、付録Aに詳述されているので、この文書は、RFC 2245の変更を置き換えます
The mechanism consists of a single message from the client to the server. The client may include in this message trace information in the form of a string of [UTF-8]-encoded [Unicode] characters prepared in accordance with [StringPrep] and the "trace" stringprep profile defined in Section 3 of this document. The trace information, which has no semantical value, should take one of two forms: an Internet email address, or an opaque string that does not contain the '@' (U+0040) character and that can be interpreted by the system administrator of the client's domain. For privacy reasons, an Internet email address or other information identifying the user should only be used with permission from the user.
メカニズムは、クライアントからサーバへの単一のメッセージで構成されています。クライアントは、[UTF-8]の文字列の形式で、このメッセージトレース情報に含めることができる[STRINGPREP]に従って、このドキュメントのセクション3で定義された「トレース」文字列準備プロフィールで調製[UNICODE]文字でエンコード。インターネット電子メールアドレス、または「@」（U + 0040）文字が含まれていないと、それは、システム管理者によって解釈できる不透明な文字列：何の意味的な価値を持っていないトレース情報は、二つの形式の一つ取る必要がありますクライアントのドメイン。プライバシー上の理由から、インターネットの電子メールアドレスまたはユーザーを特定するその他の情報は、ユーザーからの許可を得て使用する必要があります。
A server that permits anonymous access will announce support for the ANONYMOUS mechanism and allow anyone to log in using that mechanism, usually with restricted access.
匿名アクセスを許可するサーバーは、ANONYMOUSメカニズムのサポートを発表し、誰もが、通常はアクセス制限で、そのメカニズムを使用してログインできるようになります。
A formal grammar for the client message using Augmented BNF [ABNF] is provided below as a tool for understanding this technical specification.
増補BNF [ABNF]を使用して、クライアントメッセージの形式文法は、この技術仕様を理解するためのツールとして、以下に提供されます。
message = [ email / token ] ;; to be prepared in accordance with Section 3
メッセージ= [メール/トークン] ;;第3節に従って作成します
UTF1 = %x00-3F / %x41-7F ;; less '@' (U+0040) UTF2 = %xC2-DF UTF0 UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) / %xED %x80-9F UTF0 / %xEE-EF 2(UTF0) UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) / %xF4 %x80-8F 2(UTF0) UTF0 = %x80-BF
UTF1 =％x00-3F /％x41-7F ;;以下 '@'（U + 0040）UTF2 =％XC2-DF UTF0 UTF3 =％xE0％XA0-BF UTF0 /％XE1-EC 2（UTF0）/％XED％x80-9F UTF0 /％XEE-EF 2（UTF0 ）UTF4 =％XF0％X90-BF 2（UTF0）/％XF1-F3 3（UTF0）/％XF4％x80-8F 2（UTF0）UTF0 =％X80-BF
TCHAR = UTF1 / UTF2 / UTF3 / UTF4 ;; any UTF-8 encoded Unicode character ;; except '@' (U+0040)
TCHAR = UTF1 / UTF2 / UTF3 / UTF4 ;;任意のUTF-8は、Unicode文字をエンコード;; '@'（U + 0040）を除きます
email = addr-spec ;; as defined in [IMAIL]
メール= addrはスペック;; [IMAIL]で定義されるように
token = 1*255TCHAR
トークン= 1 * 255TCHAR
Note to implementors: The <token> production is restricted to 255 UTF-8-encoded Unicode characters. As the encoding of a characters uses a sequence of 1 to 4 octets, a token may be as long as 1020 octets.
実装者への注意：<トークン>生産は255 UTF-8でエンコードされたUnicode文字に制限されています。文字の符号化は1〜4オクテットのシーケンスを使用するように、トークン1020オクテットと同じくらいの長さであってよいです。
This section defines the "trace" profile of [StringPrep]. This profile is designed for use with the SASL ANONYMOUS Mechanism. Specifically, the client is to prepare the <message> production in accordance with this profile.
このセクションでは、[STRINGPREP]の「トレース」のプロファイルを定義します。このプロファイルは、SASL ANONYMOUSメカニズムを使用するように設計されています。具体的には、クライアントは、このプロファイルに従って<メッセージ>生産を調製することです。
The character repertoire of this profile is Unicode 3.2 [Unicode].
このプロファイルの文字レパートリは、Unicode 3.2 [UNICODE]です。
No mapping is required by this profile.
マッピングは、このプロファイルで必要とされません。
No Unicode normalization is required by this profile.
いいえUnicode正規化は、このプロファイルで必要とされません。
The list of unassigned code points for this profile is that provided in Appendix A of [StringPrep]. Unassigned code points are not prohibited.
このプロファイルのために割り当てられていないコードポイントのリストが[STRINGPREP]の付録Aに設けられていることです。未割り当てコードポイントが禁止されていません。
Characters from the following tables of [StringPrep] are prohibited:
[STRINGPREP]の以下の表から文字が禁止されています：
- C.2.1 (ASCII control characters) - C.2.2 (Non-ASCII control characters) - C.3 (Private use characters) - C.4 (Non-character code points) - C.5 (Surrogate codes) - C.6 (Inappropriate for plain text) - C.8 (Change display properties are deprecated) - C.9 (Tagging characters)
- C.2.1（ASCII制御文字） - C.2.2（非ASCII制御文字） - C.3（プライベート利用文字） - C.4（非文字コードポイント） - C.5（サロゲートコード） - C 0.6（プレーンテキストとして不適切） - C.8（表示プロパティの変更は推奨されません） - C.9（タグ付け文字）
No additional characters are prohibited.
追加の文字は禁止されていません。
This profile requires bidirectional character checking per Section 6 of [StringPrep].
このプロファイルは、[STRINGPREP]のセクション6ごとにチェック双方向文字が必要です。
Here is a sample ANONYMOUS login between an IMAP client and server. In this example, "C:" and "S:" indicate lines sent by the client and server, respectively. If such lines are wrapped without a new "C:" or "S:" label, then the wrapping is for editorial clarity and is not part of the command.
ここではIMAPクライアントとサーバ間のサンプルANONYMOUSログインがあります。この例では、「C：」と「S：」はそれぞれ、クライアントとサーバから送られた行を示しています。 「C：」、そのような行が新しいずに包まれている場合、または「S：」ラベル、その後、ラッピングは編集上明確にするためであり、コマンドの一部ではありません。
Note that this example uses the IMAP profile [IMAP4] of SASL. The base64 encoding of challenges and responses as well as the "+ " preceding the responses are part of the IMAP4 profile, not part of SASL itself. Additionally, protocols with SASL profiles permitting an initial client response will be able to avoid the extra round trip below (the server response with an empty "+ ").
この例では、SASLのIMAPプロファイル[IMAP4]を使用することに注意してください。応答の前チャレンジとレスポンスのbase64エンコーディングならびに「+」は、IMAP4プロファイルではなく、SASL自身の部分の一部です。また、初期のクライアント応答を許可するSASLプロファイルを持つプロトコルは、以下の余分なラウンドトリップ（「+」空とサーバの応答を）避けることができるようになります。
In this example, the trace information is "sirhc".
この例では、トレース情報は、「sirhc」です。
S: * OK IMAP4 server ready C: A001 CAPABILITY S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=DIGEST-MD5 AUTH=ANONYMOUS S: A001 OK done C: A002 AUTHENTICATE ANONYMOUS S: + C: c2lyaGM= S: A003 OK Welcome, trace information has been logged.
S：* OK IMAP4サーバ準備C：A001能力Sを：* CAPABILITY IMAP4のIMAP4rev1 AUTH = DIGEST-MD5 AUTH = ANONYMOUS S：A002 AUTHENTICATE ANONYMOUS S：OK CをやっA001 + C：c2lyaGM = S：A003ようこそOK、トレース情報をログに記録されています。
The ANONYMOUS mechanism grants access to services and/or resources by anyone. For this reason, it should be disabled by default so that the administrator can make an explicit decision to enable it.
ANONYMOUSメカニズムは誰でも、サービスおよび/またはリソースへのアクセスを許可します。管理者がそれを可能にするために、明示的な意思決定を行うことができるように、このような理由から、それはデフォルトでは無効にする必要があります。
If the anonymous user has any write privileges, a denial-of-service attack is possible by filling up all available space. This can be prevented by disabling all write access by anonymous users.
匿名ユーザーが任意の書き込み権限を持っている場合は、サービス拒否攻撃は、すべての利用可能なスペースを埋めることにより可能です。これは匿名ユーザーによるすべての書き込みアクセスを無効にすることで防ぐことができます。
If anonymous users have read and write access to the same area, the server can be used as a communication mechanism to exchange information anonymously. Servers that accept anonymous submissions should implement the common "drop box" model, which forbids anonymous read access to the area where anonymous submissions are accepted.
匿名ユーザーが読み取りと同じ領域への書き込みアクセスをしている場合、サーバは匿名で情報を交換するための通信メカニズムとして使用することができます。匿名の投稿を受け付けるサーバーは、匿名の投稿を受け付けていた領域への匿名読み取りアクセスを禁止し、共通の「ドロップボックス」モデルを、実装する必要があります。
If the anonymous user can run many expensive operations (e.g., an IMAP SEARCH BODY command), this could enable a denial-of-service attack. Servers are encouraged to reduce the priority of anonymous users or limit their resource usage.
匿名ユーザーが多く、高価な操作（例えば、IMAP検索BODYコマンド）を実行できる場合、これは、サービス拒否攻撃を可能にすることができます。サーバーは、匿名ユーザーの優先順位を下げるか、そのリソース使用量を制限することをお勧めします。
While servers may impose a limit on the number of anonymous users, note that such limits enable denial-of-service attacks and should be used with caution.
サーバーは、匿名ユーザーの数に制限を課すことができるが、このような制限は、サービス拒否攻撃を可能にし、注意して使用する必要があることに注意してください。
The trace information is not authenticated, so it can be falsified. This can be used as an attempt to get someone else in trouble for access to questionable information. Administrators investigating abuse need to realize that this trace information may be falsified.
トレース情報が認証されていないので、それを偽造することができます。これは疑わしい情報へのアクセスのためのトラブルで他の誰かを取得しようとして使用することができます。虐待を調査し、管理者は、このトレース情報が改ざんされることを認識する必要があります。
A client that uses the user's correct email address as trace information without explicit permission may violate that user's privacy. Anyone who accesses an anonymous archive on a sensitive subject (e.g., sexual abuse) likely has strong privacy needs. Clients should not send the email address without the explicit permission of the user and should offer the option of supplying no trace information, thus only exposing the source IP address and time.
明示的な許可なしにトレース情報として、ユーザーの正しいメールアドレスを使用するクライアントは、そのユーザーのプライバシーを侵害することがあります。敏感な主題上の匿名のアーカイブにアクセスする誰でも（例えば、性的虐待は）可能性が強いプライバシーのニーズを持っています。クライアントは、ユーザの明示的な許可なしに電子メールアドレスを送信するべきではありませんので、唯一のソースIPアドレスと時間を露出し、トレース情報を提供しないという選択肢を提供する必要があります。
Anonymous proxy servers could enhance this privacy but would have to consider the resulting potential denial-of-service attacks.
匿名プロキシサーバは、このプライバシーを高めることができるが、得られる潜在的なサービス拒否攻撃を検討する必要があります。
Anonymous connections are susceptible to man-in-the-middle attacks that view or alter the data transferred. Clients and servers are encouraged to support external data security services.
匿名接続が転送されたデータを表示または変更するman-in-the-middle攻撃を受けやすいです。クライアントとサーバーは、外部のデータ・セキュリティ・サービスをサポートすることをお勧めします。
Protocols that fail to require an explicit anonymous login are more susceptible to break-ins given certain common implementation techniques. Specifically, Unix servers that offer user login may initially start up as root and switch to the appropriate user id after an explicit login command. Normally, such servers refuse all data access commands prior to explicit login and may enter a restricted security environment (e.g., the Unix chroot(2) function) for anonymous users. If anonymous access is not explicitly requested, the entire data access machinery is exposed to external security attacks without the chance for explicit protective measures. Protocols that offer restricted data access should not allow anonymous data access without an explicit login step.
明示的な匿名ログインを必要としないプロトコルは、特定の一般的な実装技術与えられたインを破ることがより影響を受けやすいです。具体的には、ユーザーログインを提供するUnixサーバは、最初にルートとして起動し、明示的なログインコマンドの後に、適切なユーザーIDに切り替えることができます。通常、そのようなサーバは、前の明示的なログインにすべてのデータアクセスコマンドを拒否し、匿名ユーザーのために制限されたセキュリティ環境（例えば、Unixのはchroot（2）関数）を入力することもできます。匿名アクセスを明示的に要求されていない場合は、全体のデータアクセスの機械は、明示的な保護対策のためのチャンスなしで外部のセキュリティ攻撃にさらされています。制限されたデータへのアクセスを提供するプロトコルは、明示的なログイン手順なしの匿名データアクセスを許可してはいけません。
General [SASL] security considerations apply to this mechanism.
一般的な[SASL]セキュリティ上の考慮事項は、この機構に適用されます。
[StringPrep] security considerations and [Unicode] security considerations discussed in [StringPrep] apply to this mechanism. [UTF-8] security considerations also apply.
【STRINGPREP]で議論[STRINGPREP】セキュリティ問題と[UNICODE]セキュリティ問題は、この機構に適用します。 [UTF-8]セキュリティ上の考慮事項にも適用されます。
The SASL Mechanism registry [IANA-SASL] entry for the ANONYMOUS mechanism has been updated by the IANA to reflect that this document now provides its technical specification.
ANONYMOUSメカニズムのSASLメカニズムのレジストリ[IANA-SASL]のエントリは、この文書は、現在その技術仕様を提供していることを反映するためにIANAによって更新されました。
To: iana@iana.org Subject: Updated Registration of SASL mechanism ANONYMOUS
To：iana@iana.org件名：SASLメカニズムANONYMOUSの更新登録
SASL mechanism name: ANONYMOUS Security considerations: See RFC 4505. Published specification (optional, recommended): RFC 4505 Person & email address to contact for further information: Kurt Zeilenga <Kurt@OpenLDAP.org> Chris Newman <Chris.Newman@sun.com> Intended usage: COMMON Author/Change controller: IESG <iesg@ietf.org> Note: Updates existing entry for ANONYMOUS
SASLメカニズム名：ANONYMOUSのセキュリティの考慮事項：RFC 4505公開された仕様（オプション、推奨）を参照してください：RFC 4505人とEメールアドレスを詳細のために連絡する：クルトZeilenga <Kurt@OpenLDAP.org>クリス・ニューマン<Chris.Newman@sun。コム>意図している用法：COMMON著者/変更コントローラ：IESG <iesg@ietf.org>注：ANONYMOUSのアップデート既存のエントリ
The [StringPrep] profile "trace", first defined in this RFC, has been registered:
最初に、このRFCで定義されている[STRINGPREP]プロファイル「トレース」は、登録されています：
To: iana@iana.org Subject: Initial Registration of Stringprep "trace" profile
iana@iana.org件名：：への初期登録のstringprepの「痕跡」のプロフィール
Stringprep profile: trace Published specification: RFC 4505 Person & email address to contact for further information: Kurt Zeilenga <kurt@openldap.org>
文字列準備プロフィール：公開された仕様をトレース：RFC 4505人とEメールアドレスを詳細のために連絡する：クルトZeilenga <kurt@openldap.org>
This document is a revision of RFC 2245 by Chris Newman. Portions of the grammar defined in Section 1 were borrowed from RFC 3629 by Francois Yergeau.
この文書では、クリス・ニューマンによってRFC 2245の改訂版です。セクション1に定義された文法の部分は、フランソワYergeauによってRFC 3629から借用しました。
This document is a product of the IETF SASL WG.
この文書は、IETF SASL WGの製品です。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[ABNF]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。
[IMAIL] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[IMAIL]レズニック、P.、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[SASL] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[SASL]メルニコフ、A.編。そして、K. Zeilenga、エド。、 "簡易認証セキュリティー層（SASL）"、RFC 4422、2006年6月。
[StringPrep] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ('stringprep')", RFC 3454, December 2002.
【STRINGPREP]ホフマン、P.及びM.ブランシェ、 "国際化された文字列の調製（ '文字列準備'）"、RFC 3454、2002年12月。
[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標準は、バージョン3.2.0" は、 "Unicode規格、バージョン3.0"（読書、MA、アディソン・ウェズリー、2000 ISBN 0-201-61633-5）などによって定義されます改正 "Unicode標準の附属書＃27：ユニコード3.1"（http://www.unicode.org/reports/tr27/）とで "Unicode標準の附属書＃28：Unicodeの3.2"（のhttp：//www.unicode .ORG /レポート/ TR28 /）。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629 (also STD 63), November 2003.
[UTF-8] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、RFC 3629（また、STD 63）2003年11月。
[IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP4]クリスピン、M.、 "インターネットメッセージアクセスプロトコル - バージョン4rev1"、RFC 3501、2003年3月。
[IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) MECHANISMS", <http://www.iana.org/assignments/sasl-mechanisms>.
[IANA-SASL] IANA、 "簡易認証セキュリティー層（SASL）メカニズム"、<http://www.iana.org/assignments/sasl-mechanisms>。
Appendix A. Changes since
付録A.からの変更点
This appendix is non-normative.
この付録は非規範的です。
RFC 2245 allows the client to include optional trace information in the form of a human readable string. RFC 2245 restricted this string to US-ASCII. As the Internet is international, this document uses a string restricted to UTF-8 encoded Unicode characters. A "stringprep" profile is defined to precisely define which Unicode characters are allowed in this string. While the string remains restricted to 255 characters, the encoded length of each character may now range from 1 to 4 octets.
RFC 2245は、クライアントが人間が読める文字列の形式で、オプションのトレース情報を含めることができます。 RFC 2245には、US-ASCIIにこの文字列を制限しました。インターネットは国際的であるように、この文書はUTF-8でエンコードされたUnicode文字に制限された文字列を使用しています。 「文字列前」プロファイルは正確にUnicode文字がこの文字列で許可されるかを定義するために定義されています。文字列が255文字に制限されたままで、各文字のエンコードされた長さは、今1から4つのオクテットの範囲であってよいです。
Additionally, a number of editorial changes were made.
また、編集上の変更の数が行われました。
Editor's Address
編集者の住所
Kurt D. Zeilenga OpenLDAP Foundation
クルトD. ZeilengaのOpenLDAP財団
EMail: Kurt@OpenLDAP.org
メールアドレス：Kurt@OpenLDAP.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（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.
この文書では、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.
この文書とここに含まれている情報は、基礎と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 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.
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 provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。