doc: Add RFC documents

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]
+