本備忘錄的狀態
本文檔定義了一種Internet社區的Internet標準跟蹤協議，它需要進一步進行討論和建
議以得到改進。請參考最新版的“Internet正式協議標準”(STD1)來獲得本協議的標
準化程度和狀態。本備忘錄的發布不受任何限制。

版權聲明：
Copyright(C)TheInternetSociety(2000).AllRightsReserved.

摘要

Internet開放貿易協議(IOTP)消息將以可擴展標記語言(xml)文檔作為傳輸載體。
就其本身而論，映象至傳輸層的目的是為了保證底層的XML文檔在不同的層間正確地傳
輸。
此文檔描述了超文本傳輸協議(HTTP),Versions1.0and1.1.的映象。





目錄

1．介紹 2
2．HTTP服務器和客戶端 2
3．HTTP網絡位置 3
4．客戶 3
4.1開啟IOTP客戶端和商業IOTP服務器3
4.2傳送中的IOTP消息3
4.3中斷一個IOTP交易4
5．開始交付處理器和遞交器IOTP服務器 5
6．安全考慮 6
7．IANA的考慮 6
8．參考 7
9．作者地址 8
10．完整的版權聲明 8
鳴謝 9

























1．介紹
Internet開放貿易協議(IOTP)消息將以可擴展標記語言[XML]文檔作為傳輸載
體。就其本身而論，，映象至傳輸層的目的是為了保證底層的XML文檔在不同的層
間正確地傳輸。
此文檔描述了超文本傳輸協議(HTTP),Versions1.0and1.1的映象[RFCs
1945,2616]。
將來可能會有描述關于email（SMTP）、TCP、cableTV或者其它傳輸方面的
IOTP文檔。
在本文檔中的要害字“必須”,“決不要”,“必須的”,“將要”,“不會”,
“應當”,“不應當”,“建議”,“可以”,和“可選的”將會在[RFC2119]
文檔中給予說明。

2．HTTP服務器和客戶端
IOTP的結構以如下方式映象到HTTP的結構：

商家、付款處理器、交貨處理器，以及客戶相關的交易方都由HTTP服務器代
表。每一方都可以是由一臺獨立的服務器代表，也可以是以某種聯接方式結合。
客戶角色由HTTP客戶端代表。

注重:一個商人也會充當消費者的職能,比如說他要儲存電子貨幣。在這種情況下，商
人作為一個組織而非單一的職能，需要一個HTTP客戶端支持。

3．HTTP網絡位置

包含在IOTP規格書中的網絡位置皆為URIs（UniformResourceIdentifiers）[RFC
2396]。假如必須要或者是要求使用安全連接的話，就必須用一個對HTTP服務器以及客戶端
都支持的安全通道。像SSLversion3或者TLS[RFC2246]都可以用作這種通道。

4．客戶

在大多數環境中，客戶的最初的媒介總是一個Html瀏覽器。可是呢，現有的瀏覽器都
沒有提供足夠的功能，來為客戶充當媒介完成一次IOTP交易。這就帶來了倆個必須滿足的
條件：
一個開啟IOTP客戶端并控制權轉交給IOTP客戶端的方法，以及一個在IOTP交易結束
后安全停止IOTP客戶端并將控制權轉交給HTML瀏覽器的方法。

4.1 開始IOTP客戶端以及商業IOTP服務器

在某些情況下，用戶方的HTTP客戶端會發送一個HTTP請求，這個請求被商業HTTP服
務器解釋為一個“IOTP啟動請求”。比如說當你單擊“付款”按鈕時，就會達到這樣的效
果。這個消息就是某種形式的請求消息的“替身”，并且，商業服務器會以XML文檔的形式
對這個第一個IOTP消息作出響應。
對所有IOTP消息的MIME協議格式為：“application/IOTP”；然而，“APPLICATION/X-IOT”
已經被應用于實驗室和開發中了，這一點應該得到認可。要得到APPLICATION/IOTP的MIME
協議格式的注冊模板，請參見下面第7部分的內容。因為HTTP完全是二進制編碼，所以不
需要對要傳輸的內容進行傳輸編碼。（參見[RFC2376]修訂版，application/xml格式，它
也有一些類似的考慮。）
HTML瀏覽器會將這個HTTP響應解釋為開啟與MIME協議類型“APPLICATION/IOTP”相
關的應用程序的一個響應，并把這個消息的內容發送給應用程序。
就在這一時刻，IOTP客戶端就會被啟動，并獲得第一個消息。
IOTP消息的生存期是短暫的，因此，HTTP服務器應當避免將其響應放到緩存區中。在
HTTPV1.0當中，我們可以使用“nocache”注記符來使響應不被放到緩存區中。而當我們
使用的是SSL/TLS安全連接時，就可以不考慮這個問題，因為它不帶有緩沖區；還有，在
HTTPv1.1中HTTP發送請求也一樣不用考慮緩沖區問題，因為在HTTPv1.1中發送請求是
不會被放到緩沖區中的。

4.2 傳送中的IOTP消息

在一次交易中，先發送出去的IOTP消息中的數據必須要由IOTP客戶端保留下來，這樣
做的目的是：
（1）拷貝下來的數據作為后續IOTP消息的組成部分；
（2）用于在后續IOTP消息中驗證簽名的計算；
（3）在某些情況下，當請求沒有得到響應而超時時需要重新發送；
（4）在最新的IOTP版本中用作客戶相關交易方的輸入，等等……
拷貝的具體方式由特定的IOTP交易決定。不管交易最終是失敗、成功還是被取消，這
些數據都必須保留到IOTP交易的最后，并且在交易之后，還要保留，直到交易的任何一方
都不想再去查詢它為止。
IOTP消息包含了網絡位置信息（比如說PayReqNetLocn），HTTP的網絡位置包含有IOTP
客戶端要發送IOTP消息的目的地址的URIs。
后面的IOTP消息（皆是XML文檔）是通過使用HTTP的POST函數發送的。HTTP客戶端
必須要執行所有的HTTP的POST請求。
XML文檔必須通過一種與外部編碼所兼容的方式來發送，當然，這種外部編碼是符合XML
[XML]規格的。

4.3 中止一個IOTP交易

下面所講述的內容，讀者可以結合[RFC2801]文檔來閱讀。
當出現以下情形時，一筆IOTP交易就算完成了：

--當IOTP客戶端由于某些原因決定放棄這筆IOTP交易，也可能是由于客戶要撤銷這筆
交易，或者是在接收IOTP消息過程中出現錯誤的結果。或者當：
--出現“超時”錯誤或者是連接失敗，比如說，在用戶定義的響應時間范圍內，接收方
沒有收到對一個特定IOTP消息的響應（包括重發信息）。

一個執行IOTP交易的IOTP客戶端，此交易：

--若成功完成（也就是說，沒有接收到有HardError的錯誤塊或者是取消塊），它必須
指示瀏覽器連向在協議選項組件中定義在SUCcessNetLocn里面的網絡位置，也就是說，讓
瀏覽器去對這個URL做一個HTTPGET請求。
--若是因為收到一些錯誤交易塊而使交易沒有成功的話，它必須要將這些信息顯示在錯
誤消息中，中止這筆交易，并將控制權交給瀏覽器，這樣它就會對Error網絡地址發送一個
GET請求，此地址具體指明了錯誤是由哪一方引起的。
--若是因為收到了取消塊而使交易被迫取消了，必須要中止此IOTP交易并將控制權交
給瀏覽器，以讓瀏覽器對Cancel網絡地址發送一個GET請求，此地址具體指明了取消塊是
從哪一方發出來的。
--若是由于一個IOTP消息不符合所要求的規格而發生錯誤，必須發送一個包含錯誤交
易塊的IOTP消息到導致此錯誤消息的交易方（此交易方由ErrorLogNetLoc定義），并中止
此IOTP交易，再將控制權移交給瀏覽器，這樣這樣它就會對Error網絡地址發送一個GET
請求，此地址具體指明了錯誤是由哪一方引起的。
--假如是“超時”的話，就必須顯示一個消息來說明是超時。可以給用戶提供幾個可選
項：取消、重試或者是自動重試。假如由于超時導致交易失敗，按照上面所講的交易“錯誤”
做處理。

每一個IOTP客戶端實現都要考慮是否當完成一個IOTP交易后要馬上終止掉IOTP客戶
端應用程序，或者是要一直等到由于某種情況而被關掉，比如說是用戶關閉或者是瀏覽器關
閉。

5．開始交付處理器和遞交器IOTP服務器

當付款處理器和交貨器IOTP服務器收到包含下列信息的消息時，它就開始工作：

--對于一個付款處理器，有一個付款請求塊,以及

--對于一個交貨處理器，有一個交貨請求塊
6．安全考慮

Internet開放貿易協議(IOTP)消息的安全防護主要是靠IOTP內部的簽名，這在[RFC
2801]和[RFC2802]文檔中有具體描述。可以通過使用一個安全的通道來傳輸IOTP消息，
比如說SSL/TLS[RFC2246]，以達到IOTP交互中的保密性保護的目的。

要注重的是，由IOTP傳輸的付款協議的安全是付款協議的職責，而非IOTP的職責。

7．IANA的考慮

ThisspecificationdefinestheAPPLICATION/IOTPMIMEtype.The
registrationtemplateisasfollows[RFC2048]:

To:ietf-types@iana.org

Subject:RegistrationofMIMEmediatypeAPPLICATION/IOTP

MIMEmediatypename:APPLICATION

MIMEsuBTypename:IOTP

Requiredparameters:(none)

Optionalparameters:charset-seeRFC2376

Encodingconsiderations:ContentisXMLandmayinsomecases
requirequotedPRintableorbase64encoding.However,noencoding
isrequiredforHTTPtransportwhichiseXPectedtobecommon.

Securityconsiderations:IOTPincludesprovisionsfordigital
authenticationbutforconfidentiality,othermechanismssuchas
TLSshouldbeused.SeeRFC2801andRFC2802.

InterOperabilityconsiderations:SeeRFC2801.

Publishedspecification:SeeRFC2801andRFC2802.

Applicationswhichusethismediatype:InternetOpenTrading
Protocolapplications.

Additionalinformation:(none)

Person&emailaddresstocontactforfurtherinformation:
Name:DonaldE.Eastlake3rd
Email:Donald.Eastlake@motorola.com

Intendedusage:COMMON

Author/Changecontroller:IETF

8．參考

[RFC1945]Berners-Lee,T.,Fielding,R.andH.Frystyk,"Hypertext
TransferProtocol--HTTP/1.0",RFC1945,May1996.

[RFC2048]Freed,N.,Klensin,J.andJ.Postel,"Multipurpose
InternetMailExtensions(MIME)PartFour:Registration
Procedure",RFC2048,November1996.

[RFC2119]Bradner,S.,"KeyWordsforuseinRFCstoIndicate
RequirementLevels",BCP14,RFC2119,March1997.

[RFC2246]Dierks,T.andC.Allen,"TheTLSProtocolVersion1.0",
RFC2246,January1999.

[RFC2376]Whitehead,E.andM.Murata,"XMLMediaTypes",RFC2376,
July1998.

[RFC2396]Berners-Lee,T.,Rielding,R.andL.Masinter,"Uniform
ResourceIdentifiers(URI):GenericSyntax",RFC2396,
August1998.

[RFC2616]Fielding,R.,Gettys,J.,Mogul,J.,Frystyk,H.,
Masinter,L.,Leach,P.andT.Berners-Lee,"Hypertext
TransferProtocol--HTTP/1.1",RFC2616,June1999.

[RFC2801]Burdett,D.,"InternetOpenTradingProtocol-IOTP
Version1.0",RFC2801,April2000.

[RFC2802]Davidson,K.andY.Kawatsura,"DigitalSignaturesforthe
v1.0InternetOpenTradingProtocol(IOTP)",RFC2802,
April2000

[XML]Bray,T.,Paoli,J.andC.Sperberg-McQueen,"Extensible
MarkupLanguage(XML)1.0"<http://www.w3.org/TR/REC-xml>,
February1998.

9．作者地址

DonaldE.Eastlake3rd
Motorola
140ForestAvenue
Hudson,MA01749USA

Phone:+1978-562-2827(h)
+1508-261-5434(w)
Fax:+1508-261-4447(w)
EMail:Donald.Eastlake@motorola.com


ChrisJ.Smith
RoyalBanKOFCanada
277FrontStreetWest
Toronto,OntarioM5V3A4CANADA

Phone:+1416-348-6090
Fax:+1416-348-2210
EMail:chris.smith@royalbank.com

10．完整的版權聲明

Copyright(C)TheInternetSociety(2000).AllRightsReserved.

Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseexplainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsuchcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurpoSEOf
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.

Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuccessorsorassigns.

Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.

鳴謝

FundingfortheRFCEditorfunctioniscurrentlyprovidedbythe
InternetSociety.