idnits 2.17.1 draft-eastlake-internet-payment-01.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-eastlake-internet-payment-01.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-eastlake-internet-payment-01.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-eastlake-internet-payment-01.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-eastlake-internet-payment-01.txt,', but the file name used is 'draft-eastlake-internet-payment-01' == 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. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 251: '... Payment systems SHOULD provide a mean...' RFC 2119 keyword, line 337: '... provision SHOULD be made for a smal...' RFC 2119 keyword, line 805: '...blic and charges SHOULD NOT be imposed...' RFC 2119 keyword, line 850: '... is required and MUST be accompanied b...' RFC 2119 keyword, line 861: '...otocols, listed below, SHOULD NOT make...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 205 has weird spacing: '...56-5cad one d...' == Line 1010 has weird spacing: '...ash.com http:...' == 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 (29 January 1996) is 10314 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 1738' is mentioned on line 216, but not defined ** Obsolete undefined reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) == Unused Reference: 'ISO 4217' is defined on line 966, but no explicit reference was found in the text == Unused Reference: 'RFC 821' is defined on line 968, but no explicit reference was found in the text == Unused Reference: 'RFC 854' is defined on line 970, but no explicit reference was found in the text == Unused Reference: 'RFC 855' is defined on line 973, but no explicit reference was found in the text == Unused Reference: 'RFC 959' is defined on line 976, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO 4217' ** Obsolete normative reference: RFC 821 (Obsoleted by RFC 2821) Summary: 13 errors (**), 1 flaw (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Donald E. Eastlake 3rd 2 CyberCash 3 Expires: 28 July 1996 29 January 1996 5 Application Level Internet Payment Syntax 6 ----------- ----- -------- ------- ------ 8 Status of This Document 10 This draft, file name draft-eastlake-internet-payment-01.txt, is 11 intended to be become one or more Proposed Standard RFCs. 12 Distribution of this document is unlimited. Comments should be sent 13 to the author or the ietf-payments mailing list 14 . 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months. Internet-Drafts may be updated, replaced, or obsoleted by 23 other documents at any time. It is not appropriate to use Internet- 24 Drafts as reference material or to cite them other than as a 25 ``working draft'' or ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 29 Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), 30 nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe), 31 munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). 33 Abstract 35 The Internet is becoming an increasingly commercial arena in which 36 information is being bought and sold and payments are rendered for 37 services and data delivered within the Internet and goods and 38 services to be delivered outside of the Internet. Thus far, the 39 protocols and format used for such payments have been ad hoc and 40 proprietary. 42 This draft proposes a uniform application level syntax to support 43 commerce in applications level data and services Proposed 44 specifications are given for how this syntax fits into and enables 45 commerce in the data and services rendered by the World Wide Web, 46 FTP, Telnet, SMTP, and DNS protocols. 48 Acknowledgments 50 The contributions of the following persons to this draft are 51 gratefully acknowledged: 53 Brian Boesch 54 Phillip Hallam-Baker 55 Dave Kristol 56 David S. Raggett . 58 Table of Contents 60 Status of This Document....................................1 62 Abstract...................................................2 63 Acknowledgments............................................2 65 Table of Contents..........................................3 67 1. Introductions...........................................4 68 1.1 Applications Level Applicability.......................4 69 1.2 Overview of this document..............................4 71 2. Price Tags..............................................6 72 2.1 Prices.................................................6 73 2.2 Payment System Strings.................................6 74 2.3 Price Tags.............................................7 76 3. Payments, Receipts, and Errors..........................9 77 3.1 Payment Strings........................................9 78 3.2 Receipt Strings........................................9 79 3.3 Message Flow and Payer Private Information............10 80 3.4 Refunds...............................................10 81 3.5 Errors................................................10 83 4. Use in the World Wide Web..............................11 84 4.1 Web Browser User Interface............................11 85 4.2 Anchor Embedded Costs.................................11 86 4.3 Page Header Price Tags................................12 87 4.4 HTML Form Price Tags..................................13 88 4.5 Payments and Receipts Via Miscellaneous Headers.......14 89 4.6 Payments and Receipts Via PEP.........................15 90 4.7 Web Proxies...........................................16 92 5. Use in File Transfer Protocol..........................18 94 6. Use in Telnet..........................................19 96 7. Use in Simple Message Transfer Protocol................20 98 8. The Domain Name System.................................22 100 9. Protocols to Which Payment is not Applicable...........24 101 9.1 The ECHO, DISCARD, and CHARGEN Services...............24 102 9.2 The Finger Service....................................24 103 9.3 The Auth Service......................................25 105 10. Security Considerations...............................26 107 References................................................27 108 Author's Address..........................................27 110 1. Introductions 112 Commerce in applications level data and services on the Internet 113 requires a means to (1) indicate prices and acceptable methods of 114 payment, (2) tender payment, and (3) issue a receipt acknowledging 115 payment or notification if payment fails. 117 This document specifies a character string syntax for these three 118 items. 120 1.1 Applications Level Applicability 122 Payment facilities could be applied at a number of levels. This 123 specification is concerned only with applications level provision of 124 data items and services. It does not concern itself with network 125 level packets or quality of service nor does it concern itself 126 directly with transport level connections or quantity or quality of 127 service except as these transport level measures impact application 128 services. 130 This proposed syntax is concerned with such matters as payment for 131 access to a web page, upload of a file via ftp, initiation of a 132 telnet session, or conducting an extensive WAIS search. These are 133 generally user visible and meaningful data objects or tasks. 135 Within most legal systems, the owners of such data objects and/or the 136 owners of the facilities used to present such objects or perform such 137 tasks are frequently entitled to require some recompense if they 138 choose to require it. This document does not concern itself with the 139 morality of such laws or requirements but merely provides a syntax 140 whereby cooperating entities may speak at that level about prices and 141 payments. 143 There is no requirement that the "currencies" used with this syntax 144 be the usually recognized national or international currencies. For 145 example, some transactions could be denominated in frequent flyer 146 miles or other private unit. 148 1.2 Overview of this document 150 Sections 2 and 3 below define a basic syntactic framework for price 151 tags, payments, and receipts. 153 Sections 4 through 8 specify a standard for inclusion of these items 154 in transactions for the World Wide Web (HTTP/HTML), File Transfer 155 Protocol (FTP), Telnet, Simple Message Transfer Protocol (SMTP), and 156 the Domain Name System (DNS) protocols. 158 Section 9 lists some protocols to which application level payment 159 systems should not be applied. 161 Section 10 discusses security considerations. 163 Appendix A is an initial list of payment systems that are or are 164 planned to be usable via this syntax. 166 Appendix B gives a semi-formal BNF-like description of the syntax. 168 2. Price Tags 170 A uniform price tag format is needed to indicate when payment is due, 171 how much, and what payment methods are acceptable by the seller. 172 Such a price tag must include the specification of one or more 173 acceptable payment systems (with a provision for payment system 174 specific information) and will commonly include one or more prices. 176 Sections 2.1 and 2.2 below describe prices and payment system strings 177 and Section 2.3 assembles these for complete price tags. 179 2.1 Prices 181 Prices are encoded as character strings consisting of a number 182 followed by a currency code. 184 These currency codes are the three letter ISO 4217 codes, Internet 185 Assigned Number Authority (IANA) registered four to eight letter 186 currency codes, or any valid domain name containing at least two 187 labels. (ISO 4217 codes normally consist of the two letter country 188 code followed by a letter mnemonic for the major unit of currency.) 189 Currency codes are case insensitive. Codes of one, two, or more than 190 eight letters appearing in the place of a currency code are reserved 191 for future definition. 193 The number preceding the currency designation is the quantity of 194 major units of that currency. It may optionally have a decimal point 195 and additional decimal fraction digits and may optionally have a "+" 196 or "-" immediately followed by an integer scaling exponent. Any 197 number of digits of precision and any size exponent may be provided 198 but payment systems may define how many digits and what range they 199 utilize. 201 Some examples: 203 2.34gbp 2 pounds and 34 pence sterling 204 79+0ALL seventy nine Albanian Leks 205 123456-5cad one dollar 23 and 456 thousandths cents Canadian 206 0.125usd one eighth of a US dollar 208 2.2 Payment System Strings 210 Payment system strings consist of the payment system name, an equal 211 sign, and any payment system specific information (such as what 212 account within that payment system the payment should be made payable 213 to). 215 Payment system names are either case insensitive four to twelve 216 letter names registered with IANA or a URL [RFC 1738] and are 217 terminated by an equal sign. Codes occurring in the place of payment 218 system names consisting of one to three letter or more than twelve 219 letters are reserved for future definition. 221 Payment system specific information must be encoded so that it 222 contains no internal spaces or unusual characters as described in 223 Appendix B. It is up to the named payment system to encode and 224 decode any information it requires so as to fit within this syntax. 225 Use of the base64 encoding defined in RFC 1521 is recommended. The 226 payment system specific information, if any, appears immediately 227 after the payment system name and equal sign and is terminated by 228 white space or the end of the price tag character string. 230 A registry of payment system names is maintained by IANA. Initial 231 payment system names are listed in Appendix A. For experimental or 232 private use, any URL may be used. 234 2.3 Price Tags 236 A complete price tag consists of a string of white space separated 237 prices and payment system strings. There must be at least one 238 payment system string present. 240 Normally there will also be at least one price. However, there are 241 circumstances under which the cost of a service in highly 242 unpredictable and the seller is, in effect, requesting an arbitrary 243 donation or a payment system and account to which they can attempt to 244 charge indefinite amounts or payment for a service which will vary 245 with the amount of the payment. Where meaningful, it is recommended 246 that a price be listed that is a reasonable ceiling such that if 247 costs exceed it, the seller which have to present another price tag; 248 however, it is permitted to omit the price and list only a payment 249 system in a price tag. 251 Payment systems SHOULD provide a means for a limited amount of 252 arbitrary seller information to be included in the payment system 253 specific part of a price tag and be returned to the seller within a 254 payment message based on that price tag. 256 A price appearing after a payment system string applies only to that 257 system. Putting a price before the first payment system specific 258 information makes that price a default for every payment system 259 specified. The default can be overridden by specifying a different 260 amount for that currency after a particular payment system. 262 For example: 264 33.45all foocash=xxxx 22eTb barsys=yyyy 9.999ghC 266 indicates that payment of twenty-two Ethiopian Birrs via the foocash 267 payment system or 9.999 Ghanaian Cedis via the barsys system or 33.45 268 Albania Leks via either system is acceptable. 270 In cases where the cost of the service is not known in advance, the 271 price can be an estimate, deposit request, or the like, with any 272 overpayment refunded. Underpayment can be fixed by collecting an 273 additional payment from the client. In the absence of trust between 274 the parties, frequent small payments may be required. 276 3. Payments, Receipts, and Errors 278 The sections below describe encoding of payments and receipts and the 279 inclusion of error messages in the payment or receipt context. 281 A null payment or receipt string is explicitly permitted in most 282 contexts as a way for an entity to indicate merely that it is payment 283 syntax aware. 285 One or more equal sign terminated payment system names in isolation 286 are permitted in a payment or receipt context but only as a way to 287 indicate that a particular payment system is understood. Any actual 288 payment or receipt must have a non-null payment specific information. 289 Only one such full payment system string can occur in a payment or 290 receipt. 292 The content and/or encoding of the payment system specific 293 information would normally differ between the price tag, payment, and 294 receipt contexts but this is a matter only of concern to the payment 295 system. 297 3.1 Payment Strings 299 After encountering a price tag, either initially, during a session, 300 or in conjunction with a "payment required" error, an application 301 needs some method of tendering payment. This is done with a payment 302 system string with the same syntax as described in Section 2.2 above. 303 For example: 305 foocash=29Uso+Oa/e92micHd4s3 307 The payment system used in the payment is selected from among those 308 in the price tag since those are known to be supported by the seller. 309 Payment systems will commonly include in the payment system specific 310 information some sort of serial or transaction number so that 311 retransmission of a message containing the string will not result in 312 duplicate payment. 314 3.2 Receipt Strings 316 Normally the seller will provide a receipt for the amount of money 317 actually collected or a message indicating payment failure or error. 318 This will be via a receipt character string which is also simply in 319 the form of a payment system string. For example: 321 barsys=8n7VtC2+uL341/== 323 Payment systems will commonly include, in the payment system specific 324 information of a receipt, an indication of how much the receipt is 325 for and some type of serial or transaction number so that 326 retransmission of a message containing the receipt will not result in 327 confusion. 329 3.3 Message Flow and Payer Private Information 331 For some payment systems, the buyer, instead of sending a payment to 332 the seller, actually completes payment based on the price tag and 333 simply sends to the seller a receipt string, as described above, 334 proving that they have paid. 336 For payment systems where the payment is sent to the seller, 337 provision SHOULD be made for a small amount of arbitrary payer 338 private information to be provided in the payment message by the 339 buyer and returned to the buyer by the seller in the receipt. 341 3.4 Refunds 343 Depending on payment system details, refunds may not be available or 344 they can be implemented in two ways. It can be a payment message 345 from the seller to the buyer, normally leading to a receipt from the 346 buyer to the seller. Or the seller may be able to directly refund to 347 the buyer's account or the like and simply send the buyer a receipt. 348 In some payment systems, both refund techniques might be available. 349 In others, refunding may not be possible. 351 3.5 Errors 353 Errors in formatting or the like that are internal to a payment or 354 receipt should generally be handled by being logged and/or reported 355 by an error message encoded into a receipt. Errors within a payment 356 system in a price tag may be reported in a payment or receipt. Great 357 care must be taken to be sure to avoid any situation that could 358 result in an endless loop of receipts. 360 Errors outside of payment systems, such as receiving a payment via an 361 unknown payment system or syntax errors that make it impossible to 362 determine a payment system, should be reported via the normal error 363 mechanism of the protocol within which the payments are embedded (see 364 sections below). 366 4. Use in the World Wide Web 368 The World Wide Web is a rapidly evolving system for information 369 interaction that is being increasingly used for commerce. It is 370 particularly well suited for the inclusion of payment systems, 371 especially any designed for efficient handling of small payments 372 which might reasonably be incurred on a "per web page" basis or the 373 like. 375 In the Web, a price is indicated by a COST parameter or by a payment 376 required error response. As described below, a COST parameter can 377 occur within an anchor, HTML document header, or several places in a 378 FORM. Payment and receipts can be included with HTTP requests and 379 payments using headers. 381 4.1 Web Browser User Interface 383 [the user interface material could be moved to an appendix] 385 It is important that small payments be closely integrated into the 386 browser user interface. An expected mode of operation will be one of 387 many small payments, so the overhead associated with each must be 388 small. It is unacceptable for the user to necessarily interact with 389 a separate screen or window to approve each small payment although a 390 user who wishes to do so should have that option. 392 The user should be able to establish some threshold (default perhaps 393 around 0.15usd or equivalent) such that actions incurring that charge 394 or less are semi-automatic. That is, no special approval action is 395 required, although color coding or the like should be used to 396 distinguish toll links from free links, an optional sound could be 397 made when any money is sent, or other clues used to give the user a 398 feel for what is going on. 400 To avoid spending an unexpectedly large amount in small pieces, 401 possibly a bank graphic or the like should be displayed to show how 402 much cash is still available to the browser before the user will have 403 to take action. The act of refilling the bank would be a more 404 heavyweight operation requiring user interaction or, to get a default 405 amount, at least user approval. 407 4.2 Anchor Embedded Costs 409 A cost can appear in an anchor. This is a very strong hint that 410 payment of the indicated amount should accompany the GET or other 411 operation that occurs when following that link. Note, however, that 412 it is ultimately up to the server being hit to determine if payment 413 is adequate or to follow the course it chooses for different levels 414 of payment. 416 The cost is given by a COST parameter in the anchor. For example: 418 420 Great stuff for one thin dime! 422 It is recommended that toll links be shown in a different color or 423 type style from toll-free links. Browsers may wish to go further and 424 indicate different cost levels, particularly costs above or below any 425 "automatic approval" level the user has. When the user has their 426 pointer over the link, the browser may wish to display the payment 427 particulars in a similar way to that in which it displays the URL. 428 (Such a display could be filtered to the currency and/or payment 429 system(s) actually available to the user.) 431 Notice that the cost, if any, indicated by the anchor text ("Great 432 stuff..." above) could be different from the actual "COST=" parameter 433 which controls the payment sent with the request. In turn, the 434 "COST=" amount could be different from what the server really wants. 435 Or the server may provide different data or services for different 436 payment amount. Such variable payment schemes may be better handled 437 with a FORM as described below. 439 4.3 Page Header Price Tags 441 The cost for accessing an HTML page and the default cost for 442 accessing any anchors or forms within the page can be included in the 443 header. For example: 445 446 Mating Habits of the Red Breasted Geek 448 450 0.75usd 0.99cad xxxsys=A8jne8W2/sw== 452 ... 454 An attempt to get such a document from a payment aware server without 455 payment of at least 5 cents via the xxxsys payment system should 456 fail. (See Payment Required Error section below.) A second attempt 457 with payment will be required. This could be done in a manner 458 similar to an access restriction failure followed by a second attempt 459 with access authorization information. 461 The ... item in the head indicates that all anchors and 462 forms on the page should be considered to have a price of 75 cents US 463 or 99 cents Canadian via the xxxsys payment system unless otherwise 464 indicated. 466 4.4 HTML Form Price Tags 468 A cost can be associated with a form and with multiple choice items 469 within the form. For example: 471
473 Miscellaneous text, etc. 475 plain vanilla 476 chocolate fudge 479

Your quality of service: 484

486 The COST associated with the form is a base price (which may be 487 defaulted from a item in the document header), to which any 488 multiple choice item costs are added. The form level COST may be 489 omitted and COSTs can still appear with multiple choice items. The 490 COST associated with a "select" is a default that applies only if no 491 item is selected. When an item is selected, it overrides the 492 selection level cost and become the price component added into the 493 total form price for that selection. 495 The normally required payment system string can be omitted from some 496 of the form COST parameters, in which case any prices add to the 497 amount for all payment systems, or the COST parameters can contain 498 payment system name(s) without payment specific information to cause 499 price information to add to the amount for the designated payment 500 system(s). But one or more payment systems and their payment system 501 specific parameters must be determinable if any payment is to be 502 sent. The payment system specific information associated with the 503 last encountered payment system field used in calculating the payment 504 for the form is used. If no payment system field is encountered, 505 then no payment will be sent with the request even though "COST=" 506 parameters are present. 508 As with anchor costs, it is desirable to indicate the cost of 509 multiple choice items by color coding and the cost of activating the 510 form by color coding the submit button. Note that the submit button 511 could change from free to toll or the like as choices are made in the 512 form. 514 4.5 Payments and Receipts Via Miscellaneous Headers 516 [This section defines payments and receipts using existing HTTP 517 header fields and one new such field. As an alternative, section 4.6 518 defines then using PEP.] 520 Payment can accompany an HTTP request by including a payment line in 521 the message header. This consists of the "ChargeTo:" header label 522 followed by a payment system string; however, "ChargeTo:" can appear 523 with one or more bare payment system names for the purpose of 524 indicating that the browser understands those systems without 525 conveying any actual payment. Examples: 527 ChargeTo: xxxcash=A8jne8W2/sw== 529 ChargeTo: foocash= barsys= 531 The first example is in the form of a payment via the xxxcash system. 532 The second example is an indication by the sender that it understands 533 the foocash and barsys payment systems. 535 The browser should keep track of such actual payments it has sent and 536 re-send the identical payment if the request needs to be retried with 537 access authorization information or due to a transient error, rather 538 than sending additional funds. 540 The collection of payment or the specifics of the failure of a 541 tendered payment are indicated back to the customer by a receipt line 542 in the response header. This consists of the "receipt:" header label 543 followed by a payment system string. For example: 545 Receipt: xxxcash=b93njexW2/swq4== 547 There are cases where a larger payment is collected initially and the 548 unused portion refunded or where adjustments are required after a 549 purchase. Because of this, ChargeTo and Receipt headers are both 550 allowed in both HTTP requests and responses. 552 If an HTTP request arrives without sufficient payment (or with none 553 at all) and payment is required by the server, the server can simply 554 provide a web page with limited or no actual information and possibly 555 one or more links with COST parameters embedded in them. 556 Alternatively, a "402 payment required" error can be returned, in 557 which case there must be a "www-cost:" response header field 558 analogous to the "www-authenticate:" header field for a "401 559 unauthorized"" response. The value of the www-cost field is the same 560 as for the COST parameter described above. 562 This is similar to an access restriction error in that the browser 563 can just try again with payment included the way it can try again 564 with access information. It may be possible to combine these by 565 returning a 402 error with the HTML accompanying the error having a 566 link with a COST parameter pointing to the originally sought item. 567 This would combine automatic charging for browsers that have 402 568 error processing implemented with a convenient way for the user to 569 re-request with payment for browsers that understand anchor COST 570 parameters but do not automatically handle 402 errors. 572 4.6 Payments and Receipts Via PEP 574 [This section is just a direct translation of section 4.5 into PEP 575 [draft-khare-http-pep-00.txt]. Probably needs more work to fully 576 take advantage of PEP.] 578 Payment can accompany an HTTP request by including a payment line in 579 the message header. This consists of a "Protocol: {payment ...}" 580 header where "..." is a payment system string. 582 It is also possible to use the Accept-protocol header with one or 583 more bare payment system names for the purpose of indicating that the 584 browser understands those systems without conveying any actual 585 payment. Examples: 587 Protocol: { payment xxxcash=A8jne8W2/sw== } 589 Accept-protocol: { payment foocash= barsys= } 591 The first example is in the form of a payment via the xxxcash system. 592 The second example is an indication by the sender that it understands 593 the foocash and barsys payment systems. 595 The browser should keep track of such actual payments it has sent and 596 re-send the identical payment if the request needs to be retried with 597 access authorization information or due to a transient error, rather 598 than sending additional funds. 600 The collection of payment or the specifics of the failure of a 601 tendered payment are indicated back to the customer by a receipt line 602 in the response header. This consists of a "Protocol: { receipt 603 ...}" header where "..." is a payment system string. For example: 605 Protocol: { receipt xxxcash=b93njexW2/swq4== } 607 There are cases where a larger payment is collected initially and the 608 unused portion refunded or where adjustments are required after a 609 purchase. Because of this, payment and receipt protocol and accept- 610 protocol headers are both allowed in both HTTP requests and 611 responses. 613 If an HTTP request arrives without sufficient payment (or with none 614 at all) and payment is required by the server, the server can simply 615 provide a web page with limited or no actual information and possibly 616 one or more links with COST parameters embedded in them. 617 Alternatively, a "402 payment required" error can be returned, in 618 which case there must be a "Protocol: { cost xxx }" response header 619 field analogous to the "www-authenticate:" header field for a "401 620 unauthorized"" response. The xxx field inside the protocol:cost 621 header is the same as for the COST parameter described above. 623 This is similar to an access restriction error in that the browser 624 can just try again with payment included the way it can try again 625 with access information. It may be possible to combine these by 626 returning a 402 error with the HTML accompanying the error having a 627 link with a COST parameter pointing to the originally sought item. 628 This would combine automatic charging for browsers that have 402 629 error processing implemented with a convenient way for the user to 630 re-request with payment for browsers that understand anchor COST 631 parameters but do not automatically handle 402 errors. 633 4.7 Web Proxies 635 [This section needs more work and the scoping provision of PEP 636 [draft-khare-http-pep-00.txt] would almost certainly prove helpful.] 638 When information that has an owner and price is being cached and 639 served to multiple different users by a proxy, the payments should be 640 requested by the proxy. The safest thing for the proxy to do is to 641 send payment to the entity it retrieved the data from using an HTTP 642 request with a payment header and the OPTIONS method. 644 If the proxy understands the payment system well enough and there are 645 no firewall problems, the proxy may be able to collect the payment 646 and directly transfer funds to the information owner. 648 It is not expected that proxy payment collection will be perfect. 649 There will initially be dumb proxies that don't understand payment 650 and there may be proxies that deliberately avoid collecting and 651 forwarding payment. But any large scale avoidance of payment will be 652 noticed and corrected. In any case, if the proxy can cache a copy, 653 so could the user, who could then give copies to all his friends. 654 The ease of automatically making small payments for information 655 through this syntax is hoped to produce a net reduction in free 656 copying of information for which the owner wished to impose a charge. 658 5. Use in File Transfer Protocol 660 An FTP server may wish to charge for a file transfer (either way) or 661 for an FTP session. 663 It may do so by requesting, via the 332 or 532 reply codes, that an 664 ACCT command be sent. 332 is used to indicate that a received 665 command is being held in abeyance pending receipt of an ACCT while 666 532 indicates that a received command has been abandoned due to lack 667 of payment and an ACCT command needs to be sent before attempting the 668 command again. 670 Price tags are indicated in the 332 or 532 text by a string at the 671 beginning of the form 673 675 in the 332 or 532 text, i.e., a literal "". The word "cost" is case insensitive. Arbitrary additional text 678 may be included after the price tag. 680 A payment can be send by simply including a payment string, as 681 defined in section 3, after the ACCT command. 683 A successful receipt is rendered by returning a 233 reply with a 684 receipt payment system string as the beginning of its text. A 685 payment failure receipt is rendered by returning a 433 or 533 reply 686 depending on whether the failure is transient or permanent. In 687 either case, the receipt string can be terminated by white space and 688 additional text human readable text placed after the receipt string 689 in the reply. 691 (See RFC 959.) 693 SUMMARY 695 Price Tags - in existing 332 and 532 replies. 696 Payments - in existing ACCT command. 697 Receipts - in new 233, 433, and 533, replies. 699 6. Use in Telnet 701 A host may wish to charge for or during a Telnet session. Telnet 702 option code is used to initially negotiate agreement of the two 703 parties to speak about payment. As with other Telnet options, either 704 side can sent IAC WILL xxx, in response to which an IAC DO xxx 705 indicates agreement and an IAC DON'T xxx indicate refusal. Or a 706 party can send IAC DO xxx to which IAC WILL xxx indicates agreement 707 and an IAC WON'T xxx indicates refusal. 709 After agreement to speak about payment has been reached, Telnet 710 subnegotiation strings can be exchanged, bracketed with IAC SB and 711 IAC SE. The initial subnegotiation byte indicates the type of 712 payment message following in the rest of the subnegotiation byte 713 string as follows: 715 Byte Meaning 716 ---- ------- 718 01 Price-tag 719 02 Payment 720 03 Receipt 722 (See RFCs 854, 855.) 724 7. Use in Simple Message Transfer Protocol 726 A host or user may wish to charge for the receipt of mail. This is 727 accomplished via the new 332 reply code. This is an interim success 728 code that indicates that further information is required to complete 729 a pending command. Note that use of 332 after the SMTP RCPT command 730 would be a simple way to implement any particular user requiring 731 payment for mail to be delivered to them and its use after the MAIL 732 command would be a simple way to implement a system requiring payment 733 for mail from all or certain sources (although this information is 734 easy to forge). 736 Payment is indicated by the new ACCT command. This is followed by a 737 payment string as defined in section 3 above. 739 Charging for mail may cut off a host or user from the normal flow of 740 mail. It seems unlikely that most individuals or mailing lists would 741 be willing to pay to send mail to such an addressee. However, it is 742 easy to envision cases where a service for which it would be 743 reasonable to charge is requested via email. Or there may be 744 individuals who do want to substantially cut themselves off from most 745 mail or mail from certain senders. 747 SMTP servers that speak ESMTP (see RFC 1651) may optionally give the 748 new EHLO keyword ACCT. However, ESMTP is designed for servers to 749 list features to be optionally invoked by clients. It is not really 750 appropriate as a means for servers to indicate features that they 751 will *require* of clients. 753 In any case, it is believed that no negotiation is necessary for an 754 SMTP server to use the new 332 reply code. RFC 821 is clear that the 755 receipt of any 3xx reply code after a MAIL, RCPT, etc. command is to 756 be considered an error. This is the appropriate understanding for an 757 SMTP client that does not understand payment when an SMTP server 758 requires payment. 760 The rules and state diagrams in RFC-821 are hereby amended and the 761 state diagram for MAIL, RCPT, SEND, SOML, and SAML is modified to the 762 following: 764 1 +---+ 1,3 765 FLOW FOR +----------->| E |<-----+ 766 PAYMENT AWARE | +---+ | 767 SMTP SERVER | | 768 | 2 +---+ 2 | 769 +----------->| S |<-----+ 770 | +---+ | 771 | | 772 | | 773 +---+ cmd +---+ 3 +---+ ACCT +---+ 774 | B |--------->| W |----->| |------->| W | 775 +---+ +---+ +---+ +---+ 776 | | 777 | 4,5 +---+ 4,5 | 778 +----------->| F |<-----+ 779 +---+ 781 A successful receipt is rendered by returning the new 233 reply with 782 a receipt payment system string as the beginning of its text. A 783 payment failure receipt is rendered by returning the new 433 or 533 784 replies depending on whether the failure is transient or permanent. 785 In either case, the receipt string can be terminated by white space 786 and additional human readable text placed after the receipt string in 787 the reply. 789 The middle digit 3 in SMTP reply codes is reserved for accounting, 790 corresponding to its existing use in FTP. 792 (See RFCs 821, 1651.) 794 SUMMARY 796 Price Tags - in new 332 reply. 797 Payments - in new ACCT command. 798 Receipts - in new 233, 433, and 533 replies. 800 8. The Domain Name System 802 The Domain Name System (DNS) is currently used for such fundamental 803 purposes as translating domain names (such as tam.cybercash.com) into 804 IP addresses or specifying SMTP mail backup and routing servers. For 805 such uses DNS data is public and charges SHOULD NOT be imposed for 806 DNS queries. 808 However, new uses of DNS, including dynamic update (draft-ietf- 809 dnsind-dynDNS-*.txt), and particularly burdensome operations such as 810 zone transfers of a large zone to other than a secondary, may warrant 811 charges. 813 Payment information is all communicated via the PAY RR. The type for 814 the PAY RR is and its structre is as follows: 816 1 1 1 1 1 1 817 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 818 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 819 | subtype | / 820 +--+--+--+--+--+--+--+--+ / 821 / data / 822 / / 823 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 825 The subtype indicates what the data is as follows: 826 0 - reserved. 828 1 - price tag. 830 2 - payment string. 832 3 - receipt string. 834 4-254 - available for IANA allocation. 836 255 - reserved. 838 PAY RRs occur in a zone and master file only under the zone name as a 839 price tag indicating the fee for a zone transfer to anyone other than 840 a zone secondary server. 842 Payment can be tendered with any request by including an appropriate 843 PAY RR in the additional information section. WARNING: do not do 844 this unless you are sure the server you are communicating with 845 understands payments. Most current servers will ignore any request 846 with a non-emplty additional information section. 848 A receipt or price tag can be rendered by including an appropriate 849 PAY RR in the additional inforamtion section of a reply. Error code 850 indicates payment is required and MUST be accompanied by a 851 price tag PAY RR. 853 (See RFCs 1034, 1035, drafat-ietf-dnsind-dynDNS-*.txt) 855 9. Protocols to Which Payment is not Applicable 857 Some protocols are inappropriate for the addition of payment 858 mechanisms. Either they are sufficiently basic to the operation of 859 the network or provide sufficiently light-weight access to public 860 information or are so simple there is no obvious way to add 861 extensions. Some of these protocols, listed below, SHOULD NOT make 862 use of this syntax or impose prices or payments. This does not imply 863 that there are not many more protocols for which it would be 864 inappropriate to define payment extensions. 866 9.1 The ECHO, DISCARD, and CHARGEN Services 868 These are light weight services intended for network maintenance. 869 ECHO echoes the packet sent to it (see RFC 862), DISCARD throws away 870 packets sent to it but maintains the connection (see RFC 863), and 871 CHARGEN generates an infinite number of random characters and sends 872 them until the calling party disconnects (see RFC 864). 874 Hosts are free to decide which, if any, of these three services they 875 wish to provide (although ECHO is Recommended), but SHOULD NOT impose 876 any charges for them. In any case, there really aren't any protocol 877 hooks in these services on which to attach payment. 879 9.2 The Finger Service 881 Finger is an optional information service intended to permit remote 882 users to learn a limited amount of information about a user or users 883 on an Internet host. Information such as the time they last logged 884 in or contents of their ".plan" file. There are serious security 885 considerations involved in allowing finger access to a host and hosts 886 are free to decide how much such access, if any, they will provide. 888 In some cases, finger servers have been set up to act as information 889 retrieval or reporting mechanisms, but this was not the designed 890 purpose of finger and, in most cases, there are better mechanisms to 891 provide such access. 893 If finger access is provided because a site wishes to be open, 894 charges SHOULD NOT be imposed. In any case, the information returned 895 by finger is free form text making it difficult to flag a payment 896 requirement. 898 (See RFC 1288.) 900 9.3 The Auth Service 902 This service, when implemented, allows a remote host to determine the 903 user associated with a TCP connection. It is intended as a security 904 and auditing tool although it is weak in the face of anyone with 905 direct access to the TPC or IP level who is attempting to mislead it. 906 Implementation is optional. 908 Those who chose to provide this service are doing so to cooperate in 909 such security or auditing at some sacrifice in the privacy of their 910 users. Charging for this service makes little sense in this context. 912 (See RFC 931.) 914 10. Security Considerations 916 Getting authorization to construct payments may, depending on the 917 payment system, require the user to enter a passphrase. For example, 918 a passphrase might be required at the beginning of their session to 919 unlock a private key. Thus the user could be vulnerable to Trojan 920 horse web browsers, ftp clients, telnet clients, etc., as they are 921 to many other types of Trojan horse applications. Use of "secure" 922 application distribution with signed executables, checksums, virus 923 detection, etc., should be encouraged. 925 An adversary may be able to observe or modify traffic to and from an 926 application. Payment systems should be designed so that such 927 observation results in minimal loss of privacy and such observation 928 or modification can not result in hijacking a payment. Note that an 929 adversary that has complete control over application communications 930 can pretend to be a merchant just as it could by controlling an end 931 node. However, such impersonation from an end node may be easier to 932 trace and control than impersonation at an unknown point along the 933 communications path. Message (MOSS) and connection (IPSEC, IPv6) 934 security protocols are available to help protect the communications 935 path. 937 On receipt of an advance payment, a server is capable of charging the 938 user regardless of whether the server actually provides the data or 939 services being charged for. A server could even send back an error 940 message but keep and use the payment. Some means of automatically 941 logging payments that result in a software or human detectable 942 failure to deliver should be implemented so these can be examined for 943 patterns or cross checked with payment system statements of account. 945 A merchant can withhold and fail to send back to the user a receipt. 946 Applications should assume any payment sent will be collected 947 regardless of whether they get a receipt back. 949 With payment systems, a monetary cost can sometimes be associated 950 with downloaded data. Caching algorithms may wish to take this into 951 account and cache costly data in preference to free data. Servers 952 should accept the identical data request from the same net entity for 953 a reasonable amount of time even if the payment being presented is a 954 duplicate. Transient errors may have prevented use of the data 955 previously downloaded for that request. 957 A bad client application could generate payments exceeding the funds 958 or authorization available to it. Servers should verify payments 959 promptly and be cautious of extending services or goods unless they 960 can confirm that payment is good. Applications and payment systems 961 should be designed to limit the amount of funds a rogue application 962 could transfer. 964 References 966 [ISO 4217] - Codes for the representation of currencies and funds 968 [RFC 821] - J. Postel, "Simple Mail Transfer Protocol", 08/01/1982. 970 [RFC 854] - J. Postel, J. Reynolds, "Telnet option specifications", 971 05/01/1983. 973 [RFC 855] - J. Postel, J. Reynolds, "Telnet Protocol specification", 974 05/01/1983. 976 [RFC 959] - J. Postel, J. Reynolds, "File Transfer Protocol", 977 10/01/1985. 979 Author's Address 981 Donald E. Eastlake, 3rd 982 CyberCash, Inc. 983 318 Acton Street 984 Carlisle, MA 01741 USA 986 Telephone: +1 508 287 4877 987 +1 508 371 7148 (fax) 988 +1 703-620-4200 (main office, Reston, Virginia, USA) 989 email: dee@cybercash.com 991 Expiration and File Name 993 This draft expires 28 July 1996. 995 Its file name is draft-eastlake-internet-payment-01.txt. 997 Appendix A: Initial Payment System Names 999 This is an alphabetic list of the initial registered payment system 1000 names that intend to be usable via this syntax. 1002 [send email to author, dee@cyercash.com, if you would like to be 1003 added] 1005 Company Name Email Contact Home Page 1006 ------------ ------------- --------- 1007 Payment System Name - (brief description) 1008 ------------------- 1010 CyberCash, Inc. info@cybercash.com http://www.cybercash.com 1011 cybercash - (credit card) 1012 cash - (cash) 1014 Appendix B: Simplified BNF 1016 This is a BNF-like description of the Payment Protocol syntax syntax, 1017 using the conventions of RFC822, except that "|" is used to designate 1018 alternatives, and brackets [] are used around optional or repeated 1019 elements. Briefly, literals are quoted with "", optional elements are 1020 enclosed in [brackets], and elements may be preceded with * to 1021 designate n or more repetitions of the following element or * 1022 to indicate n or more but not more than m repetitions; n defaults to 1023 0. 1025 ;prices 1027 isocurrency = alpha alpha alpha 1028 ietfcurrency = 4*8alpha 1029 privatecurrency = 2*127[ dns-label "." ] 1030 currency = isocurrency | ietfcurrency | privatecurrency 1031 digits = 1*digit 1032 decimal = "." | "," 1033 number = digits | digits decimal *digit 1034 exponent = "+" digits | "-" digits 1036 cost = number currency | number exponent currency 1038 ;payment system strings 1040 ianapaysys = 4*12alpha 1041 privatepaysys = url 1042 paysysname = ianapaysys | url 1044 paysys = paysysname "=" *uchar 1046 ;price tag 1048 pricetag = *sp paysys *[ 1*sp cost | 1*sp paysys ] *sp | 1049 *sp *[ cost 1*sp | paysys 1*sp ] paysys *sp 1051 ;miscellaneous definitions 1053 lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | 1054 "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | 1055 "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | 1056 "y" | "z" 1057 hialpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | 1058 "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | 1059 "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | 1060 "Y" | "Z" 1062 alpha = lowalpha | hialpha 1063 digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | 1064 "8" | "9" 1065 other = "$" | "-" | "_" | "." | "+" | "/" | "=" | "@" 1066 hex = digit | "A" | "B" | "C" | "D" | "E" | "F" | 1067 "a" | "b" | "c" | "d" | "e" | "f" 1068 escape = "%" hex hex 1069 sp = " " 1070 uchar = alpha | digit | other | extra | escape