idnits 2.17.1 draft-ietf-trade-iotp-http-03.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-23) 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: ---------------------------------------------------------------------------- ** 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? == 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 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2000) is 8834 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: 'RFC 2026' is mentioned on line 24, but not defined == Missing Reference: 'RFCs 1945' is mentioned on line 76, but not defined -- Looks like a reference, but probably isn't: '2616' on line 76 == Missing Reference: 'RFC2119' is mentioned on line 84, but not defined == Unused Reference: 'RFC 1945' is defined on line 245, but no explicit reference was found in the text == Unused Reference: 'RFC 2119' is defined on line 248, but no explicit reference was found in the text == Unused Reference: 'RFC 2616' is defined on line 259, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1945 ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2376 (Obsoleted by RFC 3023) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT IOTP HTTP Supplement 2 August 1999 3 Expires February 2000 4 draft-ietf-trade-iotp-http-03.txt 6 Internet Open Trading Protocol (IOTP) HTTP Supplement 7 -------- ---- ------- -------- ------ ---- ---------- 9 Donald E. Eastlake 3rd 10 Chris J. Smith 12 Status of This Document 14 This draft, file name draft-ietf-trade-iotp-http-03.txt, is intended 15 to become a Proposed Standard RFC. Distribution of this document is 16 unlimited. Comments should be sent to the TRADE WG mailing list 17 or to the authors. 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of [RFC 2026]. Internet-Drafts are 21 working documents of the Internet Engineering Task Force (IETF), its 22 areas, and its working groups. Note that other groups may also 23 distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet- Drafts as reference 28 material or to cite them other than as "work in progress". 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 Internet Open Trading Protocol (IOTP) messages will be carried as XML 39 documents. As such, the goal of mapping to the transport layer is to 40 ensure that the underlying XML documents are carried successfully 41 between the various parties. 43 This documents describes that mapping for the Hyper Text Transport 44 Protocol (HTTP), Versions 1.0 and 1.1. 46 Table of Contents 48 Status of This Document....................................1 50 Abstract...................................................2 51 Table of Contents..........................................2 53 1. Introduction............................................3 54 2. HTTP Servers and Clients................................3 55 3. HTTP Net Locations......................................3 56 4. Consumer Clients........................................3 57 4.1 Starting the IOTP Client and the Merchant IOTP Server..4 58 4.2 Ongoing IOTP Messages..................................4 59 4.3 Stopping an IOTP Transaction...........................5 60 5. Starting the Payment handler and Deliverer IOTP Servers.6 61 6. Security Considerations.................................6 62 7. IANA Considerations.....................................6 64 References.................................................7 65 Authors Addresses..........................................7 66 Expiration and File Name...................................8 68 1. Introduction 70 Internet Open Trading Protocol (IOTP) messages will be carried as XML 71 documents. As such, the goal of mapping to the transport layer is to 72 ensure that the underlying XML documents are carried successfully 73 between the various parties. 75 This documents describes that mapping for the Hyper Text Transport 76 Protocol (HTTP), Versions 1.0 and 1.1 [RFCs 1945, 2616]. 78 There may be future documents describing IOTP over email (SMTP), TCP, 79 cable TV, or other transports. 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119]. 85 2. HTTP Servers and Clients 87 The structure of IOTP maps on to the structure of HTTP in the 88 following way: 90 The merchant, payment handler, delivery handler, and customer care 91 roles are all represented by HTTP servers. Each may be represented 92 by a separate server, or they may be combined in any combination. 94 The consumer role is represented by an HTTP client. 96 Note: A Merchant, may act in the role of a consumer, for example to 97 deposit electronic cash. In this case the Merchant, as an 98 organization rather than as a role, would need to be supported by an 99 HTTP client. 101 3. HTTP Net Locations 103 The Net Locations contained within the IOTP specification are all 104 URIs [RFC 2396]. If a secure connection is required or desired any 105 secure channel that both the HTTP Server and Client support may be 106 used, for example SSL version 3 or TLS [RFC 2246]. 108 4. Consumer Clients 110 In most environments, the consumer agent will initially be an HTML 111 browser. However, this does not provide the needed capability to act 112 as an agent for the consumer for an IOTP transaction. This leads to 113 two requirements: 115 a method of starting and passing control to the IOTP client, and 117 a method of closing down the IOTP client cleanly and passing control 118 back to the HTML browser once the IOTP Transaction has finished. 120 4.1 Starting the IOTP Client and the Merchant IOTP Server 122 At some point, the HTTP client at the consumer will send a HTTP 123 request that is interpreted as an "IOTP Startup Request" by the 124 Merchant HTTP server. This might, for example, be the result of 125 clicking on a "pay" button. This message is a stand-in for a request 126 message of some form and the Merchant Server will respond with the 127 first IOTP Message in the form of an XML document. 129 The MIME type for all IOTP messages is: "application/iotp"; however 130 "application/x-iotp" has been in use for experimentation and 131 development and SHOULD also be recognized. Because HTTP is binary 132 clean, no content-transfer-encoding is required. (See [RFC 2376] re 133 the application/xml type which has some similar considerations.) 135 This HTTP response will be interpreted by the HTML browser as a 136 request to start the application associated with MIME type 137 "application/iotp", and to pass the content of this message to that 138 application. 140 At this point, the IOTP client will be started and have the first 141 message. 143 IOTP messages are short-lived. Therefore, the HTTP server should 144 avoid having its responses cached. In HTTP V1.0, the "nocache" 145 pragma can be used. This can be neglected on SSL/TLS secured 146 connections which are not cached and on HTTP POST requests in HTTP 147 v1.1 as in v1.1 POST responses are not cached. 149 4.2 Ongoing IOTP Messages 151 Data from earlier IOTP Messages in a transaction must be retained by 152 the IOTP Client so that it may (1) be copied to make up part of later 153 IOTP Messages, (2) used in calculations to verify signatures in later 154 IOTP message, (3) be resent in some cases where it is a request that 155 times out, (4) used as input to the Customer Care role in later 156 versions of IOTP, etc. The way in which the data is copied depends on 157 the IOTP Transaction. 159 The IOTP Messages contain Net Locations (e.g. the PayReqNetLocn) 160 which for HTTP will contain the URIs to which the IOTP client must 161 ship IOTP Messages. 163 Subsequent IOTP Messages (XML documents) will be sent using the POST 164 function of HTTP. The HTTP client has to perform full HTTP POST 165 requests. 167 The XML documents will be sent in a manner compatible with the 168 external encodings allowed by the XML specification. 170 4.3 Stopping an IOTP Transaction 172 The following should be read in conjunction with [draft-ietf-trade- 173 iotp-v1.0-protocol-*.txt] An IOTP Transaction is complete 175 -- the IOTP client decides to fail the IOTP Transaction for some 176 reason either by canceling the transaction or as a result of 177 discovering an error in an IOTP message received, or 179 -- a "time out" occurs or a connection fails, e.g. a response to an 180 IOTP Message, has not been received after some user-defined period 181 of Time (including retransmissions). 183 An IOTP Client which processes an IOTP Transaction which: 185 -- completes successfully (i.e. it has not received an Error Block 186 with a HardError or a Cancel Block) must direct the browser to the 187 Net Location specified in SuccessNetLocn in the Protocol Options 188 Component, i.e., cause it to do an HTTP GET with that URL. 190 -- does not complete successfully, because it has received some Error 191 Trading Block, must display the information in the Error Message, 192 stop the transaction, then pass control to the browser so that it 193 will do a GET on the Error Net Location specified for the role 194 from which the error was received. 196 -- is cancelled since a Cancel Block has been received, stops the 197 IOTP Transaction, and hands control to the browser so that it will 198 do a GET on the on the Cancel Net Location specified for the role 199 from which the Cancel Block was received. 201 -- is in error because an IOTP Message does not conform to this 202 specification, sends an IOTP Message containing a Error Trading 203 Block to role from which the erroneous message was received and 204 the ErrorLogNetLoc specified for that role, stops the IOTP 205 Transaction, and hands control to the browser so that it will do a 206 GET from the Error Net Location specified for the role from which 207 the bad message was received. 209 -- has a "time out", must display a message describing the time out. 210 May give the user the option of cancelling or retrying and/or may 211 automatically retry. On failure due to time out, treat as an 212 error above. 214 Each implementation of an IOTP client may decide whether or not to 215 terminate the IOTP Client application immediately upon completing an 216 IOTP Transaction or whether to wait until it is closed down as a 217 result of, for example, user shut down or browser shut down. 219 5. Starting the Payment handler and Deliverer IOTP Servers 221 Payment Handler and Deliverer IOTP Servers are started by receiving 222 an IOTP Message which contains: 224 -- for a Payment handler, a Payment Request Block, and 226 -- for a Delivery Handler, a Delivery Request Block 228 6. Security Considerations 230 Security of Internet Open Trade Protocol messages is primarily 231 dependent on signatures within IOTP as described in [draft-ietf- 232 trade-iotp-v1.0-protocol-*.txt] and [draft-ietf-trade-iotp-v1.0- 233 dsig-*.txt]. 235 Note that the security of payment protocols transported by IOTP is 236 the responsibility of those payment protocols, NOT of IOTP. 238 7. IANA Considerations 240 This specification defines the application/iotp mime type which is 241 thereby reserved. 243 References 245 [RFC 1945] - "Hypertext Transfer Protocol -- HTTP/1.0", T. Berners- 246 Lee, R. Fielding & H. Frystyk. May 1996. 248 [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate 249 Requirement Levels", March 1997. 251 [RFC 2246] - "The TLS Protocol Version 1.0", T. Dierks, C. Allen. 252 January 1999. 254 [RFC 2376] - "XML Media Types", E. Whitehead, M. Murata. July 1998. 256 [RFC 2396] - T. Berners-Lee, R. Fielding, L. Masinter, "Uniform 257 Resource Identifiers (URI): Generic Syntax", August 1998. 259 [RFC 2616] - "Hypertext Transfer Protocol -- HTTP/1.1", R. Fielding, 260 J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners- 261 Lee, June 1999. 263 draft-ietf-trade-iotp-v1.0-protocol-*.txt - David Burdett 265 draft-ietf-trade-iotp-v1.0-dsig-*.txt - Kent Davidson, Yoshiaki 266 Kawatsura 268 Authors Addresses 270 Donald E. Eastlake 3rd 271 IBM 272 65 Shindegan Hill Road 273 Carmel, NY 10512 USA 275 Telephone: +1 914-276-2668(h) 276 +1 914-784-7913(w) 277 FAX: +1 914-784-3833(w) 278 email: dee3@us.ibm.com 280 Chris J. Smith 281 Royal Bank of Canada 282 277 Front Street West 283 Toronto, Ontario M5V 3A4 CANADA 285 Telephone: +1 416-348-6090 286 FAX: +1 416-348-2210 287 email: chris.smith@royalbank.com 289 Expiration and File Name 291 This draft expires February 2000. 293 Its file name is draft-ietf-trade-iotp-http-03.txt.