idnits 2.17.00 (12 Aug 2021) /tmp/idnits56659/draft-ietf-trade-iotp-http2-00.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. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 2003) is 6786 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: 'RFC2801' is mentioned on line 71, but not defined == 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 87, but not defined == Unused Reference: 'RFC 1945' is defined on line 283, but no explicit reference was found in the text == Unused Reference: 'RFC 2119' is defined on line 286, but no explicit reference was found in the text == Unused Reference: 'RFC 2616' is defined on line 292, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1945 ** 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) ** Downref: Normative reference to an Informational RFC: RFC 2801 -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2376 (Obsoleted by RFC 3023) Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Donald E. Eastlake 3rd 2 Obsoletes RFC 2935 Motorola 3 Chris Smith 4 Expires April 2004 October 2003 6 Internet Open Trading Protocol (IOTP) HTTP Supplement 7 9 Status of this Memo 11 Distribution of this document is unlimited. Comments should be sent 12 to the IETF TRADE working group . This 13 document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC 2026. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." The list 23 of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft 25 Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Copyright Notice 30 Copyright (C) 2003, The Internet Society. All Rights Reserved. 32 Abstract 34 Internet Open Trading Protocol (IOTP) messages will be carried as 35 Extensible Markup Language (XML) documents. As such, the goal of 36 mapping to the transport layer is to ensure that the underlying XML 37 documents are carried successfully between the various parties. This 38 document describes that mapping for the Hyper Text Transport Protocol 39 (HTTP), Versions 1.0 and 1.1, and the location of HTTP based IOTP 40 services using the SRV domain name system resource record. 42 Table of Contents 44 Status of this Memo........................................1 45 Copyright Notice...........................................1 46 Abstract...................................................1 48 Table of Contents..........................................2 50 1. Introduction............................................3 51 2. HTTP Servers and Clients................................3 52 3. HTTP Net Locations......................................3 53 4. Consumer Clients........................................4 54 4.1 Starting the IOTP Client and the Merchant IOTP Server..4 55 4.2 Ongoing IOTP Messages..................................5 56 4.3 Stopping an IOTP Transaction...........................5 57 5. Starting the Payment handler and Deliverer IOTP Servers.6 58 6. Security Considerations.................................7 59 7. IANA Considerations.....................................7 60 Changes from RFC 2935......................................7 62 Normative References.......................................8 63 Informative References.....................................8 65 Authors Addresses..........................................9 66 Full Copyright Statement...................................9 67 File name and Expiration..................................10 69 1. Introduction 71 Internet Open Trading Protocol (IOTP) [RFC2801] messages are carried 72 as XML [XML] documents. As such, the goal of mapping to the 73 transport layer is to ensure that the underlying XML documents are 74 carried successfully between the various parties. 76 This document describes that mapping for the Hyper Text Transport 77 Protocol (HTTP), Versions 1.0 and 1.1 [RFCs 1945, 2616], and the 78 location of IOTP services using the SRV domain name system resource 79 record [RFC 2782, draft-ietf-trade-srv-higher-services]. 81 There may be future documents describing IOTP over email (SMTP), TCP, 82 cable TV, or other transports. 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC2119]. 88 2. HTTP Servers and Clients 90 The structure of IOTP maps onto the structure of HTTP in the 91 following way: 93 The merchant, payment handler, delivery handler, and customer care 94 roles are all represented by HTTP servers. Each may be 95 represented by a separate server, or they may be combined in any 96 combination. 98 The consumer role is represented by an HTTP client, possibly a 99 browser. 101 Note: A Merchant, may act in the role of a consumer, for example to 102 deposit electronic cash. In this case the Merchant, as an 103 organization rather than as a role, would need to be supported by an 104 HTTP client. 106 3. HTTP Net Locations 108 The Net Locations specified by URIs [RFC 2396] within the IOTP 109 specification or by a domain name at which a service is required. If 110 a secure connection is required or desired a secure channel that both 111 the HTTP Server and Client support MUST be used. Examples of such 112 channels are SSL version 3 or TLS [RFC 2246]. 114 To locate an IOTP service at a domain name, the SRV DNS resource 115 record is used as describe in [draft-ietf-trade-srv-higher-services]. 116 The higher level service tokens to be used are as follows: 118 Service Token 120 customer _iotp-customer 121 merchant _iotp-merchant 122 payment _iotp-payment 123 delivery _iotp-delivery 124 care _iotp-care 126 4. Consumer Clients 128 In most environments, the consumer agent will initially be an HTML 129 browser. However, current browsers do not provide the needed 130 capability to act as an agent for the consumer for an IOTP 131 ptransaction. This leads to two requirements: 133 a method of starting and passing control to the IOTP client, and 135 a method of closing down the IOTP client cleanly and passing 136 control back to the HTML browser once the IOTP Transaction has 137 finished. 139 4.1 Starting the IOTP Client and the Merchant IOTP Server 141 At some point, the HTTP client at the consumer will send an HTTP 142 request that is interpreted as an "IOTP Startup Request" by the 143 Merchant HTTP server. This might, for example, be the result of 144 clicking on a "pay" button. This message is a stand-in for a request 145 message of some form and the Merchant Server will respond with the 146 first IOTP Message in the form of an XML document. 148 The MIME type for all IOTP messages is: "APPLICATION/IOTP"; however 149 "APPLICATION/X-IOTP" has been in use for experimentation and 150 development and SHOULD also be recognized. See section 7 below for 151 the MIME type registration template for APPLICATION/IOTP. Because 152 HTTP is binary clean, no content-transfer-encoding is required. (See 153 [RFC 2376] re the application/xml type which has some similar 154 considerations.) 156 This HTTP response will be interpreted by the HTML browser as a 157 request to start the application associated with MIME type 158 "APPLICATION/IOTP", and to pass the content of this message to that 159 application. 161 At this point, the IOTP client will be started and have the first 162 message. 164 IOTP messages are short-lived. Therefore, the HTTP server SHOULD 165 avoid having its responses cached. In HTTP V1.0, the "nocache" 166 pragma can be used. This can be neglected on SSL/TLS secured 167 connections which are not cached and on HTTP POST requests in HTTP 168 v1.1 as in v1.1 POST responses are not cached. 170 4.2 Ongoing IOTP Messages 172 Data from earlier IOTP Messages in a transaction MUST be retained by 173 the IOTP Client so that it may (1) be copied to make up part of later 174 IOTP messages, (2) used in calculations to verify signatures in later 175 IOTP message, (3) be resent in some cases where a request has timed 176 out without response, (4) used as input to the Customer Care role in 177 later versions of IOTP, etc. The way in which the data is copied 178 depends on the IOTP Transaction. The data MUST be retained until the 179 end of the transaction, whether by success, failure, or cancelation, 180 and as long thereafter as it is desired for any of the parties to 181 inquire into it. 183 The IOTP messages contain Net Locations (e.g. the PayReqNetLocn) 184 which for HTTP will contain the URIs to which the IOTP client MUST 185 send IOTP messages. 187 Subsequent IOTP messages (XML documents) will be sent using the POST 188 function of HTTP. The HTTP client MUST perform full HTTP POST 189 requests. 191 The XML documents MUST be sent in a manner compatible with the 192 external encodings allowed by the XML [XML] specification. 194 4.3 Stopping an IOTP Transaction 196 The following should be read in conjunction with [RFC 2801]. 198 An IOTP Transaction is complete when 200 -- the IOTP client decides to fail the IOTP Transaction for some 201 reason either by canceling the transaction or as a result of 202 discovering an error in an IOTP message received, or 204 -- a "time out" occurs or a connection fails, e.g. a response to an 205 IOTP Message, has not been received after some user-defined period 206 of Time (including retransmissions). 208 An IOTP Client which processes an IOTP Transaction which: 210 -- completes successfully (i.e. it has not received an Error Block 211 with a HardError or a Cancel Block) MUST direct the browser to the 212 Net Location specified in SuccessNetLocn in the Protocol Options 213 Component, i.e., cause it to do an HTTP GET with that URL. 215 -- does not complete successfully, because it has received some Error 216 Trading Block, MUST display the information in the Error Message, 217 stop the transaction, and pass control to the browser so that it 218 will do a GET on the Error Net Location specified for the role 219 from which the error was received. 221 -- is cancelled since a Cancel Block has been received, MUST stop the 222 IOTP Transaction and hand control to the browser so that it will 223 do a GET on the on the Cancel Net Location specified for the role 224 from which the Cancel Block was received. 226 -- is in error because an IOTP Message does not conform to this 227 specification, MUST send an IOTP Message containing a Error 228 Trading Block to role from which the erroneous message was 229 received and the ErrorLogNetLoc specified for that role, stop the 230 IOTP Transaction, and hand control to the browser so that it will 231 do a GET from the Error Net Location specified for the role from 232 which the bad message was received. 234 -- has a "time out", MUST display a message describing the time out. 235 May give the user the option of cancelling or retrying and/or may 236 automatically retry. On failure due to time out, treat as an 237 error above. 239 Each implementation of an IOTP client may decide whether or not to 240 terminate the IOTP Client application immediately upon completing an 241 IOTP Transaction or whether to wait until it is closed down as a 242 result of, for example, user shut down or browser shut down. 244 5. Starting the Payment handler and Deliverer IOTP Servers 246 Payment Handler and Deliverer IOTP Servers are started by receiving 247 an IOTP Message which contains: 249 -- for a Payment handler, a Payment Request Block, and 251 -- for a Delivery Handler, a Delivery Request Block 253 6. Security Considerations 255 Security of Internet Open Trade Protocol messages is primarily 256 dependent on signatures within IOTP as described in [RFC 2801] and 257 [RFC 2802]. Privacy protection for IOTP interactions can be obtained 258 by using a secure channel for IOTP messages, such as SSL/TLS [RFC 259 2246]. 261 Note that the security of payment protocols transported by IOTP is 262 the responsibility of those payment protocols, not of IOTP. 264 7. IANA Considerations 266 This specification carries forward the specification APPLICATION/IOTP 267 MIME type which has been registered. (See the registration template 268 in [RFC 2935] and in the IANA records.) 270 Changes from RFC 2935 272 1. Addition of means to locate IOTP services via the SRV resource. 274 2. Update references for more recent versions. 276 3. Update author inforamtion. 278 Normative References 280 [draft-ietf-trade-srv-higher-services] D. Eastlake, "DNS SRV Location 281 of Higher Level Services" 283 [RFC 1945] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext 284 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 286 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 287 Requirement Levels", BCP 14, RFC 2119, March 1997. 289 [RFC 2396] Berners-Lee, T., Rielding, R. and L. Masinter, "Uniform 290 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 292 [RFC 2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 293 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer 294 Protocol -- HTTP/1.1", RFC 2616, June 1999. 296 [RFC 2801] Burdett, D., "Internet Open Trading Protocol - IOTP 297 Version 1.0", RFC 2801, April 2000. 299 [XML] Bray, T., Paoli, J. and C. Sperberg-McQueen, "Extensible Markup 300 Language (XML) 1.0 (Second Edition)" , 301 February 1998. 303 Informative References 305 [RFC 2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 306 RFC 2246, January 1999. 308 [RFC 2376] Whitehead, E. and M. Murata, "XML Media Types", RFC 2376, 309 July 1998. 311 [RFC 2802] Davidson, K. and Y. Kawatsura, "Digital Signatures for the 312 v1.0 Internet Open Trading Protocol (IOTP)", RFC 2802, April 2000 314 [RFC 2935] Eastlake, D. and C. Smith, "Internet Open Trading Protocol 315 (IOTP) HTTP Supplement", September 2000. 317 Authors Addresses 319 Donald E. Eastlake 3rd 320 Motorola Laboratories 321 155 Beaver Street 322 Milford, MA 01757 USA 324 Phone: +1-508-786-7554 (w) 325 +1-508-634-2066 (h) 326 Email: Donald.Eastlake@motorola.com 328 Chris Smith 330 Email: smith@interlog.com 332 Full Copyright Statement 334 Copyright (c) 2003 The Internet Society, All Rights Reserved. 336 This document and translations of it may be copied and furnished to 337 others, and derivative works that comment on or otherwise explain it 338 or assist in its implementation may be prepared, copied, published 339 and distributed, in whole or in part, without restriction of any 340 kind, provided that the above copyright notice and this paragraph are 341 included on all such copies and derivative works. However, this 342 document itself may not be modified in any way, such as by removing 343 the copyright notice or references to the Internet Society or other 344 Internet organizations, except as needed for the purpose of 345 developing Internet standards in which case the procedures for 346 copyrights defined in the Internet Standards process must be 347 followed, or as required to translate it into languages other than 348 English. 350 The limited permissions granted above are perpetual and will not be 351 revoked by the Internet Society or its successors or assigns. 353 This document and the information contained herein is provided on an 354 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 355 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 356 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 357 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 358 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 360 File name and Expiration 362 This file is draft-ietf-trade-iotp-http2-00.txt. 363 It expires April 2004.