idnits 2.17.1 draft-ietf-trade-iotp-http-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Bad filename characters: the document name given in the document, 'draft-ietf-trade-iotp-http-00.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-trade-iotp-http-00.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-trade-iotp-http-00.txt,', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-trade-iotp-http-00.txt,', but the file name used is 'draft-ietf-trade-iotp-http-00' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (May 1999) is 9112 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFCs 1945' on line 74 looks like a reference -- Missing reference section? '2068' on line 74 looks like a reference Summary: 10 errors (**), 1 flaw (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT IOTP HTTP Supplement 2 November 1998 3 Expires May 1999 5 Internet Open Trading Protocol (IOTP) HTTP Supplement 6 -------- ---- ------- -------- ------ ---- ---------- 8 Donald E. Eastlake 3rd 9 Chris J. Smith 11 Status of This Document 13 This draft, file name draft-ietf-trade-iotp-http-00.txt, is intended 14 to become a Proposed Standard RFC. Distribution of this document is 15 unlimited. Comments should be sent to the TRADE WG mailing list 16 or to the authors. 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months. Internet-Drafts may be updated, replaced, or obsoleted by 25 other documents at any time. It is not appropriate to use Internet- 26 Drafts as reference material or to cite them other than as a 27 ``working draft'' or ``work in progress.'' 29 To view the entire list of current Internet-Drafts, please check the 30 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 31 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 32 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 33 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 35 Abstract 37 Internet Open Trading Protocol (IOTP) messages will be carried as XML 38 documents. As such, the goal of mapping to the transport layer is to 39 ensure that the underlying XML documents are carried successfully 40 between the various parties. 42 This documents describes that mapping for the Hyper Text Transport 43 Protocol (HTTP), Versions 1.0 and 1.1. 45 Table of Contents 47 Status of This Document....................................1 49 Abstract...................................................2 50 Table of Contents..........................................2 52 1. Introduction............................................3 53 2. HTTP Servers and Clients................................3 54 3. HTTP Net Locations......................................3 55 4. Consumer Clients........................................3 56 4.1 Starting the IOTP Client and the Merchant IOTP Server..4 57 4.2 Ongoing IOTP Messages..................................4 58 4.3 Stopping an IOTP Transaction...........................5 59 5. Starting the Payment handler and Deliverer IOTP Servers.6 60 6. Security Considerations.................................6 62 References.................................................7 63 Authors Addresses..........................................7 64 Expiration and File Name...................................7 66 1. Introduction 68 Internet Open Trading Protocol (IOTP) messages will be carried as XML 69 documents. As such, the goal of mapping to the transport layer is to 70 ensure that the underlying XML documents are carried successfully 71 between the various parties. 73 This documents describes that mapping for the Hyper Text Transport 74 Protocol (HTTP), Versions 1.0 and 1.1 [RFCs 1945, 2068]. 76 2. HTTP Servers and Clients 78 The structure of IOTP maps on to the structure of HTTP in the 79 following way: 81 The merchant, payment handler, deliverer, merchant customer care, and 82 payment customer care roles are all represented by HTTP servers. 83 Each may be represented by a separate server, or they may be 84 combined in any combination. 86 The consumer role is represented by an HTTP client. 88 Note: A Merchant, may act in the role of a consumer, for example to 89 deposit electronic cash. In this case the Merchant, as an 90 organisation rather than as a role, would need to be supported by an 91 HTTP client. 93 3. HTTP Net Locations 95 The Net Locations contained within the IOTP specification are all 96 URLs. Any secure channel that both the HTTP Server and Client support 97 may be used. For example SSL version 3 or TLS [xxx]. 99 4. Consumer Clients 101 In most environments, the consumer agent will initially be an HTML 102 browser. However, this does not provide the needed capability to act 103 as an agent for the consumer for an IOTP transaction. This leads to 104 two requirements: 106 a method of starting and passing control to the IOTP client, and 108 a method of closing down the IOTP client cleanly and passing control 109 back to the HTML browser once the IOTP Transaction has finished. 111 4.1 Starting the IOTP Client and the Merchant IOTP Server 113 At some point, the HTTP client at the consumer will send a HTTP 114 request that is interpreted as an "IOTP Startup Request" by the 115 Merchant HTTP server. This message is a stand-in for a request 116 message of some form, and the Merchant Server will respond with the 117 first OTP Message in the form of an XML document. 119 The MIME type for all IOTP messages is: "application/iotp"; however 120 "application/x-iotp" has been in use for experimentation and 121 development and should also be recognized. 123 This HTTP response will be interpreted by the HTML browser as a 124 request to start the application associated with MIME type 125 "application/iotp", and to pass the content of this message to that 126 application. 128 At this point, the IOTP client will be started and have the first 129 message. 131 IOTP messages are short-lived. Therefore, the HTTP server has to 132 provide accurate expiration dates or to use the HTTP no-proxy pragma, 133 such that HTTP proxy servers do not store and respond with these 134 messages to other HTTP clients. This cab be neglected on SSL/TLS 135 secured connections which are not cached. 137 4.2 Ongoing IOTP Messages 139 Data from earlier IOTP Messages must be retained by the IOTP Client 140 so that it may be copied to make up part of later IOTP Messages, used 141 in caculations to verify signatures in later IOTP message, be resent, 142 etc. The way in which the data is copied depends on the IOTP 143 Transaction. 145 The IOTP Messages contain Net Locations (e.g. the PayReqNetLocn) 146 which for HTTP will contain the URLs to which the IOTP client must 147 ship IOTP Messages. 149 Subsequent IOTP Messages (XML documents) will be sent using the POST 150 function of HTTP. The HTTP client has to perform full HTTP POST 151 requests. 153 The XML documents will be sent in a manner compatible with the 154 external encodings allowed by the XML specification. 156 4.3 Stopping an IOTP Transaction 158 An IOTP Transaction is complete 160 -- when an IOTP Message is received by the IOTP client with a status 161 of "LastMsg", 163 -- the IOTP client decides to fail the IOTP Transaction for some 164 reason either by canceling the transaction or as a result of 165 discovering an error in an IOTP message received, or 167 -- a "time out" occurs or a connection fails, e.g. a response to an 168 IOTP Message, has not been received after some user-defined period 169 of Time (including retransmissions). 171 An IOTP Client which processes an IOTP Transaction which: 173 -- completes successfully i.e. it has not received any Fail Trading 174 Block, must direct the browser to the Net Location specified in 175 SuccessNetLocn in the Protocol Options Component 177 -- does not complete successfully, because it has received some Fail 178 Trading Block must display the information in the Fail Message, 179 stop the transaction, then pass control to the browser to await a 180 response to the message 182 -- is cancelled for some reason, sends an IOTP Message containing an 183 Error Trading Block to the CancelNetLocn contained in the Protocol 184 Options Component, stops the IOTP Transaction, and hands control 185 to the browser 187 -- is in error because an IOTP Message does not conform to this 188 specification, sends an IOTP Message containing a Fail Trading 189 Block to the ErrorNetLocn contained in the Protocol Options 190 Component, stops the IOTP Transaction, and hands control to the 191 browser 193 -- has a "time out" must display a message describing the time out 194 and then pass control to the HTML browser. 196 Each implementation of an IOTP client may decide whether or not to 197 terminate the IOTP Client application immediately upon completing an 198 IOTP Transaction or whether to wait until it is closed down as a 199 result of, for example, user shut down or browser shut down. 201 5. Starting the Payment handler and Deliverer IOTP Servers 203 Payment Handler and Deliverer IOTP Servers are started by receiving 204 an IOTP Message which contains: 206 -- for a Payment handler, a Payment Request Block, and 208 -- for a Deliverer, a Delivery Request Block 210 6. Security Considerations 212 Security of Internet Open Trade Protocol messages is primarily 213 dependent on signatures within IOTP as described in [draft-ietf- 214 trade-iotp-v1.0-protocol-*.txt] and [draft-ietf-trade-xml-sig-*.txt]. 216 Note that the security of payment protocols transported by IOTP is 217 the responsibility of those payment protocols. 219 References 221 RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0", T. Berners-Lee, 222 R. Fielding & H. Frystyk. May 1996. 224 RFC 2068 - "Hypertext Transfer Protocol -- HTTP/1.1", R. Fielding, J. 225 Gettys, J. Mogul, H. Frystyk, T. Berners-Lee. January 1997. 227 draft-ietf-trade-iotp-v1.0-protocol-*.txt - David Burdett 229 draft-ietf-trade-xml-sig-*.txt - Richard Brown 231 Authors Addresses 233 Donald E. Eastlake 3rd 234 IBM 235 318 Acton Street 236 Carlisle, MA 01741 USA 238 Telephone: +1 978-287-4877 239 +1 914-784-7913 240 FAX: +1 978-371-7148 241 email: dee3@us.ibm.com 243 Chris J. Smith 244 Royal Bank of Canada 245 277 Front Street West 246 Toronto, Ontario M5V 3A4 CANADA 248 Telephone: +1 416-348-6090 249 FAX: +1 416-348-2210 250 email: chris.smith@royalbank.com 252 Expiration and File Name 254 This draft expires May 1999. 256 Its file name is draft-ietf-trade-iotp-http-00.txt.