RFC2935-Internet开放贸易协议HTTP 补充

1、组织：中国国互动出版版网（ HYPERLINK / htttp:/wwww.chiina-puub.coom/）RFC文档档中文翻译译计划（ HYPERLINK / hhttp:/commpterrs/emmook/abouutemoook.hhtm）E-maiil： HYPERLINK mailto:ouyang ouuyanggchiina-ppub.ccom译者：陈贵贵敏（effoxxxx HYPERLINK mailto: ）译文发布时时间：20001-111-4版权：本中中文翻译文文档版权归归中国互动动出版网所所有。可以以用于非商商业用途自自由转载，但但必须保留留本文档的的翻译及版版

2、权信息。Netwoork WWorkiing GGroupp D. EasttlakeeRequeest ffor CCommeents: 29335 MotoorolaaCateggory: Staandarrds TTrackk C. SSmithh Rooyal Bankk of Canaada SSepteemberr 20000Interrnet开开放贸易协协议(IOOTP)HHTTP 补充（RFC22935Intterneet Oppen TTradiing PProtoocol (IOTTP) HHTTP Suppplemeent）本备忘录的的状态本文档定义义了一种IInterr

3、net社社区的Innternnet标准准跟踪协议议，它需要要进一步进进行讨论和和建议以得得到改进。请参考最最新版的“Inteernett正式协议议标准” (STTD1)来来获得本协协议的标准准化程度和和状态。本本备忘录的的发布不受受任何限制制。版权声明：Copyrrightt (C) Thee Intterneet Soocietty (22000). AAll RRightts Reeservved.摘要Interrnet开开放贸易协协议(IOOTP)消消息将以可可扩展标记记语言(XXML)文文档作为传传输载体。就其本身身而论，映映象至传输输层的目的的是为了保保证底层的的XML文文档在不同同

4、的层间正正确地传输输。此文档描述述了超文本本传输协议议(HTTTP), Verssionss 1.00 andd 1.11.的映象象。目录TOC o 1-3 h z HYPERLINK l _Toc528586410 1介绍 PAGEREF _Toc528586410 h 2 HYPERLINK l _Toc528586411 2HTTTP服务器器和客户端端 PAGEREF _Toc528586411 h 2 HYPERLINK l _Toc528586412 3HTTTP网络位位置 PAGEREF _Toc528586412 h 3 HYPERLINK l _Toc528586413 4客户

5、 PAGEREF _Toc528586413 h 3 44.1 开启IOTTP客户端端和商业IIOTP服服务器 3 44.2 传送中的的IOTPP消息 3 4.3 中断一一个IOTTP交易 4 HYPERLINK l _Toc528586414 5开始交交付处理器器和递交器器IOTP服务务器 PAGEREF _Toc528586414 h 5 HYPERLINK l _Toc528586415 6安全考考虑 PAGEREF _Toc528586415 h 6 HYPERLINK l _Toc528586416 7IANNA的考虑虑 PAGEREF _Toc528586416 h 6 HYPER

6、LINK l _Toc528586417 8参考 PAGEREF _Toc528586417 h 7 HYPERLINK l _Toc528586418 9作者地地址 PAGEREF _Toc528586418 h 8 HYPERLINK l _Toc528586419 10完整整的版权声声明 PAGEREF _Toc528586419 h 8 HYPERLINK l _Toc528586420 鸣谢 PAGEREF _Toc528586420 h 91介绍Interrnet开开放贸易协协议(IOOTP)消消息将以可可扩展标记记语言XXML文文档作为传传输载体。就其本身身而论，映映象至传输输层

7、的目的的是为了保保证底层的的XML文文档在不同同的层间正正确地传输输。此文档描述述了超文本本传输协议议(HTTTP), Verssionss 1.00 andd 1.11的映象RRFCs 19455, 26616。将来可能会会有描述关关于emaail（SSMTP）、TCP、cablle TVV或者其它它传输方面面的IOTTP文档 。在本文档中中的关键字字“必须”, “决不要”, “必须的”,“将要”, “不会”, “应当”, “不应当”, “建议”, “可以”, 和 “可选的” 将会在RRFC21119文文档中给予予说明。2HTTTP服务器器和客户端端IOTP的的结构以如如下方式映映象到HTT

8、TP的结结构：商家、付款款处理器、交货处理理器，以及及客户相关关的交易方方都由HTTTP服务务器代表。每一方都都可以是由由一台独立立的服务器器代表，也也可以是以以某种联接接方式结合合。客户角色由由HTTPP客户端代代表。注意: 一一个商人也也会充当消消费者的职职能,比如如说他要储储存电子货货币。在这这种情况下下，商人作作为一个组组织而非单单一的职能能，需要一一个HTTTP客户端端支持。3HTTTP网络位位置包含在IOOTP规格格书中的网网络位置皆皆为URIIs （Unifform Resoourcee Ideentiffierss）RFCC 23996。如如果必须要要或者是要要求使用安安全连接

9、的的话，就必必须用一个个对HTTTP服务器器以及客户户端都支持持的安全通通道。 像SSL verssion 3 或者者 TLSS RFFC 22246都都可以用作作这种通道道。4客户在大多数环环境中，客客户的最初初的媒介总总是一个HHTML浏浏览器。可可是呢，现现有的浏览览器都没有有提供足够够的功能，来来为客户充充当媒介完完成一次IIOTP交交易。这就就带来了俩俩个必须满满足的条件件：一个开启IIOTP客客户端并控控制权转交交给IOTTP客户端端的方法，以以及一个在在IOTPP交易结束束后安全停停止IOTTP客户端端并将控制制权转交给给HTMLL浏览器的的方法。 开始IOOTP客户户端以及商商

10、业IOTTP服务器器 在某些些情况下，用用户方的HHTTP客客户端会发发送一个HHTTP请请求，这个个请求被商商业HTTTP服务器器解释为一一个“IOTPP启动请求求”。比如说说当你单击击“付款”按钮时，就就会达到这这样的效果果。这个消消息就是某某种形式的的请求消息息的“替身”，并且，商商业服务器器会以XMML文档的的形式对这这个第一个个IOTPP消息作出出响应。对所有IOOTP消息息的MIMME协议格格式为：“APPLLICATTION/IOTPP”；然而，“APPLLICATTION/X-IOOT”已经被应应用于实验验室和开发发中了，这这一点应该该得到认可可。要得到到APPLLICATTI

11、ON/IOTPP的MIMME协议格格式的注册册模板，请请参见下面面第7部分分的内容。因为HTTTP完全全是二进制制编码，所所以不需要要对要传输输的内容进进行传输编编码。（参参见RFFC 23376修修订版，aappliicatiion/xxml格式式，它也有有一些类似似的考虑。） HHTML浏浏览器会将将这个HTTTP响应应解释为开开启与MIIME协议议类型“APPLLICATTION/IOTPP” 相关的的应用程序序的一个响响应，并把把这个消息息的内容发发送给应用用程序。 就就在这一时时刻，IOOTP客户户端就会被被启动，并并获得第一一个消息。 IIOTP消消息的生存存期是短暂暂的，因此此，

12、HTTTP服务器器应当避免免将其响应应放到缓存存区中。在在HTTPP V1.0当中，我我们可以使使用“nocaache”注记符来来使响应不不被放到缓缓存区中。而当我们们使用的是是SSL/TLS安安全连接时时，就可以以不考虑这这个问题，因因为它不带带有缓冲区区；还有，在在HTTPP v1.1 中HHTTP发发送请求也也一样不用用考虑缓冲冲区问题，因因为在HTTTP vv1.1中中发送请求求是不会被被放到缓冲冲区中的。传送中的IIOTP消消息在一次交易易中，先发发送出去的的IOTPP消息中的的数据必须须要由IOOTP客户户端保留下下来，这样样做的目的的是：（1）拷贝贝下来的数数据作为后后续IOTT

13、P消息的的组成部分分；（2）用于于在后续IIOTP消消息中验证证签名的计计算；（3）在某某些情况下下，当请求求没有得到到响应而超超时时需要要重新发送送；（4）在最最新的IOOTP版本本中用作客客户相关交交易方的输输入，等等等拷贝的具体体方式由特特定的IOOTP交易易决定。不不管交易最最终是失败败、成功还还是被取消消，这些数数据都必须须保留到IIOTP交交易的最后后，并且在在交易之后后，还要保保留，直到到交易的任任何一方都都不想再去去查询它为为止。IOTP 消息包含含了网络位位置信息（比比如说PaayReqqNetLLocn），HHTTP的的网络位置置包含有IIOTP客客户端要发发送IOTTP消

14、息的的目的地址址的URIIs。后面的IOOTP消息息（皆是XXML文档档）是通过过使用HTTTP的PPOST函函数发送的的。HTTTP客户端端必须要执执行所有的的HTTPP的POSST请求。XML文档档必须通过过一种与外外部编码所所兼容的方方式来发送送，当然，这这种外部编编码是符合合XML XMLL规格的的。 中止一个个IOTPP交易下面所讲述述的内容，读读者可以结结合RFFC 28801文文档来阅读读。当出现以下下情形时，一一笔IOTTP交易就就算完成了了： 当IOOTP客户户端由于某某些原因决决定放弃这这笔IOTTP交易，也也可能是由由于客户要要撤销这笔笔交易，或或者是在接接收IOTTP消

15、息过过程中出现现错误的结结果。或者者当： 出现“超时”错误或者者是连接失失败，比如如说，在用用户定义的的响应时间间范围内，接接收方没有有收到对一一个特定IIOTP消消息的响应应（包括重重发信息）。一个执行IIOTP交交易的IOOTP客户户端，此交交易： 若成功功完成（也也就是说，没没有接收到到有HarrdErrror的错错误块或者者是取消块块），它必必须指示浏浏览器连向向在协议选选项组件中中定义在SSucceessNeetLoccn里面的的网络位置置，也就是是说，让浏浏览器去对对这个URRL做一个个HTTPP GETT请求。 若是因为为收到一些些错误交易易块而使交交易没有成成功的话，它它必须要

16、将将这些信息息显示在错错误消息中中，中止这这笔交易，并并将控制权权交给浏览览器，这样样它就会对对Erroor网络地地址发送一一个GETT请求，此此地址详细细指明了错错误是由哪哪一方引起起的。 若是因因为收到了了取消块而而使交易被被迫取消了了，必须要要中止此IIOTP交交易并将控控制权交给给浏览器，以以让浏览器器对Canncel网网络地址发发送一个GGET请求求，此地址址详细指明明了取消块块是从哪一一方发出来来的。 若是由由于一个IIOTP消消息不符合合所要求的的规格而发发生错误，必必须发送一一个包含错错误交易块块的IOTTP消息到到导致此错错误消息的的交易方（此此交易方由由ErroorLogg

17、NetLLoc定义义），并中中止此IOOTP交易易，再将控控制权移交交给浏览器器，这样这这样它就会会对Errror网络络地址发送送一个GEET请求，此此地址详细细指明了错错误是由哪哪一方引起起的。 如果是是“超时”的话，就就必须显示示一个消息息来说明是是超时。可可以给用户户提供几个个可选项：取消、重重试或者是是自动重试试。如果由由于超时导导致交易失失败，按照照上面所讲讲的交易“错误”做处理。 每每一个IOOTP客户户端实现都都要考虑是是否当完成成一个IOOTP交易易后要立刻刻终止掉IIOTP客客户端应用用程序，或或者是要一一直等到由由于某种情情况而被关关掉，比如如说是用户户关闭或者者是浏览器器

18、关闭。5开始交交付处理器器和递交器器IOTPP服务器 当当付款处理理器和交货货器IOTTP服务器器收到包含含下列信息息的消息时时，它就开开始工作： 对于一一个付款处处理器，有有一个付款款请求块, 以及 对于一一个交货处处理器，有有一个交货货请求块6安全考考虑 IInterrnet开开放贸易协协议(IOOTP)消消息的安全全防护主要要是靠IOOTP内部部的签名，这这在RFFC 28801 和 RFFC 28802文文档中有详详细描述。 可以通通过使用一一个安全的的通道来传传输IOTTP消息，比比如说SSSL/TLLS RRFC 22466，以达达到IOTTP交互中中的保密性性保护的目目的。 要注

19、注意的是，由由IOTPP传输的付付款协议的的安全是付付款协议的的职责，而而非IOTTP的职责责。7IANNA的考虑虑 Thhis sspeciificaationn deffiness thee APPPLICAATIONN/IOTTP MIIME ttype. Thhe reegisttratiion ttempllate is aas foollowws RRFC 22048: To: iettf-tyypesg Subbjectt: Reegisttratiion oof MIIME mmediaa typpe APPPLICCATIOON/IOOTP MIMME meedia type

20、e namme: AAPPLIICATIION MIMME suubtyppe naame: IOTPP Reqquireed paarameeterss: (nnone) Opttionaal paarameeterss: chharseet - see RFC 23766 Enccodinng coonsidderattionss: Coontennt iss XMLL andd mayy in somee casses reqquiree quooted prinntablle orr basse64 encoodingg. HHowevver, no eencodding is req

21、uuiredd forr HTTTP trranspport whicch iss exppecteed too be commmon. Seccuritty coonsidderattionss: IOOTP iincluudes provvisioons ffor ddigittal autthentticattion but for conffidenntiallity, othher mmechaanismms suuch aas TLSS shoould be uused. Seee RFFC 28801 aand RRFC 22802. Intteropperabbilitty c

22、oonsidderattionss: Seee RFFC 28801. Pubblishhed sspeciificaationn: Seee RFFC 28801 aand RRFC 22802. Appplicaationns whhich use thiss meddia ttype: Innternnet OOpen Tradding Prootocool apppliccatioons. Addditioonal infoormattion: (noone) Perrson & emmail addrress to ccontaact ffor ffurthher iinforrma

23、tiion: Namee: Doonaldd E. Easttlakee 3rdd Emaiil: DDonalld.Eaastlaake Inttendeed ussage: COMMMON Autthor/Channge ccontrrolleer: IIETF8参考RFC 19455 Beernerrs-Leee, TT., FFieldding, R. and H. FFrysttyk, HypperteextTranssfer Prottocoll - HTTPP/1.00, RRFC 11945, Mayy 19996.RFC 20488 Frreed, N., Kleensinn

24、, J. andd J. Posttel, MulltipuurposseInterrnet Maill Exttensiions (MIMME) PPart Fourr: ReegisttratiionProceeduree, RRFC 22048, Novvembeer 19996.RFC 21199 Brradneer, SS., Key wordds foor usse inn RFCCs too InddicatteRequiiremeent LLevells, BCP 14, RFC 21199, Maarch 19977.RFC 22466 Diierkss, T. andd C

25、. Alleen, The TLS Prottocoll Verrsionn 1.00,RFC 22246, Jannuaryy 19999.RFC 23766 Whhitehhead, E. and M. MMuratta, XML Mediia Tyypes, RFFC 23376,July 19988.RFC 23966 Beernerrs-Leee, TT., RRieldding, R. and L. MMasinnter, UnniforrmResouurce Idenntifiiers (URII): GGenerric SSyntaax, RFC 23966,Augusst 1

26、9998.RFC 26166 Fiieldiing, R., Getttys, J., Moguul, JJ., FFrysttyk, H.,Masinnter, L., Leaach, P. aand TT. Beernerrs-Leee, HypeertexxtTranssfer Prottocoll - HTTPP/1.11, RRFC 22616, Junne 19999.RFC 28011 Buurdettt, DD., Inteernett Opeen Trradinng Prrotoccol - IOTTPVersiion 11.0, RFCC 28001, AAprill 20

27、000.RFC 28022 Daavidsson, K. aand YY. Kaawatssura, Diigitaal Siignatturess forr theev1.0 Inteernett Opeen Trradinng Prrotoccol (IOTPP), RFC 28022,Aprill 20000XML Brray, T., Paolli, JJ. annd C. Speerberrg-MccQueeen, ExteensibbleMarkuup Laanguaage (XML) 1.00 ,Februuary 19988.9作者地地址 Doonaldd E. Easttla

28、kee 3rdd Mootoroola 1440 Foorestt Aveenue Huudsonn, MAA 017749 UUSA Phhone: +1 978-562-28277(h) +1 508-261-54344(w) Faax: +1 508-261-44477(w) EMMail: Donnald.Easttlakeemottorolla.coom Chhris J. SSmithh Rooyal Bankk of Canaada 2777 Frront Streeet WWest Toorontto, OOntarrio MM5V 33A4 CCANADDA Phhone:

29、+1 416-348-60900 Faax: +1 416-348-22100 EMMail: chrris.ssmithhroyyalbaank.ccom10完整整的版权声声明 Coopyriight (C) The Inteernett Soccietyy (20000). Alll Riightss Resserveed. Thhis ddocumment and trannslattionss of it mmay bbe coopiedd andd furrnishhed tto ottherss, annd deerivaativee worrks tthat commment o

30、n oor ottherwwise expllain it orr asssist in iits iimpleementtatioon maay bee preepareed, ccopieed, ppubliishedd annd diistriibuteed, iin whhole or iin paart, withhout resttricttion of aany kiind, provvidedd thaat thhe abbove copyyrighht nooticee andd thiis paaragrraph are inncludded oon alll suuch ccopiees annd deerivaativee worrks. Howweverr, thhis doocumeent iitsellf maay noot bee moddifieed inn anyy wayy, suuch aas byy remmovinng thhe coopyriight notiice oor reefereencess to the Inteernett Soccietyy or otheer Innternnet oorgannizat