draft-ietf-trade-iotp-http-00.txt   draft-ietf-trade-iotp-http-01.txt 
INTERNET-DRAFT IOTP HTTP Supplement INTERNET-DRAFT IOTP HTTP Supplement
November 1998 February 1999
Expires May 1999 Expires August 1999
Internet Open Trading Protocol (IOTP) HTTP Supplement Internet Open Trading Protocol (IOTP) HTTP Supplement
-------- ---- ------- -------- ------ ---- ---------- -------- ---- ------- -------- ------ ---- ----------
Donald E. Eastlake 3rd Donald E. Eastlake 3rd
Chris J. Smith Chris J. Smith
Status of This Document Status of This Document
This draft, file name draft-ietf-trade-iotp-http-00.txt, is intended This draft, file name draft-ietf-trade-iotp-http-01.txt, is intended
to become a Proposed Standard RFC. Distribution of this document is to become a Proposed Standard RFC. Distribution of this document is
unlimited. Comments should be sent to the TRADE WG mailing list unlimited. Comments should be sent to the TRADE WG mailing list
<ietf-trade@eListX.com> or to the authors. <ietf-trade@eListX.com> or to the authors.
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months. Internet-Drafts may be updated, replaced, or obsoleted by and may be updated, replaced, or obsoleted by other documents at any
other documents at any time. It is not appropriate to use Internet- time. It is inappropriate to use Internet- Drafts as reference
Drafts as reference material or to cite them other than as a material or to cite them other than as "work in progress".
``working draft'' or ``work in progress.''
To view the entire list of current Internet-Drafts, please check the The list of current Internet-Drafts can be accessed at
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Shadow Directories can be accessed at
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific http://www.ietf.org/shadow.html.
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract Abstract
Internet Open Trading Protocol (IOTP) messages will be carried as XML Internet Open Trading Protocol (IOTP) messages will be carried as XML
documents. As such, the goal of mapping to the transport layer is to documents. As such, the goal of mapping to the transport layer is to
ensure that the underlying XML documents are carried successfully ensure that the underlying XML documents are carried successfully
between the various parties. between the various parties.
This documents describes that mapping for the Hyper Text Transport This documents describes that mapping for the Hyper Text Transport
Protocol (HTTP), Versions 1.0 and 1.1. Protocol (HTTP), Versions 1.0 and 1.1.
skipping to change at page 2, line 31 skipping to change at page 2, line 31
1. Introduction............................................3 1. Introduction............................................3
2. HTTP Servers and Clients................................3 2. HTTP Servers and Clients................................3
3. HTTP Net Locations......................................3 3. HTTP Net Locations......................................3
4. Consumer Clients........................................3 4. Consumer Clients........................................3
4.1 Starting the IOTP Client and the Merchant IOTP Server..4 4.1 Starting the IOTP Client and the Merchant IOTP Server..4
4.2 Ongoing IOTP Messages..................................4 4.2 Ongoing IOTP Messages..................................4
4.3 Stopping an IOTP Transaction...........................5 4.3 Stopping an IOTP Transaction...........................5
5. Starting the Payment handler and Deliverer IOTP Servers.6 5. Starting the Payment handler and Deliverer IOTP Servers.6
6. Security Considerations.................................6 6. Security Considerations.................................6
7. IANA Considerations.....................................6
References.................................................7 References.................................................7
Authors Addresses..........................................7 Authors Addresses..........................................7
Expiration and File Name...................................7 Expiration and File Name...................................8
1. Introduction 1. Introduction
Internet Open Trading Protocol (IOTP) messages will be carried as XML Internet Open Trading Protocol (IOTP) messages will be carried as XML
documents. As such, the goal of mapping to the transport layer is to documents. As such, the goal of mapping to the transport layer is to
ensure that the underlying XML documents are carried successfully ensure that the underlying XML documents are carried successfully
between the various parties. between the various parties.
This documents describes that mapping for the Hyper Text Transport This documents describes that mapping for the Hyper Text Transport
Protocol (HTTP), Versions 1.0 and 1.1 [RFCs 1945, 2068]. Protocol (HTTP), Versions 1.0 and 1.1 [RFCs 1945, 2068].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. HTTP Servers and Clients 2. HTTP Servers and Clients
The structure of IOTP maps on to the structure of HTTP in the The structure of IOTP maps on to the structure of HTTP in the
following way: following way:
The merchant, payment handler, deliverer, merchant customer care, and The merchant, payment handler, deliverer, merchant customer care, and
payment customer care roles are all represented by HTTP servers. payment customer care roles are all represented by HTTP servers.
Each may be represented by a separate server, or they may be Each may be represented by a separate server, or they may be
combined in any combination. combined in any combination.
The consumer role is represented by an HTTP client. The consumer role is represented by an HTTP client.
Note: A Merchant, may act in the role of a consumer, for example to Note: A Merchant, may act in the role of a consumer, for example to
deposit electronic cash. In this case the Merchant, as an deposit electronic cash. In this case the Merchant, as an
organisation rather than as a role, would need to be supported by an organisation rather than as a role, would need to be supported by an
HTTP client. HTTP client.
3. HTTP Net Locations 3. HTTP Net Locations
The Net Locations contained within the IOTP specification are all The Net Locations contained within the IOTP specification are all
URLs. Any secure channel that both the HTTP Server and Client support URLs [RFC 1738]. If a secure connection is required or desired any
may be used. For example SSL version 3 or TLS [xxx]. secure channel that both the HTTP Server and Client support may be
used, for example SSL version 3 or TLS [RFC 2246].
4. Consumer Clients 4. Consumer Clients
In most environments, the consumer agent will initially be an HTML In most environments, the consumer agent will initially be an HTML
browser. However, this does not provide the needed capability to act browser. However, this does not provide the needed capability to act
as an agent for the consumer for an IOTP transaction. This leads to as an agent for the consumer for an IOTP transaction. This leads to
two requirements: two requirements:
a method of starting and passing control to the IOTP client, and a method of starting and passing control to the IOTP client, and
a method of closing down the IOTP client cleanly and passing control a method of closing down the IOTP client cleanly and passing control
back to the HTML browser once the IOTP Transaction has finished. back to the HTML browser once the IOTP Transaction has finished.
4.1 Starting the IOTP Client and the Merchant IOTP Server 4.1 Starting the IOTP Client and the Merchant IOTP Server
At some point, the HTTP client at the consumer will send a HTTP At some point, the HTTP client at the consumer will send a HTTP
request that is interpreted as an "IOTP Startup Request" by the request that is interpreted as an "IOTP Startup Request" by the
Merchant HTTP server. This message is a stand-in for a request Merchant HTTP server. This might, for example, be the result of
message of some form, and the Merchant Server will respond with the clicking on a "pay" button. This message is a stand-in for a request
first OTP Message in the form of an XML document. message of some form and the Merchant Server will respond with the
first IOTP Message in the form of an XML document.
The MIME type for all IOTP messages is: "application/iotp"; however The MIME type for all IOTP messages is: "application/iotp"; however
"application/x-iotp" has been in use for experimentation and "application/x-iotp" has been in use for experimentation and
development and should also be recognized. development and SHOULD also be recognized. Because HTTP is binary
clean, no content-transfer-encoding is required. (See [RFC 2376] re
the application/xml type which has some similar considerations.)
This HTTP response will be interpreted by the HTML browser as a This HTTP response will be interpreted by the HTML browser as a
request to start the application associated with MIME type request to start the application associated with MIME type
"application/iotp", and to pass the content of this message to that "application/iotp", and to pass the content of this message to that
application. application.
At this point, the IOTP client will be started and have the first At this point, the IOTP client will be started and have the first
message. message.
IOTP messages are short-lived. Therefore, the HTTP server has to IOTP messages are short-lived. Therefore, the HTTP server should
provide accurate expiration dates or to use the HTTP no-proxy pragma, avoid having its responses cahced. In HTTP V1.0, the "nocache"
such that HTTP proxy servers do not store and respond with these pragma can be used. This can be neglected on SSL/TLS secured
messages to other HTTP clients. This cab be neglected on SSL/TLS connections which are not cached and on POST HTTP request in HTTP
secured connections which are not cached. v1.1 as in v1.1 POST responses are not cached.
4.2 Ongoing IOTP Messages 4.2 Ongoing IOTP Messages
Data from earlier IOTP Messages must be retained by the IOTP Client Data from earlier IOTP Messages in a transaction must be retained by
so that it may be copied to make up part of later IOTP Messages, used the IOTP Client so that it may (1) be copied to make up part of later
in caculations to verify signatures in later IOTP message, be resent, IOTP Messages, (2) used in caculations to verify signatures in later
etc. The way in which the data is copied depends on the IOTP IOTP message, (3) be resent in some cases where it is a request that
Transaction. times out, (4) used as input to the Customer Care role in later
versions of IOTP, etc. The way in which the data is copied depends on
the IOTP Transaction.
The IOTP Messages contain Net Locations (e.g. the PayReqNetLocn) The IOTP Messages contain Net Locations (e.g. the PayReqNetLocn)
which for HTTP will contain the URLs to which the IOTP client must which for HTTP will contain the URLs to which the IOTP client must
ship IOTP Messages. ship IOTP Messages.
Subsequent IOTP Messages (XML documents) will be sent using the POST Subsequent IOTP Messages (XML documents) will be sent using the POST
function of HTTP. The HTTP client has to perform full HTTP POST function of HTTP. The HTTP client has to perform full HTTP POST
requests. requests.
The XML documents will be sent in a manner compatible with the The XML documents will be sent in a manner compatible with the
skipping to change at page 5, line 24 skipping to change at page 5, line 32
discovering an error in an IOTP message received, or discovering an error in an IOTP message received, or
-- a "time out" occurs or a connection fails, e.g. a response to an -- a "time out" occurs or a connection fails, e.g. a response to an
IOTP Message, has not been received after some user-defined period IOTP Message, has not been received after some user-defined period
of Time (including retransmissions). of Time (including retransmissions).
An IOTP Client which processes an IOTP Transaction which: An IOTP Client which processes an IOTP Transaction which:
-- completes successfully i.e. it has not received any Fail Trading -- completes successfully i.e. it has not received any Fail Trading
Block, must direct the browser to the Net Location specified in Block, must direct the browser to the Net Location specified in
SuccessNetLocn in the Protocol Options Component SuccessNetLocn in the Protocol Options Component, i.e., cause it
to do a GET with that URL.
-- does not complete successfully, because it has received some Fail -- does not complete successfully, because it has received some Fail
Trading Block must display the information in the Fail Message, Trading Bloc,k must display the information in the Fail Message,
stop the transaction, then pass control to the browser to await a stop the transaction, then pass control to the browser so that it
response to the message will do a GET on the Error Net Location specified for the role
from which the error was received. See draft-ietf-trade-iopt-
v1.0-protocol-*.txt.
-- is cancelled for some reason, sends an IOTP Message containing an -- is cancelled for some reason, sends an IOTP Message containing an
Error Trading Block to the CancelNetLocn contained in the Protocol Error Trading Block to the CancelNetLocn contained in the Protocol
Options Component, stops the IOTP Transaction, and hands control Options Component, stops the IOTP Transaction, and hands control
to the browser to the browser so that it will do a GET on the Cancel Net
Locations specified for the role the cusomer was in communications
with when the cancel occured. See draft-ietf-trade-iopt-v1.0-
protocol-*.txt
-- is in error because an IOTP Message does not conform to this -- is in error because an IOTP Message does not conform to this
specification, sends an IOTP Message containing a Fail Trading specification, sends an IOTP Message containing a Fail Trading
Block to the ErrorNetLocn contained in the Protocol Options Block to role from which the bad message was received and the
Component, stops the IOTP Transaction, and hands control to the ErrorNetLogLoc specified for that role, stops the IOTP
browser Transaction, and hands control to the browser so that it will do a
GET from the Error Net Location specified for the role from which
the bad message was received. See draft-ietf-trade-iopt-v1.0-
protocol-*.txt
-- has a "time out" must display a message describing the time out -- has a "time out", must display a message describing the time out.
and then pass control to the HTML browser. May give the user the option of cancelling or retrying and/or may
automatically retry. On failure due to time out, treat as an
error above.
Each implementation of an IOTP client may decide whether or not to Each implementation of an IOTP client may decide whether or not to
terminate the IOTP Client application immediately upon completing an terminate the IOTP Client application immediately upon completing an
IOTP Transaction or whether to wait until it is closed down as a IOTP Transaction or whether to wait until it is closed down as a
result of, for example, user shut down or browser shut down. result of, for example, user shut down or browser shut down.
5. Starting the Payment handler and Deliverer IOTP Servers 5. Starting the Payment handler and Deliverer IOTP Servers
Payment Handler and Deliverer IOTP Servers are started by receiving Payment Handler and Deliverer IOTP Servers are started by receiving
an IOTP Message which contains: an IOTP Message which contains:
-- for a Payment handler, a Payment Request Block, and -- for a Payment handler, a Payment Request Block, and
-- for a Deliverer, a Delivery Request Block -- for a Deliverer, a Delivery Request Block
6. Security Considerations 6. Security Considerations
Security of Internet Open Trade Protocol messages is primarily Security of Internet Open Trade Protocol messages is primarily
dependent on signatures within IOTP as described in [draft-ietf- dependent on signatures within IOTP as described in [draft-ietf-
trade-iotp-v1.0-protocol-*.txt] and [draft-ietf-trade-xml-sig-*.txt]. trade-iotp-v1.0-protocol-*.txt] and [draft-ietf-trade-iotp-v1.0-
dsig-*.txt].
Note that the security of payment protocols transported by IOTP is Note that the security of payment protocols transported by IOTP is
the responsibility of those payment protocols. the responsibility of those payment protocols, NOT of IOTP.
7. IANA Considerations
This specification defines the application/iotp mime type which is
thereby reserved.
References References
RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0", T. Berners-Lee, RFC 1738 - "Uniform Resource Locators (URL)", T. Berners-Lee, L.
Masinter & M. McCahill. December 1994.
RFC 1945 - "Hypertext Transfer Protocol -- HTTP/1.0", T. Berners-Lee,
R. Fielding & H. Frystyk. May 1996. R. Fielding & H. Frystyk. May 1996.
RFC 2068 - "Hypertext Transfer Protocol -- HTTP/1.1", R. Fielding, J. RFC 2068 - "Hypertext Transfer Protocol -- HTTP/1.1", R. Fielding, J.
Gettys, J. Mogul, H. Frystyk, T. Berners-Lee. January 1997. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee. January 1997.
RFC 2119 - S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
RFC 2246 - "The TLS Protocol Version 1.0", T. Dierks, C. Allen.
January 1999.
RFC 2376 - "XML Media Types", E. Whitehead, M. Murata. July 1998.
draft-ietf-trade-iotp-v1.0-protocol-*.txt - David Burdett draft-ietf-trade-iotp-v1.0-protocol-*.txt - David Burdett
draft-ietf-trade-xml-sig-*.txt - Richard Brown draft-ietf-trade-iotp-v1.0-dsig-*.txt - Kent Davidson
Authors Addresses Authors Addresses
Donald E. Eastlake 3rd Donald E. Eastlake 3rd
IBM IBM
318 Acton Street 65 Shindegan Hill Road
Carlisle, MA 01741 USA Carmel, NY 10512 USA
Telephone: +1 914-276-2668(h)
+1 914-784-7913(w)
FAX: +1 914-784-3833(w)
Telephone: +1 978-287-4877
+1 914-784-7913
FAX: +1 978-371-7148
email: dee3@us.ibm.com email: dee3@us.ibm.com
Chris J. Smith Chris J. Smith
Royal Bank of Canada Royal Bank of Canada
277 Front Street West 277 Front Street West
Toronto, Ontario M5V 3A4 CANADA Toronto, Ontario M5V 3A4 CANADA
Telephone: +1 416-348-6090 Telephone: +1 416-348-6090
FAX: +1 416-348-2210 FAX: +1 416-348-2210
email: chris.smith@royalbank.com email: chris.smith@royalbank.com
Expiration and File Name Expiration and File Name
This draft expires May 1999. This draft expires August 1999.
Its file name is draft-ietf-trade-iotp-http-00.txt. Its file name is draft-ietf-trade-iotp-http-01.txt.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/