draft-ietf-trade-iotp-http-02.txt   draft-ietf-trade-iotp-http-03.txt 
INTERNET-DRAFT IOTP HTTP Supplement INTERNET-DRAFT IOTP HTTP Supplement
August 1999 August 1999
Expires February 2000 Expires February 2000
draft-ietf-trade-iotp-http-03.txt
draft-ietf-trade-iotp-http-02.txt
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-02.txt, is intended This draft, file name draft-ietf-trade-iotp-http-03.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 and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC 2026]. Internet-Drafts are all provisions of Section 10 of [RFC 2026]. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
skipping to change at page 3, line 13 skipping to change at page 3, line 13
Expiration and File Name...................................8 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, 2616].
There may be future documents describing IOTP over email (SMTP), TCP, There may be future documents describing IOTP over email (SMTP), TCP,
cable TV, or other transports. cable TV, or other transports.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. HTTP Servers and Clients 2. HTTP Servers and Clients
skipping to change at page 3, line 35 skipping to change at page 3, line 35
following way: following way:
The merchant, payment handler, delivery handler, and customer care The merchant, payment handler, delivery handler, and customer care
roles are all represented by HTTP servers. Each may be represented roles are all represented by HTTP servers. Each may be represented
by a separate server, or they may be combined in any combination. by a separate server, or they may be 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 organization 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
URIs [RFC 2396]. If a secure connection is required or desired any URIs [RFC 2396]. If a secure connection is required or desired any
secure channel that both the HTTP Server and Client support may be secure channel that both the HTTP Server and Client support may be
used, for example SSL version 3 or TLS [RFC 2246]. used, for example SSL version 3 or TLS [RFC 2246].
4. Consumer Clients 4. Consumer Clients
skipping to change at page 4, line 36 skipping to change at page 4, line 36
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 should IOTP messages are short-lived. Therefore, the HTTP server should
avoid having its responses cahced. In HTTP V1.0, the "nocache" avoid having its responses cached. In HTTP V1.0, the "nocache"
pragma can be used. This can be neglected on SSL/TLS secured pragma can be used. This can be neglected on SSL/TLS secured
connections which are not cached and on HTTP POST requests in HTTP connections which are not cached and on HTTP POST requests in HTTP
v1.1 as in v1.1 POST responses 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 in a transaction must be retained by Data from earlier IOTP Messages in a transaction must be retained by
the IOTP Client so that it may (1) be copied to make up part of later the IOTP Client so that it may (1) be copied to make up part of later
IOTP Messages, (2) used in caculations to verify signatures in later IOTP Messages, (2) used in calculations to verify signatures in later
IOTP message, (3) be resent in some cases where it is a request that IOTP message, (3) be resent in some cases where it is a request that
times out, (4) used as input to the Customer Care role in later 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 versions of IOTP, etc. The way in which the data is copied depends on
the IOTP Transaction. 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 URIs to which the IOTP client must which for HTTP will contain the URIs 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
skipping to change at page 5, line 21 skipping to change at page 5, line 21
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
external encodings allowed by the XML specification. external encodings allowed by the XML specification.
4.3 Stopping an IOTP Transaction 4.3 Stopping an IOTP Transaction
The following should be read in conjunction with [draft-ietf-trade- The following should be read in conjunction with [draft-ietf-trade-
iotp-v1.0-protocol-*.txt] An IOTP Transaction is complete iotp-v1.0-protocol-*.txt] An IOTP Transaction is complete
-- when an IOTP Message is received by the IOTP client with a status
of "LastMsg",
-- the IOTP client decides to fail the IOTP Transaction for some -- the IOTP client decides to fail the IOTP Transaction for some
reason either by canceling the transaction or as a result of reason either by canceling the transaction or as a result of
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 an Error Block
Block) must direct the browser to the Net Location specified in with a HardError or a Cancel Block) must direct the browser to the
SuccessNetLocn in the Protocol Options Component, i.e., cause it Net Location specified in SuccessNetLocn in the Protocol Options
to do an HTTP GET with that URL. Component, i.e., cause it to do an HTTP GET with that URL.
-- does not complete successfully, because it has received some Fail -- does not complete successfully, because it has received some Error
Trading Block, must display the information in the Fail Message, Trading Block, must display the information in the Error Message,
stop the transaction, then pass control to the browser so that it stop the transaction, then pass control to the browser so that it
will do a GET on the Error Net Location specified for the role will do a GET on the Error Net Location specified for the role
from which the error was received. from which the error was received.
-- is cancelled for some reason, sends an IOTP Message containing an -- is cancelled since a Cancel Block has been received, stops the
Error Trading Block to the CancelNetLocn contained in the Protocol IOTP Transaction, and hands control to the browser so that it will
Options Component, stops the IOTP Transaction, and hands control do a GET on the on the Cancel Net Location specified for the role
to the browser so that it will do a GET on the Cancel Net from which the Cancel Block was received.
Locations specified for the role the cusomer was in communications
with when the cancel occured.
-- 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 Error Trading
Block to role from which the bad message was received and the Block to role from which the erroneous message was received and
ErrorNetLogLoc specified for that role, stops the IOTP the ErrorLogNetLoc specified for that role, stops the IOTP
Transaction, and hands control to the browser so that it will do a 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 GET from the Error Net Location specified for the role from which
the bad message was received. the bad message was received.
-- has a "time out", must display a message describing the time out. -- has a "time out", must display a message describing the time out.
May give the user the option of cancelling or retrying and/or may May give the user the option of cancelling or retrying and/or may
automatically retry. On failure due to time out, treat as an automatically retry. On failure due to time out, treat as an
error above. 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
skipping to change at page 7, line 10 skipping to change at page 7, line 10
7. IANA Considerations 7. IANA Considerations
This specification defines the application/iotp mime type which is This specification defines the application/iotp mime type which is
thereby reserved. thereby reserved.
References References
[RFC 1945] - "Hypertext Transfer Protocol -- HTTP/1.0", T. Berners- [RFC 1945] - "Hypertext Transfer Protocol -- HTTP/1.0", T. Berners-
Lee, R. Fielding & H. Frystyk. May 1996. Lee, R. Fielding & H. Frystyk. May 1996.
[RFC 2068] - "Hypertext Transfer Protocol -- HTTP/1.1", R. Fielding,
J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee. January 1997.
[RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997. Requirement Levels", March 1997.
[RFC 2246] - "The TLS Protocol Version 1.0", T. Dierks, C. Allen. [RFC 2246] - "The TLS Protocol Version 1.0", T. Dierks, C. Allen.
January 1999. January 1999.
[RFC 2376] - "XML Media Types", E. Whitehead, M. Murata. July 1998. [RFC 2376] - "XML Media Types", E. Whitehead, M. Murata. July 1998.
[RFC 2396] - T. Berners-Lee, R. Fielding, L. Masinter, "Uniform [RFC 2396] - T. Berners-Lee, R. Fielding, L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", August 1998. Resource Identifiers (URI): Generic Syntax", August 1998.
[RFC 2616] - "Hypertext Transfer Protocol -- HTTP/1.1", R. Fielding,
J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-
Lee, June 1999.
draft-ietf-trade-iotp-v1.0-protocol-*.txt - David Burdett draft-ietf-trade-iotp-v1.0-protocol-*.txt - David Burdett
draft-ietf-trade-iotp-v1.0-dsig-*.txt - Kent Davidson, Yoshiaki draft-ietf-trade-iotp-v1.0-dsig-*.txt - Kent Davidson, Yoshiaki
Kawatsura Kawatsura
Authors Addresses Authors Addresses
Donald E. Eastlake 3rd Donald E. Eastlake 3rd
IBM IBM
65 Shindegan Hill Road 65 Shindegan Hill Road
skipping to change at page 8, line 9 skipping to change at page 8, line 9
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 February 2000. This draft expires February 2000.
Its file name is draft-ietf-trade-iotp-http-02.txt. Its file name is draft-ietf-trade-iotp-http-03.txt.
 End of changes. 

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