summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2935.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2935.txt')
-rw-r--r--doc/rfc/rfc2935.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc2935.txt b/doc/rfc/rfc2935.txt
new file mode 100644
index 0000000..c0d6858
--- /dev/null
+++ b/doc/rfc/rfc2935.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group D. Eastlake
+Request for Comments: 2935 Motorola
+Category: Standards Track C. Smith
+ Royal Bank of Canada
+ September 2000
+
+
+ Internet Open Trading Protocol (IOTP) HTTP Supplement
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Abstract
+
+ Internet Open Trading Protocol (IOTP) messages will be carried as
+ Extensible Markup Language (XML) documents. As such, the goal of
+ mapping to the transport layer is to ensure that the underlying XML
+ documents are carried successfully between the various parties.
+
+ This document describes that mapping for the Hyper Text Transport
+ Protocol (HTTP), Versions 1.0 and 1.1.
+
+Table of Contents
+
+ 1. Introduction................................................... 2
+ 2. HTTP Servers and Clients....................................... 2
+ 3. HTTP Net Locations............................................. 2
+ 4. Consumer Clients............................................... 2
+ 4.1 Starting the IOTP Client and the Merchant IOTP Server.......... 3
+ 4.2 Ongoing IOTP Messages.......................................... 3
+ 4.3 Stopping an IOTP Transaction................................... 4
+ 5. Starting the Payment handler and Deliverer IOTP Servers........ 5
+ 6. Security Considerations........................................ 5
+ 7. IANA Considerations............................................ 5
+ 8. References..................................................... 6
+ 9. Authors' Addresses............................................. 7
+ 10. Full Copyright Statement....................................... 9
+
+
+
+
+
+Eastlake & Smith Standards Track [Page 1]
+
+RFC 2935 IOTP HTTP Supplement September 2000
+
+
+1. Introduction
+
+ Internet Open Trading Protocol (IOTP) [RFC2801] messages will be
+ carried as XML [XML] documents. As such, the goal of mapping to the
+ transport layer is to ensure that the underlying XML documents are
+ carried successfully between the various parties.
+
+ This document describes that mapping for the Hyper Text Transport
+ Protocol (HTTP), Versions 1.0 and 1.1 [RFCs 1945, 2616].
+
+ There may be future documents describing IOTP over email (SMTP), TCP,
+ cable TV, or other transports.
+
+ 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
+
+ The structure of IOTP maps on to the structure of HTTP in the
+ following way:
+
+ The merchant, payment handler, delivery handler, and customer care
+ roles are all represented by HTTP servers. Each may be
+ represented by a separate server, or they may be combined in any
+ combination.
+
+ The consumer role is represented by an HTTP client.
+
+ Note: A Merchant, may act in the role of a consumer, for example to
+ deposit electronic cash. In this case the Merchant, as an
+ organization rather than as a role, would need to be supported by an
+ HTTP client.
+
+3. HTTP Net Locations
+
+ The Net Locations contained within the IOTP specification are all
+ URIs [RFC 2396]. If a secure connection is required or desired a
+ secure channel that both the HTTP Server and Client support MUST be
+ used. Examples of such channels are SSL version 3 or TLS [RFC 2246].
+
+4. Consumer Clients
+
+ In most environments, the consumer agent will initially be an HTML
+ browser. However, current browsers do not provide the needed
+ capability to act as an agent for the consumer for an IOTP
+ transaction. This leads to two requirements:
+
+
+
+
+Eastlake & Smith Standards Track [Page 2]
+
+RFC 2935 IOTP HTTP Supplement September 2000
+
+
+ a method of starting and passing control to the IOTP client, and
+
+ a method of closing down the IOTP client cleanly and passing control
+ back to the HTML browser once the IOTP Transaction has finished.
+
+4.1 Starting the IOTP Client and the Merchant IOTP Server
+
+ At some point, the HTTP client at the consumer will send an HTTP
+ request that is interpreted as an "IOTP Startup Request" by the
+ 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
+ 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
+ "APPLICATION/X-IOTP" has been in use for experimentation and
+ development and SHOULD also be recognized. See section 7 below for
+ the MIME type registration template for APPLICATION/IOTP. 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
+ request to start the application associated with MIME type
+ "APPLICATION/IOTP", and to pass the content of this message to that
+ application.
+
+ At this point, the IOTP client will be started and have the first
+ message.
+
+ IOTP messages are short-lived. Therefore, the HTTP server SHOULD
+ avoid having its responses cached. In HTTP V1.0, the "nocache"
+ pragma can be used. This can be neglected on SSL/TLS secured
+ connections which are not cached and on HTTP POST requests in HTTP
+ v1.1 as in v1.1 POST responses are not cached.
+
+4.2 Ongoing IOTP Messages
+
+ 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
+ IOTP messages, (2) used in calculations to verify signatures in later
+ 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
+ later versions of IOTP, etc. The way in which the data is copied
+ 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.
+
+
+
+Eastlake & Smith Standards Track [Page 3]
+
+RFC 2935 IOTP HTTP Supplement September 2000
+
+
+ The IOTP messages contain Net Locations (e.g. the PayReqNetLocn)
+ which for HTTP will contain the URIs to which the IOTP client MUST
+ send IOTP messages.
+
+ Subsequent IOTP messages (XML documents) will be sent using the POST
+ function of HTTP. The HTTP client MUST perform full HTTP POST
+ requests.
+
+ The XML documents MUST be sent in a manner compatible with the
+ external encodings allowed by the XML [XML] specification.
+
+4.3 Stopping an IOTP Transaction
+
+ The following should be read in conjunction with [RFC 2801].
+
+ An IOTP Transaction is complete when
+
+ -- the IOTP client decides to fail the IOTP Transaction for some
+ reason either by canceling the transaction or as a result of
+ discovering an error in an IOTP message received, or
+
+ -- 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
+ of Time (including retransmissions).
+
+ An IOTP Client which processes an IOTP Transaction which:
+
+ -- completes successfully (i.e. it has not received an Error Block
+ with a HardError or a Cancel Block) MUST direct the browser to the
+ Net Location specified in SuccessNetLocn in the Protocol Options
+ Component, i.e., cause it to do an HTTP GET with that URL.
+
+ -- does not complete successfully, because it has received some Error
+ Trading Block, MUST display the information in the Error Message,
+ 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
+ from which the error was received.
+
+ -- is cancelled since a Cancel Block has been received, MUST stop the
+ 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
+ from which the Cancel Block was received.
+
+ -- is in error because an IOTP Message does not conform to this
+ specification, MUST send an IOTP Message containing a Error
+ Trading Block to role from which the erroneous message was
+ received and the ErrorLogNetLoc specified for that role, stop the
+
+
+
+
+Eastlake & Smith Standards Track [Page 4]
+
+RFC 2935 IOTP HTTP Supplement September 2000
+
+
+ IOTP Transaction, and hand 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.
+
+ -- 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
+ 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
+ terminate the IOTP Client application immediately upon completing an
+ IOTP Transaction or whether to wait until it is closed down as a
+ result of, for example, user shut down or browser shut down.
+
+5. Starting the Payment handler and Deliverer IOTP Servers
+
+ Payment Handler and Deliverer IOTP Servers are started by receiving
+ an IOTP Message which contains:
+
+ -- for a Payment handler, a Payment Request Block, and
+
+ -- for a Delivery Handler, a Delivery Request Block
+
+6. Security Considerations
+
+ Security of Internet Open Trade Protocol messages is primarily
+ dependent on signatures within IOTP as described in [RFC 2801] and
+ [RFC 2802]. Privacy protection for IOTP interactions can be obtained
+ by using a secure channel for IOTP messages, such as SSL/TLS [RFC
+ 2246].
+
+ Note that the security of payment protocols transported by IOTP is
+ the responsibility of those payment protocols, NOT of IOTP.
+
+7. IANA Considerations
+
+ This specification defines the APPLICATION/IOTP MIME type. The
+ 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)
+
+
+
+Eastlake & Smith Standards Track [Page 5]
+
+RFC 2935 IOTP HTTP Supplement September 2000
+
+
+ Optional parameters: charset - see RFC 2376
+
+ 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 RFC 2801 and RFC 2802.
+
+ Interoperability considerations: See RFC 2801.
+
+ Published specification: See RFC 2801 and RFC 2802.
+
+ 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
+
+8. References
+
+ [RFC 1945] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext
+ Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
+
+ [RFC 2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose
+ Internet Mail Extensions (MIME) Part Four: Registration
+ Procedure", RFC 2048, November 1996.
+
+ [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC 2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
+ RFC 2246, January 1999.
+
+ [RFC 2376] Whitehead, E. and M. Murata, "XML Media Types", RFC 2376,
+ July 1998.
+
+ [RFC 2396] Berners-Lee, T., Rielding, R. and L. Masinter, "Uniform
+ Resource Identifiers (URI): Generic Syntax", RFC 2396,
+ August 1998.
+
+
+
+Eastlake & Smith Standards Track [Page 6]
+
+RFC 2935 IOTP HTTP Supplement September 2000
+
+
+ [RFC 2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+ Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
+ Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+ [RFC 2801] Burdett, D., "Internet Open Trading Protocol - IOTP
+ Version 1.0", RFC 2801, April 2000.
+
+ [RFC 2802] Davidson, K. and Y. Kawatsura, "Digital Signatures for the
+ v1.0 Internet Open Trading Protocol (IOTP)", RFC 2802,
+ April 2000
+
+ [XML] Bray, T., Paoli, J. and C. Sperberg-McQueen, "Extensible
+ Markup Language (XML) 1.0" <http://www.w3.org/TR/REC-xml>,
+ February 1998.
+
+9. Authors' Addresses
+
+ Donald E. Eastlake 3rd
+ Motorola
+ 140 Forest Avenue
+ Hudson, MA 01749 USA
+
+ Phone: +1 978-562-2827(h)
+ +1 508-261-5434(w)
+ Fax: +1 508-261-4447(w)
+ EMail: Donald.Eastlake@motorola.com
+
+
+ Chris J. Smith
+ Royal Bank of Canada
+ 277 Front Street West
+ Toronto, Ontario M5V 3A4 CANADA
+
+ Phone: +1 416-348-6090
+ Fax: +1 416-348-2210
+ EMail: chris.smith@royalbank.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake & Smith Standards Track [Page 7]
+
+RFC 2935 IOTP HTTP Supplement September 2000
+
+
+10. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake & Smith Standards Track [Page 8]
+