draft-ietf-trade-iotp-http-03.txt   draft-ietf-trade-iotp-http-04.txt 
INTERNET-DRAFT IOTP HTTP Supplement INTERNET-DRAFT IOTP HTTP Supplement
August 1999 March 2000
Expires February 2000 Expires September 2000
draft-ietf-trade-iotp-http-03.txt
Internet Open Trading Protocol (IOTP) HTTP Supplement Internet Open Trading Protocol (IOTP) HTTP Supplement
-------- ---- ------- -------- ------ ---- ---------- -------- ---- ------- -------- ------ ---- ----------
<draft-ietf-trade-iotp-http-04.txt>
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-03.txt, is intended This draft is intended to become a Proposed Standard RFC.
to become a Proposed Standard RFC. Distribution of this document is Distribution of this document is unlimited. Comments should be sent
unlimited. Comments should be sent to the TRADE WG mailing list to the TRADE WG mailing list <ietf-trade@eListX.com> or to the
<ietf-trade@eListX.com> or to the authors. 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 RFC2026. Internet-Drafts are working
working documents of the Internet Engineering Task Force (IETF), its documents of the Internet Engineering Task Force (IETF), its areas,
areas, and its working groups. Note that other groups may also and its working groups. Note that other groups may also distribute
distribute working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress". material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
Internet Open Trading Protocol (IOTP) messages will be carried as XML Internet Open Trading Protocol (IOTP [draft-ietf-trade-iotp-v1.0-
documents. As such, the goal of mapping to the transport layer is to protocol-*.txt]) messages will be carried as XML documents. As such,
ensure that the underlying XML documents are carried successfully the goal of mapping to the transport layer is to ensure that the
between the various parties. underlying XML documents are carried successfully 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.
Table of Contents Table of Contents
Status of This Document....................................1 Status of This Document....................................1
Abstract...................................................1
Abstract...................................................2
Table of Contents..........................................2 Table of Contents..........................................2
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 7. IANA Considerations.....................................6
References.................................................7 References.................................................8
Authors Addresses..........................................7
Expiration and File Name...................................8 Authors Addresses..........................................9
Expiration and File Name...................................9
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 [XML] documents. As such, the goal of mapping to the transport layer
ensure that the underlying XML documents are carried successfully is to ensure that the underlying XML documents are carried
between the various parties. successfully 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, 2616]. 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].
skipping to change at page 3, line 48 skipping to change at page 3, line 48
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
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, current browsers do not provide the needed
as an agent for the consumer for an IOTP transaction. This leads to capability to act as an agent for the consumer for an IOTP
two requirements: transaction. This leads to 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 an 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 might, for example, be the result of Merchant HTTP server. This might, for example, be the result of
clicking on a "pay" button. This message is a stand-in for a request clicking on a "pay" button. This message is a stand-in for a request
message of some form and the Merchant Server will respond with the message of some form and the Merchant Server will respond with the
first IOTP Message in the form of an XML document. 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. Because HTTP is binary development and SHOULD also be recognized. See section 7 below for
clean, no content-transfer-encoding is required. (See [RFC 2376] re the MIME type registration template for application/iotp. Because
the application/xml type which has some similar considerations.) 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 should IOTP messages are short-lived. Therefore, the HTTP server should
avoid having its responses cached. 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 calculations 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 a request has times
times out, (4) used as input to the Customer Care role in later out without response, (4) used as input to the Customer Care role in
versions of IOTP, etc. The way in which the data is copied depends on later versions of IOTP, etc. The way in which the data is copied
the IOTP Transaction. 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 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
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
external encodings allowed by the XML specification. external encodings allowed by the XML [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
-- 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:
skipping to change at page 6, line 30 skipping to change at page 6, line 35
-- for a Payment handler, a Payment Request Block, and -- for a Payment handler, a Payment Request Block, and
-- for a Delivery Handler, a Delivery Request Block -- for a Delivery Handler, 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-iotp-v1.0- trade-iotp-v1.0-protocol-*.txt] and [draft-ietf-trade-iotp-v1.0-
dsig-*.txt]. dsig-*.txt]. Privacy protection for IOTP interactions should be
obtained by using a secure channle for IOTP messages, such as SSL/TLS
[RFC 2246].
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, NOT of IOTP. the responsibility of those payment protocols, NOT of IOTP.
7. IANA Considerations 7. IANA Considerations
This specification defines the application/iotp mime type which is This specification defines the application/iotp mime type. The
thereby reserved. registration template is as follows [RFC 2048]:
To: ietf-types@iana.org
Subject: Registration of MIME media type APPLICATION/IOTP
MIME media type name: APPLICATION
MIME subtype name: IOTP
Required parameters: (none)
Optional parameters: (none)
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 includes provisions for digital
authentication but for confidentiality, other mechanisms such as
TLS should be used. See draft-ietf-trade-iotp-v1.0-protocol-
07.txt in RFC Editor's queue.
Interoperability considerations: See draft-ietf-trade-iotp-v1.0-
protocol-07.txt in RFC Editor's queue.
Published specification: See draft-ietf-trade-iotp-v1.0-protocol-
07.txt in RFC Editor's queue.
Applications which use this media type: Internet Open Trading
Protocol applications.
Additional information: (none)
Person & email address to contact for further information:
Name: Donald E. Eastlake 3rd
Email: Donald.Eastlake@motorola.com
Intended usage: COMMON
Author/Change controller: IETF
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 2119] - S. Bradner, "Key words for use in RFCs to Indicate [RFC 2048] - "Multipurpose Internet Mail Extensions (MIME) Part Four:
Requirement Levels", March 1997. Registration Procedure", N. Freed, J. Klensin, J. Postel, November
1996.
[RFC 2119] - "Key words for use in RFCs to Indicate Requirement
Levels", S. Bradner, 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] - "Uniform Resource Identifiers (URI): Generic Syntax", T.
Resource Identifiers (URI): Generic Syntax", August 1998. Berners-Lee, R. Fielding, L. Masinter, August 1998.
[RFC 2616] - "Hypertext Transfer Protocol -- HTTP/1.1", R. Fielding, [RFC 2616] - "Hypertext Transfer Protocol -- HTTP/1.1", R. Fielding,
J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners- J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-
Lee, June 1999. 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
[XML] - "Extensible Markup Language (XML) 1.0"
<http://www.w3.org/TR/REC-xml>, Tim Bray, Jean Paoli, C. M.
Sperberg-McQueen, 10 February 1998
Authors Addresses Authors Addresses
Donald E. Eastlake 3rd Donald E. Eastlake 3rd
IBM Motorola
65 Shindegan Hill Road 65 Shindegan Hill Road
Carmel, NY 10512 USA Carmel, NY 10512 USA
Telephone: +1 914-276-2668(h) Telephone: +1 914-276-2668(h)
+1 914-784-7913(w) +1 508-261-5434(w)
FAX: +1 914-784-3833(w) FAX: +1 508-261-4447(w)
email: dee3@us.ibm.com email: Donald.Eastlake@motorola.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 February 2000. This draft expires September 2000.
Its file name is draft-ietf-trade-iotp-http-03.txt. Its file name is draft-ietf-trade-iotp-http-04.txt.
 End of changes. 

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