Network Working Group D. Eastlake
Request for Comments: 2935 Motorola
Category: Standards Track C. Smith
Royal Bank of Canada
September 2000
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.
版权所有（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）文档进行传输。因此，映射到传输层的目标是确保在各方之间成功地传输底层XML文档。
This document describes that mapping for the Hyper Text Transport Protocol (HTTP), Versions 1.0 and 1.1.
本文档描述了1.0和1.1版超文本传输协议（HTTP）的映射。
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
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].
本文档描述了1.0和1.1版超文本传输协议（HTTP）的映射[RFCs 1945，2616]。
There may be future documents describing IOTP over email (SMTP), TCP, cable TV, or other transports.
将来可能会有文档描述通过电子邮件（SMTP）、TCP、有线电视或其他传输的IOTP。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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:
在大多数环境中，消费者代理最初是一个HTML浏览器。但是，当前的浏览器没有提供作为IOTP交易的消费者代理所需的功能。这导致两个要求：
a method of starting and passing control to the IOTP client, and
启动并向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请求，该请求被商户HTTP服务器解释为“IOTP启动请求”。例如，这可能是单击“支付”按钮的结果。此消息是某种形式请求消息的替代，商户服务器将以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类型为：“应用程序/IOTP”；然而，“应用程序/X-IOTP”已经用于实验和开发，也应该得到认可。有关应用程序/IOTP的MIME类型注册模板，请参见下文第7节。因为HTTP是二进制干净的，所以不需要内容传输编码。（请参见[RFC 2376]了解具有类似注意事项的应用程序/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.
HTML浏览器将此HTTP响应解释为启动与MIME类型“application/IOTP”关联的应用程序并将此消息的内容传递给该应用程序的请求。
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服务器应该避免缓存其响应。在HTTPV1.0中，可以使用“nocache”pragma。在未缓存的SSL/TLS安全连接和HTTP v1.1中的HTTP POST请求（如v1.1中的POST响应）上，可以忽略这一点。
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消息的一部分，（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消息包含净位置（例如PayReqNetLocn），对于HTTP，该净位置将包含IOTP客户端必须向其发送IOTP消息的URI。
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客户端，该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.
--成功完成（即未收到带有硬错误或取消块的错误块）必须将浏览器指向协议选项组件中SuccessNetLocn中指定的网络位置，即使其使用该URL执行HTTP GET。
-- 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.
--在收到取消阻止后被取消，则必须停止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消息不符合本规范而出错，必须将包含错误交易块的IOTP消息发送给接收错误消息的角色，并为该角色指定ErrorLogNetLoc，停止
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客户端应用程序，或是否等待直到其由于例如用户关闭或浏览器关闭而关闭。
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交互的隐私保护可通过使用IOTP消息的安全通道获得，如SSL/TLS[RFC 2246]。
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
可选参数：字符集-参见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.
使用此媒体类型的应用程序：Internet开放交易协议应用程序。
Additional information: (none)
补充资料：（无）
Person & email address to contact for further information: Name: Donald E. Eastlake 3rd Email: Donald.Eastlake@motorola.com
联系人和电子邮件地址以获取更多信息：姓名：Donald E.Eastlake第三封电子邮件：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.和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]Freed，N.，Klensin，J.和J.Postel，“多用途互联网邮件扩展（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]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]Whitehead，E.和M.Murata，“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.和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.，弗莱斯蒂克，H.，马斯特，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]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互联网开放交易协议（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，“可扩展标记语言（XML）1.0”<http://www.w3.org/TR/REC-xml>，1998年2月。
Donald E. Eastlake 3rd Motorola 140 Forest Avenue Hudson, MA 01749 USA
美国马萨诸塞州哈德逊森林大道140号唐纳德E东湖第三摩托罗拉01749
Phone: +1 978-562-2827(h)
+1 508-261-5434(w)
Fax: +1 508-261-4447(w)
EMail: Donald.Eastlake@motorola.com
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
Chris J.Smith加拿大皇家银行加拿大安大略省西多伦多前大街277号M5V 3A4
Phone: +1 416-348-6090
Fax: +1 416-348-2210
EMail: chris.smith@royalbank.com
Phone: +1 416-348-6090
Fax: +1 416-348-2210
EMail: 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编辑功能的资金目前由互联网协会提供。