[要約] RFC 2935は、IOTPのHTTPサプリメントであり、オープンな取引プロトコルをインターネット上で実現するための仕様書です。このRFCの目的は、IOTPをHTTPプロトコルに統合し、セキュアな取引を可能にすることです。
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
インターネットオープントレーディングプロトコル（IOTP）HTTPサプリメント
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.
Copyright（c）The Internet Society（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）ドキュメントとして掲載されます。そのため、輸送層にマッピングするという目標は、基礎となる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 [RFCS 1945、2616]のマッピングについて説明しています。
There may be future documents describing IOTP over email (SMTP), TCP, cable TV, or other transports.
IOTPを介した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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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仕様に含まれる正味の場所はすべてURIS [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トランザクションのために消費者のエージェントとして機能するために必要な機能を提供しません。これにより、2つの要件が発生します。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クライアントは、Merchant HTTPサーバーによって「IOTPスタートアップリクエスト」として解釈されるHTTP要求を送信します。これは、たとえば、「支払い」ボタンをクリックした結果である場合があります。このメッセージは、何らかの形のリクエストメッセージの代役であり、MerchantサーバーはXMLドキュメントの形式で最初のIOTPメッセージで応答します。
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」;ただし、「アプリケーション/X-OITP」は実験と開発に使用されており、認識されるべきです。アプリケーション/IOTPのMIMEタイプ登録テンプレートについては、以下のセクション7を参照してください。HTTPはバイナリクリーンであるため、コンテンツ転移エンコードは必要ありません。（[RFC 2376] reを参照してください/XMLタイプには、いくつかの同様の考慮事項があります。）
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では、「ノーキャッシュ」プラグマを使用できます。これは、キャッシュされていないSSL/TLSセキュリティで保護された接続で無視でき、v1.1のポスト応答がキャッシュされていないように、HTTP v1.1のHTTP投稿リクエストでは無視できます。
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メッセージからのデータは、IOTPクライアントが保持する必要があります。これにより、（1）後のIOTPメッセージの一部を構成するためにコピーする必要があります。リクエストが応答せずにタイムアウトした場合、（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用のネットロケーション（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投稿リクエストを実行する必要があります。
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.
- 正常に完了します（つまり、Harderrorまたはキャンセルブロックを備えたエラーブロックを受信していません）が、プロトコルオプションコンポーネントのSuccessNetLocnで指定されたネット位置にブラウザを向ける必要があります。。
-- 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.
- エラー取引ブロックを受信しているため、正常に完了しません。エラーメッセージに情報を表示し、トランザクションを停止し、ブラウザにパスコントロールを表示して、エラーが受信された役割。
-- 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.
- キャンセルブロックが受信されているためキャンセルされ、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 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メッセージがこの仕様に準拠していないため、エラー取引ブロックを含むIOTPメッセージを送信する必要があります。エラーメッセージが受信され、その役割に指定されたErrorLognetlocが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クライアントアプリケーションをすぐに終了するかどうか、またはユーザーがシャットダウンまたはブラウザのシャットダウンの結果として閉鎖されるまで待機するかどうかを決定する場合があります。
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によって輸送される支払いプロトコルのセキュリティは、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
宛先：ietf-types@iana.org
Subject: Registration of MIME media type APPLICATION/IOTP
件名：MIMEメディアタイプアプリケーション/IOTPの登録
MIME media type name: APPLICATION
MIMEメディアタイプ名：アプリケーション
MIME subtype name: IOTP
MIMEサブタイプ名：IOTP
Required parameters: (none)
Optional parameters: charset - see 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
連絡先の個人とメールアドレス詳細については、名前：Donald E. Eastlake 3rd Email：donald.eastlake@motorola.com
Intended usage: 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] Berners-Lee、T.、Fielding、R。and H. Frystyk、「HyperText Transfer Protocol-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] Freed、N.、Klensin、J。およびJ. Postel、「多目的インターネットメール拡張機能（MIME）パート4：登録手順」、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Dierks、T。およびC. Allen、「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] Berners-Lee、T.、Rielding、R。and L. Masinter、「Uniform Resource Identiers（URI）：Generic Syntax」、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。and T. Berners-Lee、「Hypertext Transfer Protocol-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] Burdett、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] Davidson、K。およびY. Kawatsura、「V1.0 Internet Open Trading Protocol（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] Bray、T.、Paoli、J。、およびC. Sperberg-Mcqueen、 "Extensible Markup Language（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フォレストアベニューハドソン、マサチューセッツ州01749 USA
Phone: +1 978-562-2827(h)
+1 508-261-5434(w)
Fax: +1 508-261-4447(w)
EMail: Donald.Eastlake@motorola.com
Chris J. Smith Royal Bank of Canada 277 Front Street West Toronto, Ontario M5V 3A4 CANADA
クリス・J・スミス・ロイヤル・バンク・オブ・カナダ277フロント・ストリート・ウェスト・トロント、オンタリオM5V 3A4カナダ
Phone: +1 416-348-6090
Fax: +1 416-348-2210
EMail: chris.smith@royalbank.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。