《{贸易合同}开放贸易协议补充》由会员分享，可在线阅读，更多相关《{贸易合同}开放贸易协议补充（9页珍藏版）》请在金锄头文库上搜索。
1、组织：中国互动出版网（http:/www.china- ）译文发布时间：2001-11-4版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须保留本文档的翻译及版权信息。Network Working Group D. EastlakeRequest for Comments: 2935 MotorolaCategory: Standards Track C. Smith Royal Bank of Canada September 2000Internet开放贸易协议(IOTP)HTTP 补充（RFC2935Internet Open Trading Protoc
2、ol (IOTP) HTTP Supplement）本备忘录的状态本文档定义了一种Internet社区的Internet标准跟踪协议，它需要进一步进行讨论和建议以得到改进。请参考最新版的“Internet正式协议标准” (STD1)来获得本协议的标准化程度和状态。本备忘录的发布不受任何限制。版权声明：Copyright (C) The Internet Society (2000). All Rights Reserved.摘要Internet开放贸易协议(IOTP)消息将以可扩展标记语言(XML)文档作为传输载体。就其本身而论，映象至传输层的目的是为了保证底层的XML文档在不同的层间正确地传
3、输。此文档描述了超文本传输协议(HTTP), Versions 1.0 and 1.1.的映象。目录1介绍22HTTP服务器和客户端23HTTP网络位置34客户3 4.1 开启IOTP客户端和商业IOTP服务器 3 4.2 传送中的IOTP消息 3 4.3 中断一个IOTP交易 45开始交付处理器和递交器IOTP服务器56安全考虑67IANA的考虑68参考79作者地址810完整的版权声明8鸣谢91介绍Internet开放贸易协议(IOTP)消息将以可扩展标记语言XML文档作为传输载体。就其本身而论，映象至传输层的目的是为了保证底层的XML文档在不同的层间正确地传输。此文档描述了超文本传输协议(
4、HTTP), Versions 1.0 and 1.1的映象RFCs 1945, 2616。将来可能会有描述关于email（SMTP）、TCP、cable TV或者其它传输方面的IOTP文档 。在本文档中的关键字“必须”, “决不要”, “必须的”,“将要”, “不会”, “应当”, “不应当”, “建议”, “可以”, 和 “可选的” 将会在RFC2119文档中给予说明。2HTTP服务器和客户端IOTP的结构以如下方式映象到HTTP的结构：商家、付款处理器、交货处理器，以及客户相关的交易方都由HTTP服务器代表。每一方都可以是由一立的服务器代表，也可以是以某种联接方式结合。客户角色由HTTP
5、客户端代表。注意: 一个商人也会充当消费者的职能,比如说他要储存电子货币。在这种情况下，商人作为一个组织而非单一的职能，需要一个HTTP客户端支持。3HTTP网络位置包含在IOTP规格书中的网络位置皆为URIs （Uniform Resource Identifiers）RFC 2396。如果必须要或者是要求使用安全连接的话，就必须用一个对HTTP服务器以及客户端都支持的安全通道。 像SSL version 3 或者 TLS RFC 2246都可以用作这种通道。4客户在大多数环境中，客户的最初的媒介总是一个HTML浏览器。可是呢，现有的浏览器都没有提供足够的功能，来为客户充当媒介完成一次IOT
6、P交易。这就带来了俩个必须满足的条件：一个开启IOTP客户端并控制权转交给IOTP客户端的方法，以及一个在IOTP交易结束后安全停止IOTP客户端并将控制权转交给HTML浏览器的方法。4.1 开始IOTP客户端以及商业IOTP服务器 在某些情况下，用户方的HTTP客户端会发送一个HTTP请求，这个请求被商业HTTP服务器解释为一个“IOTP启动请求”。比如说当你单击“付款”按钮时，就会达到这样的效果。这个消息就是某种形式的请求消息的“替身”，并且，商业服务器会以XML文档的形式对这个第一个IOTP消息作出响应。对所有IOTP消息的MIME协议格式为：“APPLICATION/IOTP”；然而，
7、“APPLICATION/X-IOT”已经被应用于实验室和开发中了，这一点应该得到认可。要得到APPLICATION/IOTP的MIME协议格式的注册模板，请参见下面第7部分的内容。因为HTTP完全是二进制编码，所以不需要对要传输的内容进行传输编码。（参见RFC 2376修订版，application/xml格式，它也有一些类似的考虑。） HTML浏览器会将这个HTTP响应解释为开启与MIME协议类型“APPLICATION/IOTP” 相关的应用程序的一个响应，并把这个消息的内容发送给应用程序。 就在这一时刻，IOTP客户端就会被启动，并获得第一个消息。 IOTP消息的生存期是短暂的，因此，
8、HTTP服务器应当避免将其响应放到缓存区中。在HTTP V1.0当中，我们可以使用“nocache”注记符来使响应不被放到缓存区中。而当我们使用的是SSL/TLS安全连接时，就可以不考虑这个问题，因为它不带有缓冲区；还有，在HTTP v1.1 中HTTP发送请求也一样不用考虑缓冲区问题，因为在HTTP v1.1中发送请求是不会被放到缓冲区中的。4.2 传送中的IOTP消息在一次交易中，先发送出去的IOTP消息中的数据必须要由IOTP客户端保留下来，这样做的目的是：（1）拷贝下来的数据作为后续IOTP消息的组成部分；（2）用于在后续IOTP消息中验证签名的计算；（3）在某些情况下，当请求没有得到
9、响应而超时时需要重新发送；（4）在最新的IOTP版本中用作客户相关交易方的输入，等等拷贝的具体方式由特定的IOTP交易决定。不管交易最终是失败、成功还是被取消，这些数据都必须保留到IOTP交易的最后，并且在交易之后，还要保留，直到交易的任何一方都不想再去查询它为止。IOTP 消息包含了网络位置信息（比如说PayReqNetLocn），HTTP的网络位置包含有IOTP客户端要发送IOTP消息的目的地址的URIs。后面的IOTP消息（皆是XML文档）是通过使用HTTP的POST函数发送的。HTTP客户端必须要执行所有的HTTP的POST请求。XML文档必须通过一种与外部编码所兼容的方式来发送，当然
10、，这种外部编码是符合XML XML规格的。4.3 中止一个IOTP交易下面所讲述的内容，读者可以结合RFC 2801文档来阅读。当出现以下情形时，一笔IOTP交易就算完成了： - 当IOTP客户端由于某些原因决定放弃这笔IOTP交易，也可能是由于客户要撤销这笔交易，或者是在接收IOTP消息过程中出现错误的结果。或者当： -出现“超时”错误或者是连接失败，比如说，在用户定义的响应时间范围内，接收方没有收到对一个特定IOTP消息的响应（包括重发信息）。一个执行IOTP交易的IOTP客户端，此交易： - 若成功完成（也就是说，没有接收到有HardError的错误块或者是取消块），它必须指示浏览器连向
11、在协议选项组件中定义在SuccessNetLocn里面的网络位置，也就是说，让浏览器去对这个URL做一个HTTP GET请求。 -若是因为收到一些错误交易块而使交易没有成功的话，它必须要将这些信息显示在错误消息中，中止这笔交易，并将控制权交给浏览器，这样它就会对Error网络地址发送一个GET请求，此地址详细指明了错误是由哪一方引起的。 - 若是因为收到了取消块而使交易被迫取消了，必须要中止此IOTP交易并将控制权交给浏览器，以让浏览器对Cancel网络地址发送一个GET请求，此地址详细指明了取消块是从哪一方发出来的。 - 若是由于一个IOTP消息不符合所要求的规格而发生错误，必须发送一个包含
12、错误交易块的IOTP消息到导致此错误消息的交易方（此交易方由ErrorLogNetLoc定义），并中止此IOTP交易，再将控制权移交给浏览器，这样这样它就会对Error网络地址发送一个GET请求，此地址详细指明了错误是由哪一方引起的。 - 如果是“超时”的话，就必须显示一个消息来说明是超时。可以给用户提供几个可选项：取消、重试或者是自动重试。如果由于超时导致交易失败，按照上面所讲的交易“错误”做处理。 每一个IOTP客户端实现都要考虑是否当完成一个IOTP交易后要立刻终止掉IOTP客户端应用程序，或者是要一直等到由于某种情况而被关掉，比如说是用户关闭或者是浏览器关闭。5开始交付处理器和递交器I
13、OTP服务器 当付款处理器和交货器IOTP服务器收到包含下列信息的消息时，它就开始工作： - 对于一个付款处理器，有一个付款请求块, 以及 - 对于一个交货处理器，有一个交货请求块6安全考虑 Internet开放贸易协议(IOTP)消息的安全防护主要是靠IOTP内部的签名，这在RFC 2801 和 RFC 2802文档中有详细描述。 可以通过使用一个安全的通道来传输IOTP消息，比如说SSL/TLS RFC 2246，以达到IOTP交互中的保密性保护的目的。 要注意的是，由IOTP传输的付款协议的安全是付款协议的职责，而非IOTP的职责。7IANA的考虑 This specification defines the APPLICATION/IOTP MIME type. The registration template is as follows RFC 2048: To: ietf-typesiana.org Subject: Registration of MIME media typ
