idnits 2.17.1 draft-eastlake-internet-payment-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) 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-00.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-eastlake-internet-payment-00.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-eastlake-internet-payment-00.txt,', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-eastlake-internet-payment-00.txt,', but the file name used is 'draft-eastlake-internet-payment-00' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == 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 244: '... Payment systems SHOULD provide a mean...' RFC 2119 keyword, line 697: '...se protocols, listed below, SHOULD NOT...' RFC 2119 keyword, line 707: '... such, charges SHOULD NOT be imposed...' RFC 2119 keyword, line 726: '... charges SHOULD NOT be imposed....' RFC 2119 keyword, line 753: '...is Recommended), but SHOULD NOT impose...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 851 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 (7 July 1995) is 10492 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: 'TBD' is mentioned on line 586, but not defined == Unused Reference: 'ISO 4217' is defined on line 808, but no explicit reference was found in the text == Unused Reference: 'RFC 821' is defined on line 810, but no explicit reference was found in the text == Unused Reference: 'RFC 854' is defined on line 812, but no explicit reference was found in the text == Unused Reference: 'RFC 855' is defined on line 815, but no explicit reference was found in the text == Unused Reference: 'RFC 959' is defined on line 818, 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: 12 errors (**), 1 flaw (~~), 11 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 Updates RFC 821, 854, 959 CyberCash 3 Expires: 6 January 1996 7 July 1995 5 An Application Level Internet Payment Syntax 6 -- ----------- ----- -------- ------- ------ 8 Status of This Document 10 This draft, file name draft-eastlake-internet-payment-00.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 . 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months. Internet-Drafts may be updated, replaced, or obsoleted by 22 other documents at any time. It is not appropriate to use Internet- 23 Drafts as reference material or to cite them other than as a 24 ``working draft'' or ``work in progress.'' 26 To learn the current status of any Internet-Draft, please check the 27 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 28 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, 29 munnari.oz.au, or ftp.is.co.za. 31 Abstract 33 The Internet is becoming an increasingly commercial arena in which 34 information is being bought and sold and payments are rendered for 35 goods and services to be delivered outside of the Internet. Thus 36 far, the protocols and format used for such payments have been ad hoc 37 and proprietary. 39 This draft proposes a uniform application level syntax to support 40 such commerce. Specific specifications are given for how this syntax 41 fits into the World Wide Web, FTP, Telnet, and SMTP. 43 Acknowledgements 45 The contributions of the following persons to this draft are 46 gratefully acknowledged: 48 Brian Boesch 49 Phillip Hallam-Baker 50 David S. Raggett . 52 Table of Contents 54 Status of This Document....................................1 56 Abstract...................................................2 57 Acknowledgements...........................................2 59 Table of Contents..........................................3 61 1. Introductions...........................................4 62 1.1 Applications Level Applicability.......................4 63 1.2 Overview of this document..............................4 65 2. Price Tags..............................................6 66 2.1 Prices.................................................6 67 2.2 Payment System Strings.................................6 68 2.3 Price Tags.............................................7 70 3. Payments and Receipts...................................9 72 4. Use in the World Wide Web..............................11 73 4.1 Web Browser User Interface............................11 74 4.2 Anchor Embedded Costs.................................11 75 4.3 Page Header Price Tag.................................12 76 4.4 HTML Form Price Tags..................................13 77 4.5 Web Payments and Receipts.............................13 78 4.6 Payment Required Error................................14 79 4.7 Web Proxies...........................................15 81 5. Use in File Transfer Protocol..........................16 83 6. Use in Telnet..........................................17 85 7. Use in Simple Message Transfer Protocol................18 87 8. Protocols to Which Payment is not Applicable...........20 88 8.1 The Domain Name System................................20 89 8.2 The Finger Service....................................20 90 8.3 The Auth Service......................................20 91 8.4 The ECHO, DISCARD, and CHARGEN Services...............21 93 9. Security Considerations................................22 95 References................................................23 96 Author's Address..........................................23 97 Expiration and File Name..................................23 99 Appendix A: Initial Payment System Names..................24 101 Appendix B: Simplified BNF................................25 103 1. Introductions 105 Applications level Internet commerce requires a means to (1) indicate 106 prices and acceptable methods of payment, (2) tender payment, and (3) 107 issue a receipt acknowledging payment or indicate if payment fails. 109 This document specifies a character string syntax for these three 110 items. 112 1.1 Applications Level Applicability 114 Payment facilities could be applied at a number of levels. This 115 specification is concerned only with applications level data items 116 and services. It does not in any way concern itself with network 117 level packets or quality of service nor does it concern itself 118 directly with transport level connections or quantity or quality of 119 service except as these transport level measures impact application 120 services. 122 This proposed syntax is concerned with such matters as access to a 123 web page page, storage of a file, initiation of a telnet session, or 124 conducting an extensive WAIS search. These are generally user 125 visible and meaningful data objects or tasks. 127 Within most legal systems, the owners of such data objects and/or the 128 owners of the facilities used to present such objects or perform such 129 tasks are frequently entitled to require some recompense if they 130 choose to do so. This document does not concern itself with the 131 morality of such laws or requirements but merely provides a syntax 132 whereby cooperating entities may speak at that level about prices and 133 payments. 135 There is no requirement that the "currencies" used with this syntax 136 be the usually recognized national or international currencies. For 137 example, some transactions could be denominated in frequent flyer 138 miles or other private artificial unit. 140 1.2 Overview of this document 142 Sections 2 and 3 below define a basic syntactic framework for price 143 tags, payments, and receipts. 145 Sections 4 through 7 specify a standard for inclusion of these items 146 in transactions for the World Wide Web (HTTP/HTML), File Transfer 147 Protocol (FTP), Telnet, and the Simple Message Transfer Protocol 148 (SMTP). 150 Section 8 lists some protocols to which application level payment 151 systems should not be applied. 153 Section 9 discusses security considerations. 155 Appendix A is an initial list of payment systems that are or are 156 planned to be usable via this syntax. 158 Appendix B gives a semi-formal BNF-like description of the syntax. 160 2. Price Tags 162 A uniform price tag format is needed to indicate when payment is due, 163 how much, and what methods are acceptable by the seller. Such a 164 price tag must include the specification of one or more acceptable 165 payment systems (with a provision for payment system specific 166 information where needed) and will almost always include one or more 167 prices. 169 Sections 2.1 and 2.2 below describe prices and payment system strings 170 and Section 2.3 assembles these for complete price tags. 172 2.1 Prices 174 Prices are encoded as character strings consisting of a number 175 followed by a currency code. 177 These currency codes are the three letter ISO 4217 codes, Internet 178 Assigned Number Authority (IANA) registered four letter or longer 179 currency codes, or private use currency codes starting with "x-". 180 (ISO 4217 code normally consist of the two letter country code 181 followed by a letter mnemonic for the major unit of currency.) 182 Currency codes are case insensitive. One and two letter codes 183 appearing in the place of a country code are reserved for future use. 185 The number preceding the currency designation is the quantity of 186 major units of that currency. It may optionally have a decimal point 187 and additional decimal fraction digits for specifying minor unit or 188 fractions of units. (Some currencies, such as US Dollars or British 189 Pounds have minor units (cents and pennies). Others, such as Japanese 190 Yen and Italian Lira do not.) Fractional digits may continue 191 indefinitely after the decimal point but payment systems may define 192 how many digits they utilize. 194 Somes examples: 196 2.34gbp, 79ALL, 1.23456cad, 0.125usd 198 which signify 2 pounds and 34 pence sterling, seventy nine Albanian 199 Leks, one dollar and 23 and 456 thousandths cents Canadian, and one 200 eighth of a US dollar. 202 2.2 Payment System Strings 204 Payment system strings consist of the payment system name, a colon, 205 and any payment system specific information (such as what account 206 within that payment system the payment should be made payable to). 208 Payment system names are case insensitive, four or more letters long, 209 and are indicated by a terminating colon. One to three letter codes 210 occurring in the place of payment system names are reserved for 211 future use. 213 Payment system specific information must be encoded so that it 214 contains no internal spaces or unusual characters as described in 215 Appendix B. It is up to the named payment system to encode and 216 decode any information it requires so as to fit within this syntax. 217 Use of the base64 encoding defined in RFC 1521 is recommended. The 218 payment system specific information, if any, appears immediately 219 after the payment system name and colon and is terminated by white 220 space or the end of the price tag character string. 222 A registry of payment system names is maintained by IANA. Initial 223 payment system names are listed in Appendix A. For experimental use 224 pursuant to bilateral agreement between the parties involved payment 225 system name starting with "x-" may be used. No names of this form 226 will be officially registered. 228 2.3 Price Tags 230 A complete price tag consists of a string of white space separated 231 prices and payment system strings. There must be at least one 232 payment system string present. 234 Normally there will also be at least one price. However, there are 235 circumstances under which the cost of a service in highly 236 unpredictable and the seller is, in effect, requesting a payment 237 system and account to which they can attempt to charge indefinite 238 amounts. Under these circumstances, it is recommended that a price 239 be listed which is a reasonable ceiling such that if costs exceed 240 that, the seller which have to present another price tag; however, it 241 is permitted to omit the price and list only a payment system in a 242 price tag. 244 Payment systems SHOULD provide a means for a limited amount of 245 arbitrary seller information to be included in the payment system 246 specific part of a price tag and be returned to the seller within a 247 payment message based on that price tag. 249 A price appearing after a payment system string applies only to that 250 system. Putting a price before the first payment system specific 251 information makes that price a default for every payment system 252 specified. The default can be overridden by specifying a different 253 amount for that currency after a particular payment system. 255 For example: 257 33.45all foocash:xxxx 22eTb barsys:yyyy 9.999ghC 259 indicates that payment of twenty two Ethiopian Birrs via the foocash 260 payment system or 9.999 Ghanaian Cedis via the barsys system or 33.45 261 Albania Leks via either system is acceptable. 263 In cases where the cost of the service is not known in advance, the 264 price can be an estimate, deposit request, or the like, with any 265 overpayment refunded. Underpayment can be collected by requesting an 266 additional payment from the client. In the absence of trust between 267 the parties, frequent small payments may be required. 269 3. Payments and Receipts 271 After encountering a price tag, either initially, during a session, 272 or in conjunction with a "payment required" error, an application 273 needs some method of tendering payment. This is done with a payment 274 system string with the same syntax as described in Section 2.2 above. 275 For example: 277 foocash:29Uso+Oa/e92micHd4s3= 279 The payment system used in the payment is selected from among those 280 in the price tag as those are known to be supported by the seller. 281 Payment systems will normally include in the payment system specific 282 information some sort of serial or transaction number so that 283 retransmission of a message containing the string will not result in 284 duplicate payment. 286 Normally the seller will provide a receipt for the amount of money 287 actually collected or a message indicating payment failure or error. 288 This will be via a receipt character string which is also simply in 289 the form of a payment system string. For example: 291 barsys:8n7VtC2+uL341/ 293 Payment systems will normally include in the payment system specific 294 information of a receipt, in addition to an indication of how much 295 the receipt is for, some type of serial or transaction number, so 296 that retransmission of a message containing the receipt will not 297 result in confusion. 299 A null payment or receipt string is explicitly permitted in most 300 contexts as a way for an entity to indicate merely that it is payment 301 syntax aware. 303 One or more payment system names in isolation are permitted in a 304 payment or receipt context but only as a way to indicate that a 305 particular payment system is understood. Any actual payment or 306 receipt must have a colon and non-null payment specific information. 307 Only one such full payment system string can occur in a payment or 308 receipt. 310 Depending of payment system details, a refund can be implemented in 311 two way. It can be a payment message from the seller to the buyer, 312 normally leading to a receipt from the buyer to the seller. Or the 313 seller may be able to directly refund to the buyer's account or the 314 like and simply send the buyer a receipt. In some payment system, 315 both refund techniques might be available. In others, refunding may 316 not be possible. 318 The content and/or encoding of the payment system specific 319 information would normally differ between the price tag, payment, and 320 receipt contexts but this is a matter only of concern to the payment 321 system. Errors in formating or the like that are internal to a 322 payment or receipt should generally be handled by being logged and/or 323 reported by an error message encoded into a receipt. Errors in a 324 price tag may be reported in a payment or receipt. Great care should 325 be taken to be sure to avoid any situation that could result in an 326 endless loop of receipts. 328 4. Use in the World Wide Web 330 The World Wide Web is a rapidly evolving system for information 331 interaction that is being increasingly used for commerce. It is 332 particularly well suited for the inclusion of payment systems, 333 especially any designed for efficient handling of very small payments 334 which might reasonably be incurred on a "per web page" basis or the 335 like. 337 In the Web, a price is indicated by a COST parameter, as described 338 below, which can occur within an anchor, HTML document header, or 339 several places in a FORM. Payment can be included with any HTTP 340 request using the "ChargeTo:" header. A receipt can be included in 341 any HTTP reply using the "Receipt:" header. 343 4.1 Web Browser User Interface 345 It is important that small payments be closely integrated into the 346 browser user interface. An expected mode of operation will be one of 347 many small payments so the overhead associated with each must be 348 small. It is unacceptable for the user to necessarily interact with 349 a separate screen or window to approve each small payment although a 350 user who wishes to do so should have that option. 352 The user should be able to establish some threshold (default perhaps 353 around 0.1usd or equivalent) such that actions incurring that charge 354 or less are semi-automatic. That is, no special approval action is 355 required, although color coding or the like should be used to 356 distinguish toll links from free links, an optional sound could be 357 made when any money is sent, or other clues used to give the user a 358 feel for what is going on. 360 To avoid spending an unexpectedly large amount in small pieces, 361 possibly a bank graphic or the like should be displayed to show how 362 much cash is still available to the browser before the user will have 363 to take action. The act of refilling the bank would be a more heavy 364 weight operation requiring user interaction or, to get a default 365 amount, at least user approval. 367 4.2 Anchor Embedded Costs 369 A cost can appear in an anchor. This is a very strong hint that 370 payment of the indicated amount should accompany the GET operation 371 that occurs when following that link. Note, however, that it is 372 ultimately up to the server being hit to determine if payment is 373 adequate or to follow the course it chooses for different levels of 374 payment. 376 The cost is given by a COST parameter in the anchor. For example: 378 380 Great stuff for one thin dime! 382 It is recommended that toll links be shown in a different color or 383 type style from toll-free links. Browsers may wish to go further and 384 indicate different cost levels, particularly costs above or below any 385 "automatic approval" level the user has. When the user has their 386 pointer over the link, the browser may wish to display the payment 387 particulars in a similar way to that in which it displays the URL. 388 (Such a display could be filtered to the currency and/or payment 389 system(s) actually available to the user.) 391 Notice that the cost, if any, indicated by the anchor text ("Great 392 stuff..." above) could be different from the actual "COST=" parameter 393 which controls the payment sent with the request. In turn, the 394 "COST=" amount could be different from what the server really wants. 395 Or the server may provide different data or services for different 396 payment amount. Such variable payment schemes may be better handled 397 with a FORM as described below. 399 4.3 Page Header Price Tag 401 The cost for accessing an HTML page can be included in the header. 402 For example: 404 405 Mating Habits of the Red Breasted Geek 406 0.75usd 0.99cad cybercash:A8jne8W2/sw== 407 ... 409 An attempt to get such a document without payment or with inadequate 410 payment should fail (see Payment Required Error section below). A 411 second attempt with payment will be required. This could be done in 412 a manner similar to an access restriction failure followed by a 413 second attempt with access authorization information. 415 Implementing page header cost requires that the HTML for a web page 416 be partly understood by the server, at least through the head, but 417 this is necessary to implement the "title:" and "link:" response 418 entity header fields anyway. 420 4.4 HTML Form Price Tags 422 A cost can be associated with a form and with multiple choice items 423 within the form. For example: 425
427 Miscellaneous text, etc. 429 plain vanilla 430 chocolate fudge 433

Your quality of service: 438

440 The COST associated with the form is a base price to which any 441 multiple choice item costs are added. The form level COST may be 442 omitted and COSTs can still appear with multiple choice items. The 443 COST associated with a "select" is a default which applies only if no 444 item is selected. When an item is selected, it over-rides the 445 selection level cost and become the price component added into the 446 total form price for that selection. 448 The normally required payment system string can be omitted from some 449 of the form COST parameters, in which case any prices add to the 450 amount for all payment systems. But one or more payment systems and 451 their payment system specific parameters must be determinable if any 452 payment is to be sent. The payment system specific information 453 associated with the last encountered instance of a payment system 454 field in processing the form is used. If no payment system field is 455 encountered, then no payment will be sent with the request even 456 though "COST=" parameters are present. 458 As with anchor costs, it is desirable to indicate the cost of 459 multiple choice items by color coding and the cost of activating the 460 form by color coding the submit button. Note that the submit button 461 could change from free to toll or the like as choices are made in the 462 form. 464 4.5 Web Payments and Receipts 466 Any HTTP request can be accompanied with payment by including a 467 payment line in the message header. This consists of the "ChargeTo:" 468 header label followed by a payment system string; however, 469 "ChargeTo:" can appear with one or more bare payment system names for 470 the purpose of indicating that the browser understands those systems 471 without conveying any actual payment. Examples: 473 ChargeTo: cybercash:A8jne8W2/sw== 475 ChargeTo: foocash barsys 477 The first example is in the form of a payment via cybercash. The 478 second example is an indication by the sender that it understands the 479 foocash and barsys payment systems. 481 The browser should keep track of such actual payments it has sent and 482 re-send the identical payment if the request needs to be retried with 483 access authorization information or due to a transient error, rather 484 than sending additional funds. 486 The collection of payment or the specifics of the failure of a 487 tendered payment are indicated back to the customer by a receipt line 488 in the response header. This consists of the "receipt:" header label 489 followed by a payment system string. For example: 491 Receipt: cybercash:A8jne8W2/sw== 493 There cases where a larger payment is collected initially and the 494 unused portion refunded or where adjustments are required after a 495 purchase. Because of this, ChargeTo and Receipt headers are both 496 allowed in both HTTP requests and responses. 498 4.6 Payment Required Error 500 If an HTTP request arrives without sufficient payment (or with none 501 at all) and payment is required by the server, the server can simply 502 provide a web page with limited or no actual information and possibly 503 one or more links with COST parameters embedded in them. 504 Alternatively, a "402 payment required" error is returned in which 505 case there must be a "www-cost:" response header field analogous to 506 the "www-authenticate:" header field for a "401 unauthorized"" 507 response. The value of the www-cost field is the same as for the 508 COST parameter described above. 510 This is similar to an access restriction error in that the browser 511 can just try again with payment included the way they can try again 512 with access information. It may be possible to combine these by 513 returning a 402 error with the HTML accompanying the error having a 514 link with a COST parameter pointing to the originally sought item. 515 This would combine automatic charging for browsers that have 402 516 error processing implemented with a convenient way for the user to 517 re-request with payment for browsers that understand anchor COST 518 parameters but do not automatically handle 402 errors. 520 4.7 Web Proxies 522 When information that has an owner and price is being cached and 523 served to multiple different users by a proxy, the payments should be 524 requested by the proxy. The safest thing for the proxy to do is to 525 send payment to the entity it retrieved the data from using an HTTP 526 request with a ChargeTo header and the PAYMENT method. 528 If the proxy understands the payment system well enough and there are 529 no firewall problems, the proxy may be able to collect the payment 530 and directly transfer funds to the information owner. 532 It is not expected that proxy payment collection will be perfect. 533 There will initially be many dumb proxies that don't understand 534 payment and there may be proxies that deliberately avoid collecting 535 and forwarding payment. But any large scale avoidance of payment 536 will be noticed. In any case, if the proxy can cache a copy, so 537 could the user, who could then give copies to all his friends. The 538 ease of automatically making small payments for information through 539 this syntax is hoped to produce a net reduction in unauthorized 540 information copying. 542 5. Use in File Transfer Protocol 544 An FTP server may wish to charge for a file transfer (either way) or 545 for an FTP session. 547 It may do so by requesting that an ACCT command be sent via the 332 548 or 532 reply codes. 332 is used to indicate that a received command 549 is being held in abeyance pending receipt of an ACCT while 532 550 indicates that a received command has been abandoned due to lack of 551 payment and an ACCT command needs to be sent before attempting the 552 command again. 554 Price tags are indicated in the 332 or 532 text by a string at the 555 beginning of the form 557 559 in the 332 or 532 text, i.e., a literal "". The word "cost" is case insensitive. Arbitrary additional text 562 may be included after the price tag. 564 A payment can be send by simply including a payment string, as 565 defined in section 3, after the ACCT command. 567 A successful receipt is rendered by returning a 233 reply with a 568 receipt payment system string as the beginning of its text. A 569 payment failure receipt is rendered by returning a 433 or 533 reply 570 depending on whether the failure is transient or permanent. In 571 either case, the receipt string can be terminated by white space and 572 additional text human readable text placed after the receipt string 573 in the reply. 575 (See RFC 959.) 577 SUMMARY 579 Price Tags - in existing 332 and 532 replies. 580 Payments - in existing ACCT command. 581 Receipts - in new 233, 433, and 533, replies. 583 6. Use in Telnet 585 A host may wish to charge for a Telnet session. Telnet option code 586 [TBD] is used to initially negotiate agreement of the two parties to 587 speak about payment. As with other Telnet options, either side can 588 sent IAC WILL xxx, in response to which an IAC DO xxx indicates 589 agreement and an IAC DON'T xxx indicate refusal. Or a party can send 590 IAC DO xxx to which IAC WILL xxx indicates agreement and an IAC WON'T 591 xxx indicates refusal. 593 After agreement to speak about payment has been reached, Telnet 594 subnegotiation strings can be exchanged, bracketed with IAC SB and 595 IAC SE. The initial subnegotiation byte indicates the type of 596 payment message following in the rest of the subnegotiation byte 597 string as follows: 599 Byte Meaning 600 ---- ------- 602 01 Price-tag 603 02 Payment 604 03 Receipt 606 If desired, arbitrary binary representations may be used for payment 607 system specific information after the colon terminating the system 608 name in payments and receipts (as long as bytes with value 255 are 609 doubled as per the Telnet standard). Termination can be unambiguously 610 determined by the IAC SE sequence. However, price tags must stick 611 with the ASCII syntax given herein as they must be parsed by systems 612 that may not understand any particular payment system. 614 (See RFCs 854, 855.) 616 7. Use in Simple Message Transfer Protocol 618 A host or user may wish to charge for the receipt of mail. This is 619 accomplished via the new 332 reply code. This is an interim success 620 code that indicates that further information is required to complete 621 a pending command. Note that use of 332 after the SMTP RCPT command 622 would be a simple way to implement any particular user requiring 623 payment for mail to be delivered to them and its use after the MAIL 624 command would be a simple way to implement a system requiring payment 625 for mail from all or certain sources (although this information is 626 easy to forge). 628 Payment is indicated by the new ACCT command. This is followed by a 629 payment string as defined in section 3 above. 631 Charging for mail may cut a host or user off from the normal flow of 632 mail. It seems unlikely that most individuals or mailing lists would 633 be willing to pay to send mail to an address. However, it is easy to 634 envision cases where a service for which it would be reasonable to 635 charge is requested via email. Or there may be individuals who do 636 want to substantially cut themselves off from most mail or mail from 637 certain senders. 639 SMTP servers that speak ESMTP (see RFC 1651) may optionally give the 640 new EHLO keyword ACCT. However, ESMTP is designed for servers to 641 list features to be optionally invoked by clients. It is not really 642 appropriate as a means for servers to indicate features that they 643 will *require* of clients. 645 In any case, it is believed that no negotiation is necessary for an 646 SMTP server to use the new 332 reply code. RFC 821 is clear that the 647 receipt of any 3xx reply code after a MAIL, RCPT, etc. command is to 648 be considered an error. This is the appropriate understanding for an 649 SMTP client that does not understand payment when an SMTP server 650 requires payment. 652 The rules and state diagrams in RFC-821 are hereby amended and the 653 state diagram for MAIL, RCPT, SEND, SOML, and SAML is modified to the 654 following: 656 1 +---+ 1,3 657 FLOW FOR +----------->| E |<-----+ 658 PAYMENT AWARE | +---+ | 659 SMTP SERVER | | 660 | 2 +---+ 2 | 661 +----------->| S |<-----+ 662 | +---+ | 663 | | 664 | | 665 +---+ cmd +---+ 3 +---+ ACCT +---+ 666 | B |--------->| W |----->| |------->| W | 667 +---+ +---+ +---+ +---+ 668 | | 669 | 4,5 +---+ 4,5 | 670 +----------->| F |<-----+ 671 +---+ 673 A successful receipt is rendered by returning the new 233 reply with 674 a receipt payment system string as the beginning of its text. A 675 payment failure receipt is rendered by returning the new 433 or 533 676 replies depending on whether the failure is transient or permanent. 677 In either case, the receipt string can be terminated by white space 678 and additional text human readable text placed after the receipt 679 string in the reply. 681 The middle digit 3 in SMTP reply codes is reserved for accounting, 682 corresponding to its existing use in FTP. 684 (See RFCs 821, 1651.) 686 SUMMARY 688 Price Tags - in new 332 reply. 689 Payments - in new ACCT command. 690 Receipts - in new 233, 433, and 533 replies. 692 8. Protocols to Which Payment is not Applicable 694 Some protocols are sufficiently basic to the operation of the network 695 or provide sufficiently light-weight access to public information 696 that attempts to impose application level payment would be 697 inappropriate. Some of these protocols, listed below, SHOULD NOT 698 make use of this syntax or impose prices or payments. 700 8.1 The Domain Name System 702 Part of the philosophy of the Domain Name System (DNS) is that it 703 contains public information and generally gives the same answers to 704 all inquirers. It is used for such fundamental purposes as 705 translating domain names (such as tam.cybercash.com) into IP 706 addresses or specifying SMTP mail backup and routing servers. As 707 such, charges SHOULD NOT be imposed for DNS queries. 709 (See RFCs 1034, 1035.) 711 8.2 The Finger Service 713 Finger is an optional information service intended to permit remote 714 users to learn a limited amount of information about a user or users 715 on an Internet host. Information such as the time they last logged 716 in or contents of their ".plan" file. There are serious security 717 considerations involved in allowing finger access to a host and hosts 718 are free to decide how much such access, if any, they will provide. 720 In some cases, finger servers have been set up to act as information 721 retrieval or reporting mechanisms, but this was not the designed 722 purpose of finger and, in most cases, there are better mechanisms to 723 provide such access. 725 If finger access is provided because a site wishes to be open, 726 charges SHOULD NOT be imposed. 728 (See RFC 1288.) 730 8.3 The Auth Service 732 This service, when implemented, allows a remote host to determine the 733 user associated with a TCP connection. It is intended as a security 734 and auditing tool although it is weak in the face of anyone with 735 direct access to the TPC or IP level who was attempting to mislead 736 it. Implementation is optional. 738 Those who chose to provide this service are doing so to cooperate in 739 such security or auditing at some sacrifice in the privacy of their 740 users. Charging for this service makes little sense in this context. 742 (See RFC 931.) 744 8.4 The ECHO, DISCARD, and CHARGEN Services 746 These are light weight services intended for network maintenance. 747 ECHO echoes the packet sent to it (see RFC 862), DISCARD throws away 748 packets sent to it but maintains the connection (see RFC 863), and 749 CHARGEN generates an infinite number of random characters and sends 750 them until the calling party disconnects (see RFC 864). 752 Hosts are free to decide which, if any, of these three services they 753 wish to provide (although ECHO is Recommended), but SHOULD NOT impose 754 any charges for them. 756 9. Security Considerations 758 Getting authorization to construct payments may, depending on the 759 payment system, require the user to enter a passphrase. For example, 760 a passphrase might be required at the beginning of their session to 761 unlock a private key. Thus the user could be vulnerable to Trojan 762 horse web browsers, ftp clients, telnet clients, etc., as they are 763 to many other types of Trojan horse applications. Use of "secure" 764 application distribution with signed executables, checksums, virus 765 detection, etc., should be encouraged. 767 An adversary may be able to observe or modify traffic to and from an 768 application. Payment systems should be designed so that such 769 observation results in minimal loss of privacy and such observation 770 or modification can not result in hijacking a payment. Note that an 771 adversary that has complete control over application communications 772 can pretend to be a merchant just as it could by controlling an end 773 node. However, such impersonation from an end node may be easier to 774 trace and control than impersonation at an unknown point along the 775 communications path. Message (MOSS, SHTTP, etc.) and connection 776 (IPSEC, IPv6, SSL, etc.) security protocols are available to help 777 protect the communications path. 779 On receipt of an advance payment, a server is capable of charging the 780 user regardless of whether the server actually provides the data or 781 services being charged for. A server could even send back an error 782 message but keep and use the payment. Some means of automatically 783 logging payments that result in a software or human detectable 784 failure to deliver should be implemented so these can be examined for 785 patterns or cross checked with payment system statements of account. 787 A merchant can withhold and fail to send back to the user a receipt. 788 Applications should assume any payment sent will be collected 789 regardless of whether they get a receipt back. 791 With payment systems, a monetary cost can sometimes be associated 792 with downloaded data. Caching algorithms may wish to take this into 793 account and cache costly data in preference to free data. Servers 794 should accept the identical data request from the same net entity for 795 a reasonable amount of time even if the payment being presented 796 appears to be a duplicate. Transient errors may have prevented use of 797 the data previously downloaded for that request. 799 A bad client application could generate payments exceeding the funds 800 or authorization available to it. Servers should verify payments 801 promptly and be cautious of extending services or goods unless they 802 can confirms that payment is good. Applications and payment systems 803 should be designed to limit the amount of funds a rogue application 804 could transfer. 806 References 808 [ISO 4217] - Codes for the representation of currencies and funds 810 [RFC 821] - J. Postel, "Simple Mail Transfer Protocol", 08/01/1982. 812 [RFC 854] - J. Postel, J. Reynolds, "Telnet option specifications", 813 05/01/1983. 815 [RFC 855] - J. Postel, J. Reynolds, "Telnet Protocol specification", 816 05/01/1983. 818 [RFC 959] - J. Postel, J. Reynolds, "File Transfer Protocol", 819 10/01/1985. 821 Author's Address 823 Donald E. Eastlake, 3rd 824 CyberCash, Inc. 825 318 Acton Street 826 Carlisle, MA 01741 USA 828 Telephone: +1 508 287 4877 829 +1 703-620-4200 (main office, Reston, Virginia, USA) 830 email: dee@cybercash.com 832 Expiration and File Name 834 This draft expires 28 December 1995. 836 Its file name is draft-eastlake-internet-payment-00.txt. 838 Appendix A: Initial Payment System Names 840 This is the initial alphabetic list of the initial registered payment 841 system names that intend to be usable via this syntax. 843 [send email to author, dee@cyercash.com, if you would like to be 844 added] 846 Company Name Email Contact Home Page 847 ------------ ------------- --------- 848 Payment System Name - (brief description) 849 ------------------- 851 CyberCash, Inc. info@cybercash.com http://www.cybercash.com 852 cybercash - (credit card) 853 cash - (cash) 855 Appendix B: Simplified BNF 857 This is a BNF-like description of the Payment Protocol syntax syntax, 858 using the conventions of RFC822, except that "|" is used to designate 859 alternatives, and brackets [] are used around optional or repeated 860 elements. Briefly, literals are quoted with "", optional elements are 861 enclosed in [brackets], and elements may be preceded with * to 862 designate n or more repetitions of the following element; n defaults 863 to 0. 865 ;prices 867 isocurrency = alpha alpha alpha 868 ietfcurrency = 4*alpha 869 privatecurrency = "x-" 4*alpha 870 currency = isocurrency | ietfcurrency | privatecurrency 871 digits = 1*digit 872 decimalpoint = "." | "," 873 number = digits | digits decimalpoint *digit 875 cost = number currency 877 ;payment system strings 879 ianapaysys = 4*alpha 880 privatepaysys = "x-" 4*alpha 881 paysysname = ianapaysys | privatepaysys 883 paysys = paysysname ":" *uchar 885 ;price tag 887 pricetag = *sp paysys *[ 1*sp cost | 1*sp paysys ] *sp | 888 *sp *[ cost 1*sp | paysys 1*sp ] paysys *sp 890 ;miscellaneous definitions 892 lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | 893 "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | 894 "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | 895 "y" | "z" 896 hialpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | 897 "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | 898 "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | 899 "Y" | "Z" 900 alpha = lowalpha | hialpha 901 digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | 902 "8" | "9" 903 other = "$" | "-" | "_" | "." | "+" | "/" | "=" | "@" 904 hex = digit | "A" | "B" | "C" | "D" | "E" | "F" | 905 "a" | "b" | "c" | "d" | "e" | "f" 906 escape = "%" hex hex 907 sp = " " 908 uchar = alpha | digit | other | extra | escape