idnits 2.17.1 draft-ietf-trade-iotp-http-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 (October 2000) is 8565 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: 'RFCs 1945' is mentioned on line 77, but not defined -- Looks like a reference, but probably isn't: '2616' on line 77 == Missing Reference: 'RFC2119' is mentioned on line 85, but not defined == Unused Reference: 'RFC 1945' is defined on line 293, but no explicit reference was found in the text == Unused Reference: 'RFC 2119' is defined on line 300, but no explicit reference was found in the text == Unused Reference: 'RFC 2616' is defined on line 311, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1945 ** Obsolete normative reference: RFC 2048 (Obsoleted by RFC 4288, RFC 4289) ** 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT IOTP HTTP Supplement 2 Expires October 2000 4 Internet Open Trading Protocol (IOTP) HTTP Supplement 5 -------- ---- ------- -------- ------ ---- ---------- 6 8 Donald E. Eastlake 3rd 9 Chris J. Smith 11 Status of This Document 13 This draft is intended to become a Proposed Standard RFC. 14 Distribution of this document is unlimited. Comments should be sent 15 to the TRADE WG mailing list or to the 16 authors. 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 Internet Open Trading Protocol (IOTP [draft-ietf-trade-iotp-v1.0- 38 protocol-*.txt]) messages will be carried as XML documents. As such, 39 the goal of mapping to the transport layer is to ensure that the 40 underlying XML documents are carried successfully between the various 41 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 49 Abstract...................................................1 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.................................................8 66 Authors Addresses..........................................9 67 Expiration and File Name...................................9 69 1. Introduction 71 Internet Open Trading Protocol (IOTP) messages will be carried as XML 72 [XML] documents. As such, the goal of mapping to the transport layer 73 is to ensure that the underlying XML documents are carried 74 successfully between the various parties. 76 This documents describes that mapping for the Hyper Text Transport 77 Protocol (HTTP), Versions 1.0 and 1.1 [RFCs 1945, 2616]. 79 There may be future documents describing IOTP over email (SMTP), TCP, 80 cable TV, or other transports. 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [RFC2119]. 86 2. HTTP Servers and Clients 88 The structure of IOTP maps on to the structure of HTTP in the 89 following way: 91 The merchant, payment handler, delivery handler, and customer care 92 roles are all represented by HTTP servers. Each may be represented 93 by a separate server, or they may be combined in any combination. 95 The consumer role is represented by an HTTP client. 97 Note: A Merchant, may act in the role of a consumer, for example to 98 deposit electronic cash. In this case the Merchant, as an 99 organization rather than as a role, would need to be supported by an 100 HTTP client. 102 3. HTTP Net Locations 104 The Net Locations contained within the IOTP specification are all 105 URIs [RFC 2396]. If a secure connection is required or desired any 106 secure channel that both the HTTP Server and Client support may be 107 used, for example SSL version 3 or TLS [RFC 2246]. 109 4. Consumer Clients 111 In most environments, the consumer agent will initially be an HTML 112 browser. However, current browsers do not provide the needed 113 capability to act as an agent for the consumer for an IOTP 114 transaction. This leads to two requirements: 116 a method of starting and passing control to the IOTP client, and 118 a method of closing down the IOTP client cleanly and passing control 119 back to the HTML browser once the IOTP Transaction has finished. 121 4.1 Starting the IOTP Client and the Merchant IOTP Server 123 At some point, the HTTP client at the consumer will send an HTTP 124 request that is interpreted as an "IOTP Startup Request" by the 125 Merchant HTTP server. This might, for example, be the result of 126 clicking on a "pay" button. This message is a stand-in for a request 127 message of some form and the Merchant Server will respond with the 128 first IOTP Message in the form of an XML document. 130 The MIME type for all IOTP messages is: "application/iotp"; however 131 "application/x-iotp" has been in use for experimentation and 132 development and SHOULD also be recognized. See section 7 below for 133 the MIME type registration template for application/iotp. Because 134 HTTP is binary clean, no content-transfer-encoding is required. (See 135 [RFC 2376] re the application/xml type which has some similar 136 considerations.) 138 This HTTP response will be interpreted by the HTML browser as a 139 request to start the application associated with MIME type 140 "application/iotp", and to pass the content of this message to that 141 application. 143 At this point, the IOTP client will be started and have the first 144 message. 146 IOTP messages are short-lived. Therefore, the HTTP server should 147 avoid having its responses cached. In HTTP V1.0, the "nocache" 148 pragma can be used. This can be neglected on SSL/TLS secured 149 connections which are not cached and on HTTP POST requests in HTTP 150 v1.1 as in v1.1 POST responses are not cached. 152 4.2 Ongoing IOTP Messages 154 Data from earlier IOTP Messages in a transaction must be retained by 155 the IOTP Client so that it may (1) be copied to make up part of later 156 IOTP messages, (2) used in calculations to verify signatures in later 157 IOTP message, (3) be resent in some cases where a request has timed 158 out without response, (4) used as input to the Customer Care role in 159 later versions of IOTP, etc. The way in which the data is copied 160 depends on the IOTP Transaction. 162 The IOTP messages contain Net Locations (e.g. the PayReqNetLocn) 163 which for HTTP will contain the URIs to which the IOTP client must 164 ship IOTP messages. 166 Subsequent IOTP messages (XML documents) will be sent using the POST 167 function of HTTP. The HTTP client has to perform full HTTP POST 168 requests. 170 The XML documents will be sent in a manner compatible with the 171 external encodings allowed by the XML [XML] specification. 173 4.3 Stopping an IOTP Transaction 175 The following should be read in conjunction with [draft-ietf-trade- 176 iotp-v1.0-protocol-*.txt] 178 An IOTP Transaction is complete when 180 -- the IOTP client decides to fail the IOTP Transaction for some 181 reason either by canceling the transaction or as a result of 182 discovering an error in an IOTP message received, or 184 -- a "time out" occurs or a connection fails, e.g. a response to an 185 IOTP Message, has not been received after some user-defined period 186 of Time (including retransmissions). 188 An IOTP Client which processes an IOTP Transaction which: 190 -- completes successfully (i.e. it has not received an Error Block 191 with a HardError or a Cancel Block) must direct the browser to the 192 Net Location specified in SuccessNetLocn in the Protocol Options 193 Component, i.e., cause it to do an HTTP GET with that URL. 195 -- does not complete successfully, because it has received some Error 196 Trading Block, must display the information in the Error Message, 197 stop the transaction, then pass control to the browser so that it 198 will do a GET on the Error Net Location specified for the role 199 from which the error was received. 201 -- is cancelled since a Cancel Block has been received, stops the 202 IOTP Transaction, and hands control to the browser so that it will 203 do a GET on the on the Cancel Net Location specified for the role 204 from which the Cancel Block was received. 206 -- is in error because an IOTP Message does not conform to this 207 specification, sends an IOTP Message containing a Error Trading 208 Block to role from which the erroneous message was received and 209 the ErrorLogNetLoc specified for that role, stops the IOTP 210 Transaction, and hands control to the browser so that it will do a 211 GET from the Error Net Location specified for the role from which 212 the bad message was received. 214 -- has a "time out", must display a message describing the time out. 215 May give the user the option of cancelling or retrying and/or may 216 automatically retry. On failure due to time out, treat as an 217 error above. 219 Each implementation of an IOTP client may decide whether or not to 220 terminate the IOTP Client application immediately upon completing an 221 IOTP Transaction or whether to wait until it is closed down as a 222 result of, for example, user shut down or browser shut down. 224 5. Starting the Payment handler and Deliverer IOTP Servers 226 Payment Handler and Deliverer IOTP Servers are started by receiving 227 an IOTP Message which contains: 229 -- for a Payment handler, a Payment Request Block, and 231 -- for a Delivery Handler, a Delivery Request Block 233 6. Security Considerations 235 Security of Internet Open Trade Protocol messages is primarily 236 dependent on signatures within IOTP as described in [draft-ietf- 237 trade-iotp-v1.0-protocol-*.txt] and [draft-ietf-trade-iotp-v1.0- 238 dsig-*.txt]. Privacy protection for IOTP interactions should be 239 obtained by using a secure channel for IOTP messages, such as SSL/TLS 240 [RFC 2246]. 242 Note that the security of payment protocols transported by IOTP is 243 the responsibility of those payment protocols, NOT of IOTP. 245 7. IANA Considerations 247 This specification defines the application/iotp mime type. The 248 registration template is as follows [RFC 2048]: 250 To: ietf-types@iana.org 251 Subject: Registration of MIME media type APPLICATION/IOTP 253 MIME media type name: APPLICATION 255 MIME subtype name: IOTP 257 Required parameters: (none) 259 Optional parameters: charset - see RFC 2376 261 Encoding considerations: Content is XML and may in some cases 262 require quoted printable or base64 encoding. However, no encoding 263 is required for HTTP transport which is expected to be common. 265 Security considerations: IOTP includes provisions for digital 266 authentication but for confidentiality, other mechanisms such as 267 TLS should be used. See draft-ietf-trade-iotp-v1.0-protocol- 268 07.txt and draft-ietf-trade-iotp-v1.0-dsig-*.txt in RFC Editor's 269 queue. 271 Interoperability considerations: See draft-ietf-trade-iotp-v1.0- 272 protocol-07.txt in RFC Editor's queue. 274 Published specification: See draft-ietf-trade-iotp-v1.0-protocol- 275 07.txt and draft-ietf-trade-iotp-v1.0-dsig-*.txt in RFC Editor's 276 queue. 278 Applications which use this media type: Internet Open Trading 279 Protocol applications. 281 Additional information: (none) 283 Person & email address to contact for further information: 284 Name: Donald E. Eastlake 3rd 285 Email: Donald.Eastlake@motorola.com 287 Intended usage: COMMON 289 Author/Change controller: IETF 291 References 293 [RFC 1945] - "Hypertext Transfer Protocol -- HTTP/1.0", T. Berners- 294 Lee, R. Fielding & H. Frystyk. May 1996. 296 [RFC 2048] - "Multipurpose Internet Mail Extensions (MIME) Part Four: 297 Registration Procedure", N. Freed, J. Klensin, J. Postel, November 298 1996. 300 [RFC 2119] - "Key words for use in RFCs to Indicate Requirement 301 Levels", S. Bradner, March 1997. 303 [RFC 2246] - "The TLS Protocol Version 1.0", T. Dierks, C. Allen. 304 January 1999. 306 [RFC 2376] - "XML Media Types", E. Whitehead, M. Murata. July 1998. 308 [RFC 2396] - "Uniform Resource Identifiers (URI): Generic Syntax", T. 309 Berners-Lee, R. Fielding, L. Masinter, August 1998. 311 [RFC 2616] - "Hypertext Transfer Protocol -- HTTP/1.1", R. Fielding, 312 J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners- 313 Lee, June 1999. 315 [draft-ietf-trade-iotp-v1.0-protocol-*.txt] - David Burdett 317 [draft-ietf-trade-iotp-v1.0-dsig-*.txt] - Kent Davidson, Yoshiaki 318 Kawatsura 320 [XML] - "Extensible Markup Language (XML) 1.0" 321 , Tim Bray, Jean Paoli, C. M. 322 Sperberg-McQueen, 10 February 1998 324 Authors Addresses 326 Donald E. Eastlake 3rd 327 Motorola 328 65 Shindegan Hill Road 329 Carmel, NY 10512 USA 331 Telephone: +1 914-276-2668(h) 332 +1 508-261-5434(w) 333 FAX: +1 508-261-4447(w) 334 email: Donald.Eastlake@motorola.com 336 Chris J. Smith 337 Royal Bank of Canada 338 277 Front Street West 339 Toronto, Ontario M5V 3A4 CANADA 341 Telephone: +1 416-348-6090 342 FAX: +1 416-348-2210 343 email: chris.smith@royalbank.com 345 Expiration and File Name 347 This draft expires October 2000. 349 Its file name is draft-ietf-trade-iotp-http-05.txt.