Network Working Group D. Eastlake
Request for Comments: 2935 Motorola
Category: Standards Track C. Smith
Royal Bank of Canada
September 2000
Internet Open Trading Protocol (IOTP) HTTP Supplement
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 (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
Internet Open Trading Protocol (IOTP) messages will be carried as Extensible Markup Language (XML) documents. As such, the goal of mapping to the transport layer is to ensure that the underlying XML documents are carried successfully between the various parties.
インターネットオープン取引プロトコル（IOTP）のメッセージはXML（Extensible Markup Language）ドキュメントとして実行されます。そのため、トランスポート層へのマッピングの目標は、基礎となるXML文書は、様々な関係者の間で成功裏に実施されていることを確認することです。
This document describes that mapping for the Hyper Text Transport Protocol (HTTP), Versions 1.0 and 1.1.
この文書では、ハイパーテキスト転送プロトコル（HTTP）、バージョン1.0および1.1のためにそのマッピングを記述する。
Table of Contents
目次
1. Introduction................................................... 2
2. HTTP Servers and Clients....................................... 2
3. HTTP Net Locations............................................. 2
4. Consumer Clients............................................... 2
4.1 Starting the IOTP Client and the Merchant IOTP Server.......... 3
4.2 Ongoing IOTP Messages.......................................... 3
4.3 Stopping an IOTP Transaction................................... 4
5. Starting the Payment handler and Deliverer IOTP Servers........ 5
6. Security Considerations........................................ 5
7. IANA Considerations............................................ 5
8. References..................................................... 6
9. Authors' Addresses............................................. 7
10. Full Copyright Statement....................................... 9
Internet Open Trading Protocol (IOTP) [RFC2801] messages will be carried as XML [XML] documents. As such, the goal of mapping to the transport layer is to ensure that the underlying XML documents are carried successfully between the various parties.
インターネットオープン取引プロトコル（IOTP）[RFC2801]のメッセージはXML [XML]文書として実行されます。そのため、トランスポート層へのマッピングの目標は、基礎となるXML文書は、様々な関係者の間で成功裏に実施されていることを確認することです。
This document describes that mapping for the Hyper Text Transport Protocol (HTTP), Versions 1.0 and 1.1 [RFCs 1945, 2616].
この文書では、ハイパーテキスト転送プロトコル（HTTP）、バージョン1.0および1.1 [RFCの1945、2616]のためにそのマッピングを記述する。
There may be future documents describing IOTP over email (SMTP), TCP, cable TV, or other transports.
今後のメールでIOTPを記載した文書（SMTP）、TCP、ケーブルテレビ、または他のトランスポートがあるかもしれません。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The structure of IOTP maps on to the structure of HTTP in the following way:
IOTPの構造は次のようにHTTPの構造にマップします。
The merchant, payment handler, delivery handler, and customer care roles are all represented by HTTP servers. Each may be represented by a separate server, or they may be combined in any combination.
商人、支払いハンドラ、配信ハンドラ、および顧客ケアの役割は、すべてのHTTPサーバで表現されています。それぞれが別個のサーバによって表すことができる、またはそれらは任意の組み合わせで組み合わせることができます。
The consumer role is represented by an HTTP client.
消費者の役割は、HTTPクライアントによって表されます。
Note: A Merchant, may act in the role of a consumer, for example to deposit electronic cash. In this case the Merchant, as an organization rather than as a role, would need to be supported by an HTTP client.
注意：商人を、電子現金を堆積させるために、たとえば、消費者の役割で作用することができます。この場合、商人は、組織としてではなく、役割として、HTTPクライアントによってサポートされる必要があるだろう。
The Net Locations contained within the IOTP specification are all URIs [RFC 2396]. If a secure connection is required or desired a secure channel that both the HTTP Server and Client support MUST be used. Examples of such channels are SSL version 3 or TLS [RFC 2246].
IOTP仕様の範囲内に含まれるネットの場所は、すべてのURI [RFC 2396]です。セキュアな接続が必要またはHTTPサーバーとクライアントサポートの両方を使用しなければならない安全なチャネルを所望される場合。そのようなチャネルの例には、SSLバージョン3またはTLS [RFC 2246]です。
In most environments, the consumer agent will initially be an HTML browser. However, current browsers do not provide the needed capability to act as an agent for the consumer for an IOTP transaction. This leads to two requirements: a method of starting and passing control to the IOTP client, and
ほとんどの環境では、消費者エージェントは、最初にHTMLブラウザになります。しかし、現在のブラウザはIOTP取引に対する消費者のためのエージェントとして動作するために必要な機能を提供していません。起動とIOTPクライアントに制御を渡す方法を、と：これは、二つの要件につながります
a method of closing down the IOTP client cleanly and passing control back to the HTML browser once the IOTP Transaction has finished.
きれいIOTPクライアントを閉鎖し、IOTPトランザクションが終了した後のHTMLブラウザに制御を渡す方法。
At some point, the HTTP client at the consumer will send an HTTP request that is interpreted as an "IOTP Startup Request" by the Merchant HTTP server. This might, for example, be the result of clicking on a "pay" button. This message is a stand-in for a request message of some form and the Merchant Server will respond with the first IOTP Message in the form of an XML document.
ある時点で、消費者のHTTPクライアントは、商人のHTTPサーバで「IOTP起動要求」と解釈されたHTTPリクエストを送信します。これは、例えば、「賃金」ボタンをクリックした結果であるかもしれません。このメッセージは、スタンドでのいくつかのフォームのリクエスト・メッセージとXML文書の形で最初のIOTPメッセージで応答します商人Serverのです。
The MIME type for all IOTP messages is: "APPLICATION/IOTP"; however "APPLICATION/X-IOTP" has been in use for experimentation and development and SHOULD also be recognized. See section 7 below for the MIME type registration template for APPLICATION/IOTP. Because HTTP is binary clean, no content-transfer-encoding is required. (See [RFC 2376] re the application/xml type which has some similar considerations.)
すべてのIOTPメッセージのMIMEタイプがある： "APPLICATION / IOTP";しかし「APPLICATION / X-IOTPは」実験と開発のために使用されているとも認識されるべきです。 APPLICATION / IOTPのためのMIMEタイプ登録テンプレートについては、以下のセクション7を参照してください。 HTTPはバイナリクリーンですので、何のコンテンツ転送エンコードは必要ありません。 （いくつかの同様の考慮事項を有するアプリケーション/ XML型のRe [RFC 2376]を参照）。
This HTTP response will be interpreted by the HTML browser as a request to start the application associated with MIME type "APPLICATION/IOTP", and to pass the content of this message to that application.
このHTTP応答は、MIMEタイプ「アプリケーション/ IOTP」に関連付けられたアプリケーションを起動すると、そのアプリケーションにこのメッセージの内容を渡す要求としてHTMLブラウザによって解釈されます。
At this point, the IOTP client will be started and have the first message.
この時点では、IOTPクライアントが開始され、最初のメッセージを持っています。
IOTP messages are short-lived. Therefore, the HTTP server SHOULD avoid having its responses cached. In HTTP V1.0, the "nocache" pragma can be used. This can be neglected on SSL/TLS secured connections which are not cached and on HTTP POST requests in HTTP v1.1 as in v1.1 POST responses are not cached.
IOTPメッセージは短命です。そのため、HTTPサーバは、その応答がキャッシュされた避ける必要があります。 HTTPのV1.0では、「NOCACHE」プラグマを使用することができます。これは、キャッシュされていないとV1.1のPOST応答のようにHTTP v1.1の中にHTTP POSTのリクエストがキャッシュされないSSL / TLS保護された接続上で無視することができます。
Data from earlier IOTP Messages in a transaction MUST be retained by the IOTP Client so that it may (1) be copied to make up part of later IOTP messages, (2) used in calculations to verify signatures in later IOTP message, (3) be resent in some cases where a request has timed out without response, (4) used as input to the Customer Care role in later versions of IOTP, etc. The way in which the data is copied depends on the IOTP Transaction. The data MUST be retained until the end of the transaction, whether by success, failure, or cancelation, and as long thereafter as it is desired for any of the parties to inquire into it.
トランザクション内の以前IOTPメッセージからデータが（1）後IOTPメッセージの一部を構成するためにコピーすることができるようにIOTPクライアントによって保持されなければならない、（2）後IOTPメッセージに署名を検証するために計算に使用される、（3）要求が応答せずにタイムアウトしたいくつかの場合には再送され、（4）等にコピーされたデータがIOTPトランザクションに依存する方法IOTPそれ以降のバージョンのカスタマーケアの役割への入力として使用されます。データは限りその後の当事者のいずれかがそれを調査することが望まれてかどうか、成功、失敗、またはキャンセルにより、トランザクションの終了まで保持し、しなければなりません。
The IOTP messages contain Net Locations (e.g. the PayReqNetLocn) which for HTTP will contain the URIs to which the IOTP client MUST send IOTP messages.
IOTPメッセージは、HTTPのためのIOTPクライアントがIOTPメッセージを送らなければなりませんしたURIを含んでいますネットの場所（例えばPayReqNetLocn）を含有します。
Subsequent IOTP messages (XML documents) will be sent using the POST function of HTTP. The HTTP client MUST perform full HTTP POST requests.
後続のIOTPメッセージ（XML文書）は、HTTPのPOST機能を使用して送信されます。 HTTPクライアントは、完全なHTTP POSTリクエストを実行しなければなりません。
The XML documents MUST be sent in a manner compatible with the external encodings allowed by the XML [XML] specification.
XML文書は、XML [XML]仕様によって許可された外部エンコーディングと互換性のある方法で送信されなければなりません。
The following should be read in conjunction with [RFC 2801].
以下は、[RFC 2801]と併せて読まれるべきです。
An IOTP Transaction is complete when
IOTPトランザクションが完了時です
-- the IOTP client decides to fail the IOTP Transaction for some reason either by canceling the transaction or as a result of discovering an error in an IOTP message received, or
- IOTPクライアントは、トランザクションをキャンセルすることによって、または受信IOTPメッセージでエラーを発見する、またはの結果として何らかの理由でIOTPトランザクションを失敗することを決定します
-- a "time out" occurs or a connection fails, e.g. a response to an IOTP Message, has not been received after some user-defined period of Time (including retransmissions).
- 例えば、「タイムアウト」が発生するか、接続が失敗しましたIOTPメッセージに対する応答は、（再送信を含む）時間のいくつかのユーザー定義期間後に受信されませんでした。
An IOTP Client which processes an IOTP Transaction which:
：IOTPトランザクション処理IOTPクライアント
-- completes successfully (i.e. it has not received an Error Block with a HardError or a Cancel Block) MUST direct the browser to the Net Location specified in SuccessNetLocn in the Protocol Options Component, i.e., cause it to do an HTTP GET with that URL.
- それは、そのURLでGET HTTPを行うには原因、すなわち、プロトコル・オプションコンポーネントでSuccessNetLocnで指定されたネットの場所にブラウザに指示しなければならない（すなわち、それはHardErrorと誤りブロックを受信またはAブロックを解除していない）正常に完了。
-- does not complete successfully, because it has received some Error Trading Block, MUST display the information in the Error Message, stop the transaction, and pass control to the browser so that it will do a GET on the Error Net Location specified for the role from which the error was received.
- それは、いくつかのエラー貿易ブロックを受信しているので、それがために指定されたエラーネット場所にGETを行いますように、エラーメッセージ内の情報を表示し、取引を停止し、ブラウザに制御を渡す必要があり、正常に完了しません。エラーが受信された役割。
-- is cancelled since a Cancel Block has been received, MUST stop the IOTP Transaction and hand control to the browser so that it will do a GET on the on the Cancel Net Location specified for the role from which the Cancel Block was received.
- それはキャンセルブロックが受信されたロールに指定取消ネット場所に上のGETを行いますように、ブラウザにIOTPトランザクションとハンド制御を停止する必要があり、ブロックが受信されているので、キャンセルキャンセルされます。
-- is in error because an IOTP Message does not conform to this specification, MUST send an IOTP Message containing a Error Trading Block to role from which the erroneous message was received and the ErrorLogNetLoc specified for that role, stop the
- IOTPメッセージは、この仕様に準拠していない誤ったメッセージが受信された役割にエラー取引をブロックし、そのロールに指定ErrorLogNetLocを含むIOTPメッセージを送信しなければならないため、エラーであり、停止
IOTP Transaction, and hand control to the browser so that it will do a GET from the Error Net Location specified for the role from which the bad message was received.
IOTPトランザクション、およびそれが不正なメッセージが受信されたロールに指定エラーネット場所からGETを行いますように、ブラウザにハンド制御。
-- has a "time out", MUST display a message describing the time out. May give the user the option of cancelling or retrying and/or may automatically retry. On failure due to time out, treat as an error above.
- 「タイムアウト」は、時間を説明するメッセージを表示する必要があります。ユーザーがキャンセルまたは再試行および/または自動的に再試行することのオプションを与えることができます。アウト期限に失敗した場合に、上記のエラーとして扱います。
Each implementation of an IOTP client may decide whether or not to terminate the IOTP Client application immediately upon completing an IOTP Transaction or whether to wait until it is closed down as a result of, for example, user shut down or browser shut down.
IOTPクライアントの各実装はIOTPトランザクションが完了すると、すぐにIOTP Clientアプリケーションを終了するか否か、またはそれは、例えば、結果として閉鎖されるまで待機するかどうかを決定することがあり、ユーザーがシャットダウンしたり、ブラウザがシャットダウンします。
Payment Handler and Deliverer IOTP Servers are started by receiving an IOTP Message which contains:
支払ハンドラと救出IOTPサーバが含まれているIOTPメッセージを受信することによって開始されます。
-- for a Payment handler, a Payment Request Block, and
- お支払いハンドラ、支払要求ブロック、および用
-- for a Delivery Handler, a Delivery Request Block
- 配信ハンドラのため、配達要求ブロック
Security of Internet Open Trade Protocol messages is primarily dependent on signatures within IOTP as described in [RFC 2801] and [RFC 2802]. Privacy protection for IOTP interactions can be obtained by using a secure channel for IOTP messages, such as SSL/TLS [RFC 2246].
[RFC 2801]と[RFC 2802]で説明したように、インターネット開かれた貿易・プロトコル・メッセージのセキュリティはIOTP内の署名に主に依存しています。 IOTP相互作用のためのプライバシー保護は、SSL / TLS [RFC 2246]と、IOTPメッセージのセキュアチャネルを使用することによって得ることができます。
Note that the security of payment protocols transported by IOTP is the responsibility of those payment protocols, NOT of IOTP.
IOTPによって運ば支払プロトコルのセキュリティは、これらの支払プロトコルの、NOT IOTPの責任であることに注意してください。
This specification defines the APPLICATION/IOTP MIME type. The registration template is as follows [RFC 2048]:
この仕様では、アプリケーション/ IOTP MIMEタイプを定義します。 [RFC 2048]を次のように登録テンプレートは以下のとおりです。
To: ietf-types@iana.org
と： いえｔｆーｔｙぺｓ＠いあな。おｒｇ
Subject: Registration of MIME media type APPLICATION/IOTP
件名：MIMEメディアタイプapplication / IOTPの登録
MIME media type name: APPLICATION
MIMEメディアタイプ名：APPLICATION
MIME subtype name: IOTP
MIMEサブタイプ名：IOTP
Required parameters: (none)
必須パラメータ：（なし）
Optional parameters: charset - see RFC 2376
オプションのパラメータ：charsetが - RFC 2376を参照してください
Encoding considerations: Content is XML and may in some cases require quoted printable or base64 encoding. However, no encoding is required for HTTP transport which is expected to be common.
エンコードの考慮事項：コンテンツはXMLであり、いくつかのケースでは、印刷可能なまたはBASE64エンコーディングを引用必要な場合があります。しかし、何のエンコーディングが一般的であると期待されているHTTPトランスポートのために必要とされません。
Security considerations: IOTP includes provisions for digital authentication but for confidentiality, other mechanisms such as TLS should be used. See RFC 2801 and RFC 2802.
セキュリティの考慮事項：IOTPは、デジタル認証のための条項を含んでいるが、機密保持のために、TLSなどの他のメカニズムを使用する必要があります。 RFC 2801およびRFC 2802を参照してください。
Interoperability considerations: See RFC 2801.
相互運用性の考慮事項：RFC 2801を参照してください。
Published specification: See RFC 2801 and RFC 2802.
公開された仕様：RFC 2801およびRFC 2802を参照してください。
Applications which use this media type: Internet Open Trading Protocol applications.
インターネットオープン取引プロトコルアプリケーション：このメディアタイプを使用するアプリケーション。
Additional information: (none)
追加情報：（なし）
Person & email address to contact for further information: Name: Donald E. Eastlake 3rd Email: Donald.Eastlake@motorola.com
人と詳細のために連絡する電子メールアドレス：名：ドナルドE.イーストレイク第三電子メール：Donald.Eastlake@motorola.com
Intended usage: COMMON
意図している用法：COMMON
Author/Change controller: IETF
著者/変更コントローラ：IETF
[RFC 1945] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[RFC 1945]バーナーズ=リー、T.、フィールディング、R.、およびH. Frystyk、 "ハイパーテキスト転送プロトコル - HTTP / 1.0"、RFC 1945、1996年5月。
[RFC 2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedure", RFC 2048, November 1996.
[RFC 2048]フリード、N.、Klensin、J.とJ.ポステル、 "多目的インターネットメール拡張（MIME）第四部：登録手順"、RFC 2048、1996年11月。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC 2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC 2246]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[RFC 2376] Whitehead, E. and M. Murata, "XML Media Types", RFC 2376, July 1998.
[RFC 2376]ホワイトヘッド、E.およびM.村田、 "XMLのメディアタイプ"、RFC 2376、1998年7月。
[RFC 2396] Berners-Lee, T., Rielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC 2396]バーナーズ=リー、T.、Rielding、R.とL. Masinter、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
[RFC 2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC 2616]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[RFC 2801] Burdett, D., "Internet Open Trading Protocol - IOTP Version 1.0", RFC 2801, April 2000.
[RFC 2801]バーデット、D.、 "インターネットオープン取引プロトコル - IOTPバージョン1.0"、RFC 2801、2000年4月。
[RFC 2802] Davidson, K. and Y. Kawatsura, "Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP)", RFC 2802, April 2000
[RFC 2802]ダビッドソン、K.とY. Kawatsura、 "v1.0のインターネットオープン取引プロトコル（IOTP）のデジタル署名"、RFC 2802、2000年4月
[XML] Bray, T., Paoli, J. and C. Sperberg-McQueen, "Extensible Markup Language (XML) 1.0" <http://www.w3.org/TR/REC-xml>, February 1998.
[XML]ブレイ、T.、パオリ、J.及びC. Sperberg-マックイーン、 "拡張マークアップ言語（XML）1.0" <http://www.w3.org/TR/REC-xml>、1998年2月。
Donald E. Eastlake 3rd Motorola 140 Forest Avenue Hudson, MA 01749 USA
ドナルドE.イーストレーク第3モトローラ140森アベニューハドソン、MA 01749 USA
Phone: +1 978-562-2827(h) +1 508-261-5434(w) Fax: +1 508-261-4447(w) EMail: Donald.Eastlake@motorola.com
電話：+1 978-562-2827（H）+1 508-261-5434（W）FAX番号：+1 508-261-4447（W）メール：Donald.Eastlake@motorola.com
Chris J. Smith Royal Bank of Canada 277 Front Street West Toronto, Ontario M5V 3A4 CANADA
カナダのクリス・J.スミスロイヤル・バンク・277フロントストリート西トロント、オンタリオM5V 3A4 CANADA
Phone: +1 416-348-6090 Fax: +1 416-348-2210 EMail: chris.smith@royalbank.com
電話：+1 416-348-6090ファックス：+1 416-348-2210電子メール：chris.smith@royalbank.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。