RFC2935-Internet開放貿(mào)易協(xié)議(IOTP)HTTP 補充

1、組織：中國互動出版網(wǎng)（ HYPERLINK / /）RFC文檔中文翻譯計計劃（ HYPERLINK / http:/compters/emook/aboutemook.htm）E-mail： HYPERLINK mailto:ouyang ouyang譯者：陳貴敏（efoxxx HYPERLINK mailto: ）譯文發(fā)布時間：2001-11-4版權(quán)：本中文翻譯文檔檔版權(quán)歸中國互動動出版網(wǎng)所有。可可以用于非商業(yè)用用途自由轉(zhuǎn)載，但但必須保留本文檔檔的翻譯及版權(quán)信信息。Network Working Group D. EastlakeRequest for Comments: 2935 Moto

2、rolaCategory: Standards Track C. Smith Royal Bank of Canada September 2000Internet開放放貿(mào)易協(xié)議(IOTP)HTTP 補充充（RFC2935Internet Open Trading Protocol (IOTP) HTTP Supplement）本備忘錄的狀態(tài)本文檔定義了一種Internet社社區(qū)的Internet標(biāo)標(biāo)準(zhǔn)跟蹤協(xié)議，它它需要進(jìn)一步進(jìn)行行討論和建議以得得到改進(jìn)。請參考考最新版的“Internet正正式協(xié)議標(biāo)準(zhǔn)” (STD1)來獲得本協(xié)議的的標(biāo)準(zhǔn)化程度和狀狀態(tài)。本備忘錄的的發(fā)布不受任何限限制。版權(quán)聲明

3、：Copyright (C) The Internet Society (2000). All Rights Reserved.摘要Internet開放放貿(mào)易協(xié)議(IOTP)消息將以可擴(kuò)展展標(biāo)記語言(XML)文檔作為傳輸載載體。就其本身而而論，映象至傳輸輸層的目的是為了了保證底層的XML文文檔在不同的層間間正確地傳輸。此文檔描述了超文本傳傳輸協(xié)議(HTTP), Versions 1.0 and 1.1.的映象象。目錄TOC o 1-3 h z HYPERLINK l _Toc528586410 1介紹 PAGEREF _Toc528586410 h 2 HYPERLINK l _Toc5285

4、86411 2HTTP服務(wù)器和客戶戶端 PAGEREF _Toc528586411 h 2 HYPERLINK l _Toc528586412 3HTTP網(wǎng)絡(luò)位置 PAGEREF _Toc528586412 h 3 HYPERLINK l _Toc528586413 4客戶 PAGEREF _Toc528586413 h 3 4.1 開開啟IOTP客戶端和和商業(yè)IOTP服務(wù)器 3 4.2 傳傳送中的IOTP消息 3 4.3 中斷一個IOTP交易 4 HYPERLINK l _Toc528586414 5開始交付處理器和遞遞交器IOTP服務(wù)器 PAGEREF _Toc528586414 h 5

5、HYPERLINK l _Toc528586415 6安全考慮 PAGEREF _Toc528586415 h 6 HYPERLINK l _Toc528586416 7IANA的考慮 PAGEREF _Toc528586416 h 6 HYPERLINK l _Toc528586417 8參考 PAGEREF _Toc528586417 h 7 HYPERLINK l _Toc528586418 9作者地址 PAGEREF _Toc528586418 h 8 HYPERLINK l _Toc528586419 10完整的版權(quán)聲明明 PAGEREF _Toc528586419 h 8 HYPE

6、RLINK l _Toc528586420 鳴謝 PAGEREF _Toc528586420 h 91介紹Internet開放放貿(mào)易協(xié)議(IOTP)消息將以可擴(kuò)展展標(biāo)記語言XML文檔作為傳輸載載體。就其本身而而論，映象至傳傳輸層的目的是為為了保證底層的XML文文檔在不同的層間間正確地傳輸。此文檔描述了超文本傳傳輸協(xié)議(HTTP), Versions 1.0 and 1.1的映象RFCs 1945, 2616。將來可能會有描述關(guān)于于email（SMTP）、TCP、cable TV或者其它傳傳輸方面的IOTP文檔 。在本文檔中的關(guān)鍵字“必須”, “決不要”, “必須的”,“將要”, “不會”, “

7、應(yīng)當(dāng)”, “不應(yīng)當(dāng)”, “建議”, “可以”, 和 “可選的” 將會在RFC2119文檔中給予說明明。2HTTP服務(wù)器和和客戶端IOTP的結(jié)構(gòu)以如下下方式映象到HTTP的的結(jié)構(gòu)：商家、付款處理器、交交貨處理器，以及及客戶相關(guān)的交易易方都由HTTP服服務(wù)器代表。每一一方都可以是由一一臺獨立的服務(wù)器器代表，也可以是是以某種聯(lián)接方式式結(jié)合?？蛻艚巧蒆TTP客客戶端代表。注意: 一個商人也會會充當(dāng)消費者的職職能,比如說他要要儲存電子貨幣。在在這種情況下，商商人作為一個組織織而非單一的職能能，需要一個HTTP客客戶端支持。3HTTP網(wǎng)絡(luò)位置置包含在IOTP規(guī)格書書中的網(wǎng)絡(luò)位置皆皆為URIs （Unif

8、orm Resource Identifiers）RFC 2396。如果必須要或者是要求使用安全連接的話，就必須用一個對HTTP服務(wù)器以及客戶端都支持的安全通道。 像SSL version 3 或者 TLS RFC 2246都可以用作這種通道。4客戶在大多數(shù)環(huán)境中，客戶戶的最初的媒介總總是一個HTML瀏瀏覽器?？墒悄?，現(xiàn)現(xiàn)有的瀏覽器都沒沒有提供足夠的功功能，來為客戶充充當(dāng)媒介完成一次次IOTP交易。這這就帶來了倆個必必須滿足的條件：一個開啟IOTP客戶戶端并控制權(quán)轉(zhuǎn)交交給IOTP客戶戶端的方法，以及及一個在IOTP交交易結(jié)束后安全停停止IOTP客戶戶端并將控制權(quán)轉(zhuǎn)轉(zhuǎn)交給HTML瀏瀏覽器的方法。

9、 開始IOTP客戶端端以及商業(yè)IOTP服服務(wù)器 在某些情況下，用用戶方的HTTP客客戶端會發(fā)送一個個HTTP請求，這這個請求被商業(yè)HTTP服服務(wù)器解釋為一個個“IOTP啟動請請求”。比如說當(dāng)你單單擊“付款”按鈕時，就會達(dá)達(dá)到這樣的效果。這這個消息就是某種種形式的請求消息息的“替身”，并且，商業(yè)服服務(wù)器會以XML文文檔的形式對這個個第一個IOTP消消息作出響應(yīng)。對所有IOTP消息的的MIME協(xié)議格格式為：“APPLICATION/IOTP”；然而，“APPLICATION/X-IOT”已經(jīng)被應(yīng)用于實驗室和開發(fā)中了，這一點應(yīng)該得到認(rèn)可。要得到APPLICATION/IOTP的MIME協(xié)議格式的注冊

10、模板，請參見下面第7部分的內(nèi)容。因為HTTP完全是二進(jìn)制編碼，所以不需要對要傳輸?shù)膬?nèi)容進(jìn)行傳輸編碼。（參見RFC 2376修訂版，application/xml格式，它也有一些類似的考慮。） HTML瀏覽覽器會將這個HTTP響響應(yīng)解釋為開啟與與MIME協(xié)議類類型“APPLICATION/IOTP” 相關(guān)的應(yīng)用程程序的一個響應(yīng)，并并把這個消息的內(nèi)內(nèi)容發(fā)送給應(yīng)用程程序。 就在這一時刻刻，IOTP客戶戶端就會被啟動，并并獲得第一個消息息。 IOTP消息息的生存期是短暫暫的，因此，HTTP服服務(wù)器應(yīng)當(dāng)避免將將其響應(yīng)放到緩存存區(qū)中。在HTTP V1.0當(dāng)中，我們可以使用“nocache”注記符來使響應(yīng)不

11、被放到緩存區(qū)中。而當(dāng)我們使用的是SSL/TLS安全連接時，就可以不考慮這個問題，因為它不帶有緩沖區(qū)；還有，在HTTP v1.1 中HTTP發(fā)送請求也一樣不用考慮緩沖區(qū)問題，因為在HTTP v1.1中發(fā)送請求是不會被放到緩沖區(qū)中的。傳送中的IOTP消息息在一次交易中，先發(fā)送送出去的IOTP消消息中的數(shù)據(jù)必須須要由IOTP客客戶端保留下來，這這樣做的目的是：（1）拷貝下來的數(shù)據(jù)據(jù)作為后續(xù)IOTP消消息的組成部分；（2）用于在后續(xù)IOTP消消息中驗證簽名的的計算；（3）在某些情況下，當(dāng)當(dāng)請求沒有得到響響應(yīng)而超時時需要要重新發(fā)送；（4）在最新的IOTP版版本中用作客戶相相關(guān)交易方的輸入入，等等拷貝的具

12、體方式由特定定的IOTP交易易決定。不管交易易最終是失敗、成成功還是被取消，這這些數(shù)據(jù)都必須保保留到IOTP交交易的最后，并且且在交易之后，還還要保留，直到交交易的任何一方都都不想再去查詢它它為止。IOTP 消息包含了了網(wǎng)絡(luò)位置信息（比比如說PayReqNetLocn），HTTP的網(wǎng)絡(luò)位置包含有IOTP客戶端要發(fā)送IOTP消息的目的地址的URIs。后面的IOTP消息（皆皆是XML文檔）是是通過使用HTTP的的POST函數(shù)發(fā)發(fā)送的。HTTP客客戶端必須要執(zhí)行行所有的HTTP的的POST請求。XML文檔必須通過一一種與外部編碼所所兼容的方式來發(fā)發(fā)送，當(dāng)然，這種種外部編碼是符合合XML XML規(guī)格的

13、。 中止一個IOTP交交易下面所講述的內(nèi)容，讀讀者可以結(jié)合RFC 2801文檔檔來閱讀。當(dāng)出現(xiàn)以下情形時，一一筆IOTP交易易就算完成了： - 當(dāng)IOTP客客戶端由于某些原原因決定放棄這筆筆IOTP交易，也也可能是由于客戶戶要撤銷這筆交易易，或者是在接收收IOTP消息過過程中出現(xiàn)錯誤的的結(jié)果?；蛘弋?dāng)： -出現(xiàn)“超時時”錯誤或者是連接接失敗，比如說，在在用戶定義的響應(yīng)應(yīng)時間范圍內(nèi)，接接收方?jīng)]有收到對對一個特定IOTP消消息的響應(yīng)（包括括重發(fā)信息）。一個執(zhí)行IOTP交易易的IOTP客戶戶端，此交易： - 若成功完完成（也就是說，沒沒有接收到有HardError的錯誤塊或者是取消塊），它必須指示瀏覽

14、器連向在協(xié)議選項組件中定義在SuccessNetLocn里面的網(wǎng)絡(luò)位置，也就是說，讓瀏覽器去對這個URL做一個HTTP GET請求。 -若是因為收收到一些錯誤交易易塊而使交易沒有有成功的話，它必必須要將這些信息息顯示在錯誤消息息中，中止這筆交交易，并將控制權(quán)權(quán)交給瀏覽器，這這樣它就會對Error網(wǎng)絡(luò)地地址發(fā)送一個GET請請求，此地址詳細(xì)細(xì)指明了錯誤是由由哪一方引起的。 - 若是因為為收到了取消塊而而使交易被迫取消消了，必須要中止止此IOTP交易易并將控制權(quán)交給給瀏覽器，以讓瀏瀏覽器對Cancel網(wǎng)絡(luò)絡(luò)地址發(fā)送一個GET請請求，此地址詳細(xì)細(xì)指明了取消塊是是從哪一方發(fā)出來來的。 - 若是由于于一個

15、IOTP消消息不符合所要求求的規(guī)格而發(fā)生錯錯誤，必須發(fā)送一一個包含錯誤交易易塊的IOTP消消息到導(dǎo)致此錯誤誤消息的交易方（此此交易方由ErrorLogNetLoc定義），并中止此IOTP交易，再將控制權(quán)移交給瀏覽器，這樣這樣它就會對Error網(wǎng)絡(luò)地址發(fā)送一個GET請求，此地址詳細(xì)指明了錯誤是由哪一方引起的。 - 如果是“超時”的話，就必須顯顯示一個消息來說說明是超時?？梢砸越o用戶提供幾個個可選項：取消、重試或者是自動動重試。如果由于于超時導(dǎo)致交易失失敗，按照上面所所講的交易“錯誤”做處理。 每一個IOTP客客戶端實現(xiàn)都要考考慮是否當(dāng)完成一一個IOTP交易易后要立刻終止掉掉IOTP客戶端端應(yīng)用程

16、序，或者者是要一直等到由由于某種情況而被被關(guān)掉，比如說是是用戶關(guān)閉或者是是瀏覽器關(guān)閉。5開始交付處理器和和遞交器IOTP服服務(wù)器 當(dāng)付款處理器器和交貨器IOTP服服務(wù)器收到包含下下列信息的消息時時，它就開始工作作： - 對于一個個付款處理器，有有一個付款請求塊塊, 以及 - 對于一個個交貨處理器，有有一個交貨請求塊塊6安全考慮 Internet開開放貿(mào)易協(xié)議(IOTP)消息的安全防護(hù)護(hù)主要是靠IOTP內(nèi)內(nèi)部的簽名，這在在RFC 2801 和 RFC 2802文檔中有詳細(xì)描描述。 可以通過使用用一個安全的通道道來傳輸IOTP消消息，比如說SSL/TLS RFC 2246，以以達(dá)到IOTP交交互中

17、的保密性保保護(hù)的目的。 要注意的是，由由IOTP傳輸?shù)牡母犊顓f(xié)議的安全全是付款協(xié)議的職職責(zé)，而非IOTP的的職責(zé)。7IANA的考慮 This specification defines the APPLICATION/IOTP MIME type. The registration template is as follows RFC 2048: To: ietf-types Subject: Registration of MIME media type APPLICATION/IOTP MIME media type name: APPLICATION MIME subtype name:

18、 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. Security considerations: IOTP i

19、ncludes provisions for digital authentication but for confidentiality, other mechanisms such as TLS should be used. See RFC 2801 and RFC 2802. Interoperability considerations: See RFC 2801. Published specification: See RFC 2801 and RFC 2802. Applications which use this media type: Internet Open Trad

20、ing Protocol applications. Additional information: (none) Person & email address to contact for further information: Name: Donald E. Eastlake 3rd Email: Donald.Eastlake Intended usage: COMMON Author/Change controller: IETF8參考RFC 1945 Berners-Lee, T., Fielding, R. and H. Frystyk, HypertextTransfer Pr

21、otocol - HTTP/1.0, RFC 1945, May 1996.RFC 2048 Freed, N., Klensin, J. and J. Postel, MultipurposeInternet Mail Extensions (MIME) Part Four: RegistrationProcedure, RFC 2048, November 1996.RFC 2119 Bradner, S., Key words for use in RFCs to IndicateRequirement Levels, BCP 14, RFC 2119, March 1997.RFC 2

22、246 Dierks, T. and C. Allen, The TLS Protocol Version 1.0,RFC 2246, January 1999.RFC 2376 Whitehead, E. and M. Murata, XML Media Types, RFC 2376,July 1998.RFC 2396 Berners-Lee, T., Rielding, R. and L. Masinter, UniformResource Identifiers (URI): Generic Syntax, RFC 2396,August 1998.RFC 2616 Fielding

23、, R., Gettys, J., Mogul, J., Frystyk, H.,Masinter, L., Leach, P. and T. Berners-Lee, HypertextTransfer Protocol - HTTP/1.1, RFC 2616, June 1999.RFC 2801 Burdett, D., Internet Open Trading Protocol - IOTPVersion 1.0, RFC 2801, April 2000.RFC 2802 Davidson, K. and Y. Kawatsura, Digital Signatures for

24、thev1.0 Internet Open Trading Protocol (IOTP), RFC 2802,April 2000XML Bray, T., Paoli, J. and C. Sperberg-McQueen, ExtensibleMarkup Language (XML) 1.0 ,February 1998.9作者地址 Donald E. Eastlake 3rd Motorola 140 Forest Avenue Hudson, MA 01749 USA Phone: +1 978-562-2827(h) +1 508-261-5434(w) Fax: +1 508-

25、261-4447(w) EMail: Donald.Eastlake Chris J. Smith Royal Bank of Canada 277 Front Street West Toronto, Ontario M5V 3A4 CANADA Phone: +1 416-348-6090 Fax: +1 416-348-2210 EMail: chris.smith10完整的版權(quán)聲明明 Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it m

26、ay 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