draft-ietf-trade-iotp-http-06.txt   rfc2935.txt 
INTERNET-DRAFT IOTP HTTP Supplement
Expires December 2000
Internet Open Trading Protocol (IOTP) HTTP Supplement
-------- ---- ------- -------- ------ ---- ----------
<draft-ietf-trade-iotp-http-06.txt>
Donald E. Eastlake 3rd
Chris J. Smith
Status of This Document Network Working Group D. Eastlake
Request for Comments: 2935 Motorola
Category: Standards Track C. Smith
Royal Bank of Canada
September 2000
This draft is intended to become a Proposed Standard RFC. Internet Open Trading Protocol (IOTP) HTTP Supplement
Distribution of this document is unlimited. Comments should be sent
to the TRADE WG mailing list <ietf-trade@lists.eListX.com> or to the
authors.
This document is an Internet-Draft and is in full conformance with Status of this Memo
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This document specifies an Internet standards track protocol for the
and may be updated, replaced, or obsoleted by other documents at any Internet community, and requests discussion and suggestions for
time. It is inappropriate to use Internet- Drafts as reference improvements. Please refer to the current edition of the "Internet
material or to cite them other than as "work in progress." Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2000). All Rights Reserved.
http://www.ietf.org/shadow.html.
Abstract Abstract
Internet Open Trading Protocol (IOTP [RFC 2801]) messages will be Internet Open Trading Protocol (IOTP) messages will be carried as
carried as XML documents. As such, the goal of mapping to the Extensible Markup Language (XML) documents. As such, the goal of
transport layer is to ensure that the underlying XML documents are mapping to the transport layer is to ensure that the underlying XML
carried successfully between the various parties. documents are carried successfully between the various parties.
This documents describes that mapping for the Hyper Text Transport This document 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 1. Introduction................................................... 2
Abstract...................................................1 2. HTTP Servers and Clients....................................... 2
3. HTTP Net Locations............................................. 2
Table of Contents..........................................2 4. Consumer Clients............................................... 2
4.1 Starting the IOTP Client and the Merchant IOTP Server.......... 3
1. Introduction............................................3 4.2 Ongoing IOTP Messages.......................................... 3
2. HTTP Servers and Clients................................3 4.3 Stopping an IOTP Transaction................................... 4
3. HTTP Net Locations......................................3 5. Starting the Payment handler and Deliverer IOTP Servers........ 5
4. Consumer Clients........................................3 6. Security Considerations........................................ 5
4.1 Starting the IOTP Client and the Merchant IOTP Server..4 7. IANA Considerations............................................ 5
4.2 Ongoing IOTP Messages..................................4 8. References..................................................... 6
4.3 Stopping an IOTP Transaction...........................5 9. Authors' Addresses............................................. 7
5. Starting the Payment handler and Deliverer IOTP Servers.6 10. Full Copyright Statement....................................... 9
6. Security Considerations.................................6
7. IANA Considerations.....................................6
References.................................................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) [RFC2801] messages will be
[XML] documents. As such, the goal of mapping to the transport layer carried as XML [XML] documents. As such, the goal of mapping to the
is to ensure that the underlying XML documents are carried transport layer is to ensure that the underlying XML documents are
successfully between the various parties. carried successfully between the various parties.
This documents describes that mapping for the Hyper Text Transport This document 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].
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, 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
by a separate server, or they may be combined in any combination. represented 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
organization 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 a
secure channel that both the HTTP Server and Client support may be secure channel that both the HTTP Server and Client support MUST be
used, for example SSL version 3 or TLS [RFC 2246]. used. Examples of such channels are 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, current browsers do not provide the needed browser. However, current browsers do not provide the needed
capability to act as an agent for the consumer for an IOTP capability to act as an agent for the consumer for an IOTP
transaction. This leads to 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 an 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. See section 7 below for development and SHOULD also be recognized. See section 7 below for
the MIME type registration template for application/iotp. Because the MIME type registration template for APPLICATION/IOTP. Because
HTTP is binary clean, no content-transfer-encoding is required. (See HTTP is binary clean, no content-transfer-encoding is required. (See
[RFC 2376] re the application/xml type which has some similar [RFC 2376] re the application/xml type which has some similar
considerations.) 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 a request has timed IOTP message, (3) be resent in some cases where a request has timed
out without response, (4) used as input to the Customer Care role in out without response, (4) used as input to the Customer Care role in
later versions of IOTP, etc. The way in which the data is copied later versions of IOTP, etc. The way in which the data is copied
depends on the IOTP Transaction. depends on the IOTP Transaction. The data MUST be retained until the
end of the transaction, whether by success, failure, or cancelation,
and as long thereafter as it is desired for any of the parties to
inquire into it.
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. send 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 MUST perform full HTTP POST
requests. requests.
The XML documents will be sent in a manner compatible with the The XML documents MUST be sent in a manner compatible with the
external encodings allowed by the XML [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 [RFC 2801]. The following should be read in conjunction with [RFC 2801].
An IOTP Transaction is complete when 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:
-- completes successfully (i.e. it has not received an Error Block -- completes successfully (i.e. it has not received an Error Block
with a HardError or a Cancel Block) must direct the browser to the with a HardError or a Cancel Block) MUST direct the browser to the
Net Location specified in SuccessNetLocn in the Protocol Options Net Location specified in SuccessNetLocn in the Protocol Options
Component, i.e., cause it 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 Error -- does not complete successfully, because it has received some Error
Trading Block, must display the information in the Error 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, and 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 since a Cancel Block has been received, stops the -- is cancelled since a Cancel Block has been received, MUST stop the
IOTP Transaction, and hands control to the browser so that it will IOTP Transaction and hand control to the browser so that it will
do a GET on the on the Cancel Net Location specified for the role do a GET on the on the Cancel Net Location specified for the role
from which the Cancel Block was received. from which the Cancel Block was received.
-- 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 Error Trading specification, MUST send an IOTP Message containing a Error
Block to role from which the erroneous message was received and Trading Block to role from which the erroneous message was
the ErrorLogNetLoc specified for that role, stops the IOTP received and the ErrorLogNetLoc specified for that role, stop the
Transaction, and hands control to the browser so that it will do a IOTP Transaction, and hand control to the browser so that it will
GET from the Error Net Location specified for the role from which do a GET from the Error Net Location specified for the role from
the bad message was received. which 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
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
skipping to change at page 6, line 33 skipping to change at page 5, line 31
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 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 [RFC 2801] and dependent on signatures within IOTP as described in [RFC 2801] and
[RFC 2802]. Privacy protection for IOTP interactions should be [RFC 2802]. Privacy protection for IOTP interactions can be obtained
obtained by using a secure channel for IOTP messages, such as SSL/TLS by using a secure channel for IOTP messages, such as SSL/TLS [RFC
[RFC 2246]. 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. The This specification defines the APPLICATION/IOTP MIME type. The
registration template is as follows [RFC 2048]: registration template is as follows [RFC 2048]:
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of MIME media type APPLICATION/IOTP Subject: Registration of MIME media type APPLICATION/IOTP
MIME media type name: APPLICATION MIME media type name: APPLICATION
MIME subtype name: IOTP MIME subtype name: IOTP
Required parameters: (none) Required parameters: (none)
Optional parameters: charset - see RFC 2376 Optional parameters: charset - see RFC 2376
Encoding considerations: Content is XML and may in some cases Encoding considerations: Content is XML and may in some cases
require quoted printable or base64 encoding. However, no encoding require quoted printable or base64 encoding. However, no encoding
is required for HTTP transport which is expected to be common. is required for HTTP transport which is expected to be common.
Security considerations: IOTP includes provisions for digital Security considerations: IOTP includes provisions for digital
authentication but for confidentiality, other mechanisms such as authentication but for confidentiality, other mechanisms such as
TLS should be used. See RFC 2801 and RFC 2802. TLS should be used. See RFC 2801 and RFC 2802.
skipping to change at page 8, line 5 skipping to change at page 6, line 31
Additional information: (none) Additional information: (none)
Person & email address to contact for further information: Person & email address to contact for further information:
Name: Donald E. Eastlake 3rd Name: Donald E. Eastlake 3rd
Email: Donald.Eastlake@motorola.com Email: Donald.Eastlake@motorola.com
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: IETF Author/Change controller: IETF
References 8. References
[RFC 1945] - "Hypertext Transfer Protocol -- HTTP/1.0", T. Berners- [RFC 1945] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext
Lee, R. Fielding & H. Frystyk. May 1996. Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[RFC 2048] - "Multipurpose Internet Mail Extensions (MIME) Part Four: [RFC 2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose
Registration Procedure", N. Freed, J. Klensin, J. Postel, November Internet Mail Extensions (MIME) Part Four: Registration
1996. Procedure", RFC 2048, November 1996.
[RFC 2119] - "Key words for use in RFCs to Indicate Requirement [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", S. Bradner, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2246] - "The TLS Protocol Version 1.0", T. Dierks, C. Allen. [RFC 2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
January 1999. RFC 2246, January 1999.
[RFC 2376] - "XML Media Types", E. Whitehead, M. Murata. July 1998. [RFC 2376] Whitehead, E. and M. Murata, "XML Media Types", RFC 2376,
July 1998.
[RFC 2396] - "Uniform Resource Identifiers (URI): Generic Syntax", T. [RFC 2396] Berners-Lee, T., Rielding, R. and L. Masinter, "Uniform
Berners-Lee, R. Fielding, L. Masinter, August 1998. Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[RFC 2616] - "Hypertext Transfer Protocol -- HTTP/1.1", R. Fielding, [RFC 2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners- Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
Lee, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC 2801] - "Internet Open Trading Protocol - IOTP Version 1.0", D. [RFC 2801] Burdett, D., "Internet Open Trading Protocol - IOTP
Burdett, April 2000. Version 1.0", RFC 2801, April 2000.
[RFC 2802] - "Digital Signatures for the v1.0 Internet Open Trading [RFC 2802] Davidson, K. and Y. Kawatsura, "Digital Signatures for the
Protocol (IOTP)", K. Davidson, Y. Kawatsura, April 2000 v1.0 Internet Open Trading Protocol (IOTP)", RFC 2802,
April 2000
[XML] - "Extensible Markup Language (XML) 1.0" [XML] Bray, T., Paoli, J. and C. Sperberg-McQueen, "Extensible
<http://www.w3.org/TR/REC-xml>, Tim Bray, Jean Paoli, C. M. Markup Language (XML) 1.0" <http://www.w3.org/TR/REC-xml>,
Sperberg-McQueen, 10 February 1998 February 1998.
Authors Addresses 9. Authors' Addresses
Donald E. Eastlake 3rd Donald E. Eastlake 3rd
Motorola Motorola
140 Forest Avenue 140 Forest Avenue
Hudson, MA 01749 USA Hudson, MA 01749 USA
Telephone: +1 978-562-2827(h) Phone: +1 978-562-2827(h)
+1 508-261-5434(w) +1 508-261-5434(w)
FAX: +1 508-261-4447(w) Fax: +1 508-261-4447(w)
email: Donald.Eastlake@motorola.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 Phone: +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 10. Full Copyright Statement
This draft expires December 2000. Copyright (C) The Internet Society (2000). All Rights Reserved.
Its file name is draft-ietf-trade-iotp-http-06.txt. 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 other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 55 change blocks. 
129 lines changed or deleted 117 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/