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

1、.RFC2935Internet Open Trading Protocol (IOTP) Supplement Internet開放貿(mào)易協(xié)議(IOTP) 補(bǔ)充PAGE ：.；PAGE 9RFC文檔中文翻譯方案組織：中國互動(dòng)出版網(wǎng) HYPERLINK china-pub/ china-pub/RFC文檔中文翻譯方案 HYPERLINK china-pub/ china-pub/compters/emook/aboutemook.htm：HYPERLINK mailto:ouyangchina-pubouyangchina-pub譯者：陳貴敏efoxxx HYPERLINK mailto: 譯文

2、發(fā)布時(shí)間：2001-11-4版權(quán)：本中文翻譯文檔版權(quán)歸中國互動(dòng)出版網(wǎng)一切?？梢杂糜诜巧虡I(yè)用途自在轉(zhuǎn)載，但必需保管本文檔的翻譯及版權(quán)信息。Network Working Group D. EastlakeRequest for Comments: 2935 MotorolaCategory: Standards Track C. Smith Royal Bank of Canada September 2000Internet開放貿(mào)易協(xié)議(IOTP) 補(bǔ)充RFC2935Internet Open Trading Protocol (IOTP) Supplement本備忘錄的形狀本文檔定義了一種I

3、nternet社區(qū)的Internet規(guī)范跟蹤協(xié)議，它需求進(jìn)一步進(jìn)展討論和建議以得到改良。請(qǐng)參考最新版的“Internet正式協(xié)議規(guī)范 (STD1)來獲得本協(xié)議的規(guī)范化程度和形狀。本備忘錄的發(fā)布不受任何限制。版權(quán)聲明：Copyright (C) The Internet Society (2000). All Rights Reserved.摘要Internet開放貿(mào)易協(xié)議(IOTP)音訊將以可擴(kuò)展標(biāo)志言語(XML)文檔作為傳輸載體。就其本身而論，映象至傳輸層的目的是為了保證底層的XML文檔在不同的層間正確地傳輸。此文檔描畫了超文本傳輸協(xié)議(), Versions 1.0 and 1.1.的映象

4、。目錄 TOC o 1-3 h z HYPERLINK l _Toc528586410 1引見 PAGEREF _Toc528586410 h 2 HYPERLINK l _Toc528586411 2HTTP效力器和客戶端 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效力器 3 4.2 傳送中的IOTP音訊 3

5、4.3 中斷一個(gè)IOTP買賣 4 HYPERLINK l _Toc528586414 5開場交付處置器和遞交器IOTP效力器 PAGEREF _Toc528586414 h 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作者地址 PAGE

6、REF _Toc528586418 h 8 HYPERLINK l _Toc528586419 10完好的版權(quán)聲明 PAGEREF _Toc528586419 h 8 HYPERLINK l _Toc528586420 鳴謝 PAGEREF _Toc528586420 h 91引見Internet開放貿(mào)易協(xié)議(IOTP)音訊將以可擴(kuò)展標(biāo)志言語XML文檔作為傳輸載體。就其本身而論，映象至傳輸層的目的是為了保證底層的XML文檔在不同的層間正確地傳輸。此文檔描畫了超文本傳輸協(xié)議(), Versions 1.0 and 1.1的映象RFCs 1945, 2616。未來能夠會(huì)有描畫關(guān)于emailSMTP

7、、TCP、cable TV或者其它傳輸方面的IOTP文檔 。在本文檔中的關(guān)鍵字“必需, “決不要, “必需的,“將要, “不會(huì), “該當(dāng), “不該當(dāng), “建議, “可以, 和 “可選的 將會(huì)在RFC2119文檔中給予闡明。2HTTP效力器和客戶端IOTP的構(gòu)造以如下方式映象到HTTP的構(gòu)造：商家、付款處置器、交貨處置器，以及客戶相關(guān)的買賣方都由HTTP效力器代表。每一方都可以是由一臺(tái)獨(dú)立的效力器代表，也可以是以某種聯(lián)接方式結(jié)合?？蛻艚巧蒆TTP客戶端代表。留意: 一個(gè)商人也會(huì)充任消費(fèi)者的職能,比如說他要儲(chǔ)存電子貨幣。在這種情況下，商人作為一個(gè)組織而非單一的職能，需求一個(gè)HTTP客戶端支持。3

8、HTTP網(wǎng)絡(luò)位置包含在IOTP規(guī)格書中的網(wǎng)絡(luò)位置皆為URIs Uniform Resource IdentifiersRFC 2396。假設(shè)必需求或者是要求運(yùn)用平安銜接的話，就必需用一個(gè)對(duì)HTTP效力器以及客戶端都支持的平安通道。 像SSL version 3 或者 TLS RFC 2246都可以用作這種通道。4客戶在大多數(shù)環(huán)境中，客戶的最初的媒介總是一個(gè)HTML閱讀器?？墒悄?，現(xiàn)有的閱讀器都沒有提供足夠的功能，來為客戶充任媒介完成一次IOTP買賣。這就帶來了倆個(gè)必需滿足的條件：一個(gè)開啟IOTP客戶端并控制權(quán)轉(zhuǎn)交給IOTP客戶端的方法，以及一個(gè)在IOTP買賣終了后平安停頓IOTP客戶端并將控制

9、權(quán)轉(zhuǎn)交給HTML閱讀器的方法。 開場IOTP客戶端以及商業(yè)IOTP效力器 在某些情況下，用戶方的HTTP客戶端會(huì)發(fā)送一個(gè)HTTP懇求，這個(gè)懇求被商業(yè)HTTP效力器解釋為一個(gè)“IOTP啟動(dòng)懇求。比如說當(dāng)他單擊“付款按鈕時(shí)，就會(huì)到達(dá)這樣的效果。這個(gè)音訊就是某種方式的懇求音訊的“替身，并且，商業(yè)效力器會(huì)以XML文檔的方式對(duì)這個(gè)第一個(gè)IOTP音訊作出呼應(yīng)。對(duì)一切IOTP音訊的MIME協(xié)議格式為：“APPLICATION/IOTP；然而，“APPLICATION/X-IOT曾經(jīng)被運(yùn)用于實(shí)驗(yàn)室和開發(fā)中了，這一點(diǎn)應(yīng)該得到認(rèn)可。要得到APPLICATION/IOTP的MIME協(xié)議格式的注冊(cè)模板，請(qǐng)參見下面第7

10、部分的內(nèi)容。由于HTTP完全是二進(jìn)制編碼，所以不需求對(duì)要傳輸?shù)膬?nèi)容進(jìn)展傳輸編碼。參見RFC 2376修訂版，application/xml格式，它也有一些類似的思索。 HTML閱讀器會(huì)將這個(gè)HTTP呼應(yīng)解釋為開啟與MIME協(xié)議類型“APPLICATION/IOTP 相關(guān)的運(yùn)用程序的一個(gè)呼應(yīng)，并把這個(gè)音訊的內(nèi)容發(fā)送給運(yùn)用程序。 就在這一時(shí)辰，IOTP客戶端就會(huì)被啟動(dòng)，并獲得第一個(gè)音訊。 IOTP音訊的生存期是短暫的，因此，HTTP效力器該當(dāng)防止將其呼應(yīng)放到緩存區(qū)中。在HTTP V1.0當(dāng)中，我們可以運(yùn)用“nocache注記符來使呼應(yīng)不被放到緩存區(qū)中。而當(dāng)我們運(yùn)用的是SSL/TLS平安銜接時(shí)，就可

11、以不思索這個(gè)問題，由于它不帶有緩沖區(qū)；還有，在HTTP v1.1 中HTTP發(fā)送懇求也一樣不用思索緩沖區(qū)問題，由于在HTTP v1.1中發(fā)送懇求是不會(huì)被放到緩沖區(qū)中的。傳送中的IOTP音訊在一次買賣中，先發(fā)送出去的IOTP音訊中的數(shù)據(jù)必需求由IOTP客戶端保管下來，這樣做的目的是：1拷貝下來的數(shù)據(jù)作為后續(xù)IOTP音訊的組成部分；2用于在后續(xù)IOTP音訊中驗(yàn)證簽名的計(jì)算；3在某些情況下，當(dāng)懇求沒有得到呼應(yīng)而超時(shí)時(shí)需求重新發(fā)送；4在最新的IOTP版本中用作客戶相關(guān)買賣方的輸入，等等拷貝的詳細(xì)方式由特定的IOTP買賣決議。不論買賣最終是失敗、勝利還是被取消，這些數(shù)據(jù)都必需保管到IOTP買賣的最后，并

12、且在買賣之后，還要保管，直到買賣的任何一方都不想再去查詢它為止。IOTP 音訊包含了網(wǎng)絡(luò)位置信息比如說PayReqNetLocn，HTTP的網(wǎng)絡(luò)位置包含有IOTP客戶端要發(fā)送IOTP音訊的目的地址的URIs。后面的IOTP音訊皆是XML文檔是經(jīng)過運(yùn)用HTTP的POST函數(shù)發(fā)送的。HTTP客戶端必需求執(zhí)行一切的HTTP的POST懇求。XML文檔必需經(jīng)過一種與外部編碼所兼容的方式來發(fā)送，當(dāng)然，這種外部編碼是符合XML XML規(guī)格的。 中止一個(gè)IOTP買賣下面所講述的內(nèi)容，讀者可以結(jié)合RFC 2801文檔來閱讀。當(dāng)出現(xiàn)以下情形時(shí)，一筆IOTP買賣就算完成了： - 當(dāng)IOTP客戶端由于某些緣由決議放棄

13、這筆IOTP買賣，也能夠是由于客戶要撤銷這筆買賣，或者是在接納IOTP音訊過程中出現(xiàn)錯(cuò)誤的結(jié)果。或者當(dāng)： -出現(xiàn)“超時(shí)錯(cuò)誤或者是銜接失敗，比如說，在用戶定義的呼應(yīng)時(shí)間范圍內(nèi)，接納方?jīng)]有收到對(duì)一個(gè)特定IOTP音訊的呼應(yīng)包括重發(fā)信息。一個(gè)執(zhí)行IOTP買賣的IOTP客戶端，此買賣： - 假設(shè)勝利完成也就是說，沒有接納到有HardError的錯(cuò)誤塊或者是取消塊，它必需指示閱讀器連向在協(xié)議選項(xiàng)組件中定義在SuccessNetLocn里面的網(wǎng)絡(luò)位置，也就是說，讓閱讀器去對(duì)這個(gè)URL做一個(gè)HTTP GET懇求。 -假設(shè)是由于收到一些錯(cuò)誤買賣塊而使買賣沒有勝利的話，它必需求將這些信息顯示在錯(cuò)誤音訊中，中止這筆

14、買賣，并將控制權(quán)交給閱讀器，這樣它就會(huì)對(duì)Error網(wǎng)絡(luò)地址發(fā)送一個(gè)GET懇求，此地址詳細(xì)指明了錯(cuò)誤是由哪一方引起的。 - 假設(shè)是由于收到了取消塊而使買賣被迫取消了，必需求中止此IOTP買賣并將控制權(quán)交給閱讀器，以讓閱讀器對(duì)Cancel網(wǎng)絡(luò)地址發(fā)送一個(gè)GET懇求，此地址詳細(xì)指明了取消塊是從哪一方發(fā)出來的。 - 假設(shè)是由于一個(gè)IOTP音訊不符合所要求的規(guī)格而發(fā)生錯(cuò)誤，必需發(fā)送一個(gè)包含錯(cuò)誤買賣塊的IOTP音訊到導(dǎo)致此錯(cuò)誤音訊的買賣方此買賣方由ErrorLogNetLoc定義，并中止此IOTP買賣，再將控制權(quán)移交給閱讀器，這樣這樣它就會(huì)對(duì)Error網(wǎng)絡(luò)地址發(fā)送一個(gè)GET懇求，此地址詳細(xì)指明了錯(cuò)誤是由哪

15、一方引起的。 - 假設(shè)是“超時(shí)的話，就必需顯示一個(gè)音訊來闡明是超時(shí)?？梢越o用戶提供幾個(gè)可選項(xiàng)：取消、重試或者是自動(dòng)重試。假設(shè)由于超時(shí)導(dǎo)致買賣失敗，按照上面所講的買賣“錯(cuò)誤做處置。 每一個(gè)IOTP客戶端實(shí)現(xiàn)都要思索能否當(dāng)完成一個(gè)IOTP買賣后要立刻終止掉IOTP客戶端運(yùn)用程序，或者是要不斷等到由于某種情況而被關(guān)掉，比如說是用戶封鎖或者是閱讀器封鎖。5開場交付處置器和遞交器IOTP效力器 當(dāng)付款處置器和交貨器IOTP效力器收到包含以下信息的音訊時(shí)，它就開場任務(wù)： - 對(duì)于一個(gè)付款處置器，有一個(gè)付款懇求塊, 以及 - 對(duì)于一個(gè)交貨處置器，有一個(gè)交貨懇求塊6平安思索 Internet開放貿(mào)易協(xié)議(IO

16、TP)音訊的平安防護(hù)主要是靠IOTP內(nèi)部的簽名，這在RFC 2801 和 RFC 2802文檔中有詳細(xì)描畫。 可以經(jīng)過運(yùn)用一個(gè)平安的通道來傳輸IOTP音訊，比如說SSL/TLS RFC 2246，以到達(dá)IOTP交互中的嚴(yán)密性維護(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:

17、 Registration of MIME media type APPLICATION/IOTP MIME media type name: APPLICATION MIME subtype name: 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 e

18、ncoding is required for transport which is expected to be common. 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. Interoperability considerations: See RFC 2801. Published spe

19、cification: See RFC 2801 and RFC 2802. Applications which use this media type: Internet Open Trading Protocol applications. Additional information: (none) Person & address to contact for further information: Name: Donald E. Eastlake 3rd : Donald.Eastlakemotorola Intended usage: COMMON Author/Change

20、controller: IETF8參考RFC 1945 Berners-Lee, T., Fielding, R. and H. Frystyk, HypertextTransfer Protocol - /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., K

21、ey words for use in RFCs to IndicateRequirement Levels, BCP 14, RFC 2119, March 1997.RFC 2246 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,

22、 UniformResource Identifiers (URI): Generic Syntax, RFC 2396,August 1998.RFC 2616 Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,Masinter, L., Leach, P. and T. Berners-Lee, HypertextTransfer Protocol - /1.1, RFC 2616, June 1999.RFC 2801 Burdett, D., Internet Open Trading Protocol - IOTPVersion 1.0

23、, RFC 2801, April 2000.RFC 2802 Davidson, K. and Y. Kawatsura, Digital Signatures for 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

24、 Avenue Hudson, MA 01749 USA Phone: +1 978-562-2827(h) +1 508-261-5434(w) Fax: +1 508-261-4447(w) : Donald.Eastlakemotorola 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 : chris.smithroyalbank10完好的版權(quán)聲明 Copyright

25、(C) The Internet Society (2000). All Rights Reserved. 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