From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2706.txt | 731 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 731 insertions(+) create mode 100644 doc/rfc/rfc2706.txt (limited to 'doc/rfc/rfc2706.txt') diff --git a/doc/rfc/rfc2706.txt b/doc/rfc/rfc2706.txt new file mode 100644 index 0000000..149704f --- /dev/null +++ b/doc/rfc/rfc2706.txt @@ -0,0 +1,731 @@ + + + + + + +Network Working Goup D. Eastlake +Request for Comments: 2706 IBM +Category: Informational T. Goldstein + Brodia + October 1999 + + + ECML v1: Field Names for E-Commerce + + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved. + +IESG Note + + This document is the output of a vendor consortium, and is not the + output of an IETF Working Group. Implementors of this specification + are warned that this data model is heavily biased toward conventions + used in the United States, and the English language. As such it is + unlikely to be suitable for international or multilingual use in the + global Internet. + +Abstract + + Customers are frequently required to enter substantial amounts of + information at an Internet merchant site in order to complete a + purchase or other transaction, especially the first time they go + there. A standard set of information fields is defined as the first + version of an Electronic Commerce Modeling Language (ECML) so that + this task can be more easily automated, for example by wallet + software that could fill in fields. Even for the manual data entry + case, customers will be less confused by varying merchant sites if a + substantial number adopt these standard fields. + + + + + + + + + + + +Eastlake & Goldstein Informational [Page 1] + +RFC 2706 ECom Field Names October 1999 + + +Acknowledgements + + The following persons, in alphabetic order, contributed substantially + to the material herein: + + George Burne, Trintech + + Joe Coco, Microsoft + + Kevin Weller, Visa + +Table of Contents + + 1. Introduction................................................2 + 1.1 Background.................................................2 + 1.2 Relationship to Other Standards............................3 + 1.3 Areas Deferred to Future Versions..........................4 + 2. Using The Fields............................................4 + 2.1 Presentation of the Fields.................................4 + 2.2 Methods and Flow of Setting the Fields.....................5 + 2.3 HTML Example...............................................6 + 3. Field Definitions...........................................7 + 4. End Notes...................................................9 + 5. Security Considerations....................................10 + References....................................................11 + Authors' Addresses............................................12 + Full Copyright Statement......................................13 + +1. Introduction + +1.1 Background + + Today, numerous merchants are successfully conducting business on the + Internet using HTML-based forms. The data formats used in these forms + varies considerably from one merchant to another. End-users find the + diversity confusing and the process of manually filling in these + forms to be tedious. The result is that many merchant forms, + reportedly around two thirds, are abandoned during the fill in + process. + + Software tools called electronic wallets can help this situation. A + digital wallet is an application or service that assists consumers in + conducting online transactions by allowing them to store billing, + shipping, payment, and preference information and to use this + information to automatically complete merchant interactions. This + greatly simplifies the check-out process and minimizes the need for a + consumer to complete a merchant's form every time. Digital wallets + that fill forms have been successfully built into browsers, as helper + + + +Eastlake & Goldstein Informational [Page 2] + +RFC 2706 ECom Field Names October 1999 + + + applications to browsers, as stand-alone applications, as browser + plug-ins, and as server-based applications. But the proliferation of + electronic wallets has been hampered by the lack of standards. + + ECML (Electronic Commerce Modeling Language, ) Version + 1 provides a set of simple guidelines for web merchants that will + enable electronic wallets from multiple vendors to fill in their web + forms. The end-result is that more consumers will find shopping on + the web to be easy and compelling. + + The set of fields documented herein was developed by the + Wallet/Merchant Standards Alliance (www.ecml.org) which now includes, + in alphabetic order, the following: + + American Express (www.americanexpress.com) + AOL (www.aol.com) + Brodia (www.brodia.com) + Compaq (www.compaq.com) + CyberCash (www.cybercash.com) + Discover (www.discovercard.com) + FSTC (www.fstc.org) + IBM (www.ibm.com) + Mastercard (www.mastercard.com) + Microsoft (www.microsoft.com) + Novell (www.novell.com) + SETCo (www.setco.org) + Sun Microsystems (www.sun.com) + Trintech (www.trintech.com) + Visa (www.visa.com) + + The fields are derived from and consistent with the W3C P3P base data + schema at + + . + +1.2 Relationship to Other Standards + + ECML Version 1 is not a replacement or alternative to SSL/TLS [RFC + 2246], SET [SET], XML [XML], or IOTP [IOTP]. These are important + standards that provide functionality such as non-repudiatable + transactions, automatable payment scheme selection, and smart card + support. + + ECML may be used with any payment mechanism. It simply allows a + merchant to publish consistent simple web forms. + + Multiple wallets and multiple merchants plan to interoperably support + ECML. This is an open standard. ECML is designed to be simple. + + + +Eastlake & Goldstein Informational [Page 3] + +RFC 2706 ECom Field Names October 1999 + + + Version 1 of the project adds no new technology to the web. A + merchant can adopt ECML and gain the support of these multiple + Wallets by making very simple changes to the HTML pages that they + currently use to support their customers. Use of ECML requires no + license. + +1.3 Areas Deferred to Future Versions + + Standardization of information fields transmitted from the merchant + to the consumer, considerations for business purchasing cards, non- + card payment mechanisms, wallet activation, privacy related + mechanisms, additional payment mechanisms, and any sort of + "negotiation" were among the areas deferred to consideration in + future versions. Hidden or other special fields were minimized. The + primary target was North American consumer to merchant electronic + commerce. + +2. Using The Fields + + To conform to this document, the field names shall be as listed in + section 3 below. Note: this does not impose any restriction on the + user visible labeling of fields, just on their names as used in + communication with the merchant. + +2.1 Presentation of the Fields + + There is no necessary implication as to the order or manner of + presentation. Some merchants may wish to ask for more information, + some less by omitting fields. Some merchants may ask for the + information they want in one HTML form on one web page, others may + ask for parts of the information at different times on different + pages. For example, it is common to ask for "ship to" information + earlier, so shipping cost can be computed, before the payment method + information. Some merchants may require that all the information + they request be provided while other make much information optional, + etc. + + There is no way with version 1 of ECML to indicate what fields the + merchant considers mandatory. From the point of view of customer + software, all fields are optional to complete. However, the merchant + may give an error or re-present a request for information if some + field it requires is not completed, just as it may if a field is + completed in a manner it considers erroneous. + + + + + + + + +Eastlake & Goldstein Informational [Page 4] + +RFC 2706 ECom Field Names October 1999 + + +2.2 Methods and Flow of Setting the Fields + + There are a variety of methods of communication possible between the + customer and the merchant by which the merchant can indicate what + fields they want that the consumer can provide. Probably the easiest + to use for currently deployed software is as fields in an HTML + [HTML4.0] form. Other possibilities are to use the W3C P3P protocol + or the IOTP Authenticate transaction [IOTP]. + + User action or the appearance of the Ecom_SchemaVersion field are + examples of triggers that could be used to initiate a facility + capable of filling in fields. It is required that the + Ecom_SchemaVersion field, which is usually a hidden field, be + included on every web page that has any "Ecom_" fields. + + Because web pages can load very slowly, it may not be clear to an + automated field fill-in function when it is finished filling in + fields on a web page. For this reason, it is recommended that the + Ecom_SchemaVersion field be the last "Ecom_" field on a web page. + + Merchant requests for information can extend over several web pages. + Without further provision, a facility could either require re- + starting on each page or possibly violate or appear to violate + privacy by continuing to fill in fields for pages beyond with end of + the transaction with a particular merchant. For this reason the + Ecom_TransactionComplete field, which is normally hidden, is + provided. It is recommended that it appear on the last web page + involved in a transaction, just before an Ecom_SchemaVersion field, + so that multi-web-page automated field fill in logic could know when + to stop if it chooses to check for this field. + + + + + + + + + + + + + + + + + + + + + +Eastlake & Goldstein Informational [Page 5] + +RFC 2706 ECom Field Names October 1999 + + +2.3 HTML Example + + An example in HTML might be as follows: + + + + eCom Fields Example + + +
+ Please enter card information: +

Your name on the card + +
The card number + +
Expiration date (MM YY) + + + + +
+ +

+ + + + After all of the pages are submitted, the merchant will reply with a + confirmation page informing both the user and the wallet that the + transaction is complete. + + + + eCom Transaction Complete Example + + +
+ Thank you for your order. It will be shipped in several days. + + +
+ + + + + + + + + +Eastlake & Goldstein Informational [Page 6] + +RFC 2706 ECom Field Names October 1999 + + +3. Field Definitions + + The fields are listed below along with the minimum data entry size to + allow. Note that these fields are hierarchically organized as + indicated by the embedded underscore ("_") characters. Appropriate + consumer to merchant transmission mechanisms may use this to request + and send aggregates, such as Ecom_Payment_Card_ExpDate to encompass + all the date components or Ecom_ShipTo to encompass all the ship to + components that the consumer is willing to provide. The marshalling + and unmarshalling of the components of such aggregates depends on the + data transfer protocol used. + + IMPORTANT NOTE: "MIN" in the table below is the MINIMUM DATA SIZE TO + ALLOW FOR ON DATA ENTRY. It is NOT the minimum size for valid + contents of the field and merchant software should, in most cases, be + prepared to receive a longer or shorter value. Merchant dealing with + areas where, for example, the state/province name or phone number is + longer than the "Min" given below must obviously permit longer data + entry. In some cases, however, there is a maximum size that makes + sense and where this is the case, it is documented in a Note for the + field. + + FIELD NAME Min Notes + + ship to title Ecom_ShipTo_Postal_Name_Prefix 4 ( 1) + ship to first name Ecom_ShipTo_Postal_Name_First 15 + ship to middle name Ecom_ShipTo_Postal_Name_Middle 15 ( 2) + ship to last name Ecom_ShipTo_Postal_Name_Last 15 + ship to name suffix Ecom_ShipTo_Postal_Name_Suffix 4 ( 3) + ship to street line1 Ecom_ShipTo_Postal_Street_Line1 20 ( 4) + ship to street line2 Ecom_ShipTo_Postal_Street_Line2 20 ( 4) + ship to street line3 Ecom_ShipTo_Postal_Street_Line3 20 ( 4) + ship to city Ecom_ShipTo_Postal_City 22 + ship to state/province Ecom_ShipTo_Postal_StateProv 2 ( 5) + ship to zip/postal code Ecom_ShipTo_Postal_PostalCode 14 ( 6) + ship to country Ecom_ShipTo_Postal_CountryCode 2 ( 7) + ship to phone Ecom_ShipTo_Telecom_Phone_Number 10 ( 8) + ship to email Ecom_ShipTo_Online_Email 40 ( 9) + + bill to title Ecom_BillTo_Postal_Name_Prefix 4 ( 1) + bill to first name Ecom_BillTo_Postal_Name_First 15 + bill to middle name Ecom_BillTo_Postal_Name_Middle 15 ( 2) + bill to last name Ecom_BillTo_Postal_Name_Last 15 + bill to name suffix Ecom_BillTo_Postal_Name_Suffix 4 ( 3) + bill to street line1 Ecom_BillTo_Postal_Street_Line1 20 ( 4) + bill to street line2 Ecom_BillTo_Postal_Street_Line2 20 ( 4) + bill to street line3 Ecom_BillTo_Postal_Street_Line3 20 ( 4) + bill to city Ecom_BillTo_Postal_City 22 + + + +Eastlake & Goldstein Informational [Page 7] + +RFC 2706 ECom Field Names October 1999 + + + bill to state/province Ecom_BillTo_Postal_StateProv 2 ( 5) + bill to zip/postal code Ecom_BillTo_Postal_PostalCode 14 ( 6) + bill to country Ecom_BillTo_Postal_CountryCode 2 ( 7) + bill to phone Ecom_BillTo_Telecom_Phone_Number 10 ( 8) + bill to email Ecom_BillTo_Online_Email 40 ( 9) + + receiptTo title Ecom_ReceiptTo_Postal_Name_Prefix 4 ( 1) + receiptTo first name Ecom_ReceiptTo_Postal_Name_First 15 + receiptTo middle name Ecom_ReceiptTo_Postal_Name_Middle 15 ( 2) + receiptTo last name Ecom_ReceiptTo_Postal_Name_Last 15 + receiptTo name suffix Ecom_ReceiptTo_Postal_Name_Suffix 4 ( 3) + receiptTo street line1 Ecom_ReceiptTo_Postal_Street_Line1 20 ( 4) + receiptTo street line2 Ecom_ReceiptTo_Postal_Street_Line2 20 ( 4) + receiptTo street line3 Ecom_ReceiptTo_Postal_Street_Line3 20 ( 4) + receiptTo city Ecom_ReceiptTo_Postal_City 22 + receiptTo state/province Ecom_ReceiptTo_Postal_StateProv 2 ( 5) + receiptTo postal code Ecom_ReceiptTo_Postal_PostalCode 14 ( 6) + receiptTo country Ecom_ReceiptTo_Postal_CountryCode 2 ( 7) + receiptTo phone Ecom_ReceiptTo_Telecom_Phone_Number 10 ( 8) + receiptTo email Ecom_ReceiptTo_Online_Email 40 ( 9) + + name on card Ecom_Payment_Card_Name 30 (10) + + card type Ecom_Payment_Card_Type 4 (11) + card number Ecom_Payment_Card_Number 19 (12) + card verification value Ecom_Payment_Card_Verification 4 (13) + + card expire date day Ecom_Payment_Card_ExpDate_Day 2 (14) + card expire date month Ecom_Payment_Card_ExpDate_Month 2 (15) + card expire date year Ecom_Payment_Card_ExpDate_Year 4 (16) + + card protocols Ecom_Payment_Card_Protocol 20 (17) + + consumer order ID Ecom_ConsumerOrderID 20 (18) + + schema version Ecom_SchemaVersion 30 (19) + + end transaction flag Ecom_TransactionComplete - (20) + + FIELD NAME Min Notes + + IMPORTANT NOTE: "MIN" in the table above is the MINIMUM DATA SIZE TO + ALLOW FOR ON DATA ENTRY. It is NOT the minimum size for valid + contents of the field and merchant software should, in most cases, be + prepared to receive a longer or shorter value. Merchant dealing with + areas where, for example, the state/province name or phone number is + + + + + +Eastlake & Goldstein Informational [Page 8] + +RFC 2706 ECom Field Names October 1999 + + + longer than the "Min" given below must obviously permit longer data + entry. In some cases, however, there is a maximum size that makes + sense and this is documented in a Note for the field. + +4. End Notes + + ( 1) For example: Mr., Mrs., Ms., Dr. This field is commonly not + used. + + ( 2) May also be used for middle initial + + ( 3) For example: Ph.D., Jr. (Junior), 3rd, Esq. (Esquire). This + field is commonly not used. + + ( 4) Address lines must be filled in the order line1, then line2, + last line3. + + ( 5) 2 characters are the minimum for the US and Canada, other + countries may require longer fields. For the US use 2 character + US Postal state abbreviation. + + ( 6) Minimum field lengths for Postal Code will vary based on + international market served. Use 5 character or 5+4 ZIP for the + US and 6 character postal code for Canada. The size given, 14, + is believed to be the maximum required anywhere in the world. + + ( 7) Use [ISO 3166] standard two letter codes + for + country names. + + ( 8) 10 digits are the minimum for numbers local to the North + American Numbering Plan (: US, Canada and + a number of smaller Caribbean and Pacific nations (but not + Cuba)), other countries may require longer fields. Telephone + numbers are complicated by differing international access codes, + variant punctuation of area/city codes within countries, + confusion caused by the fact that the international access code + in the NANP region is usually the same as the "country code" for + that area (1), etc. It will probably be necessary to use + heuristics or human examination based on the telephone number + and addresses given to figure out how to actually call a + customer. It is recommend that an "x" be placed before extension + numbers. + + ( 9) For example: jsmith@example.com + + (10) The name of the cardholder. + + + + +Eastlake & Goldstein Informational [Page 9] + +RFC 2706 ECom Field Names October 1999 + + + (11) Use the first 4 letters of the association name: American + Express=AMER; Diners Club=DINE; Discover=DISC; JCB=JCB; + Mastercard=MAST; Visa=VISA. + + (12) Includes the check digit at end but no spaces or hyphens [ISO + 7812]. The Min given, 19, is the longest number permitted under + the ISO standard. + + (13) An additional cardholder verification number printed on the card + (but not embossed or recorded on the magnetic stripe) such as + American Express' CIV, MasterCard's CVC2, and Visa's CVV2 + values. + + (14) The day of the month. Values: 1-31 + + (15) The month of the year. Jan - 1, Feb - 2, March - 3, etc.; + Values: 1-12 + + (16) The value in the wallet cell is always four digits, e.g., 1999, + 2000, 2001, ... + + (17) A space separated list of protocols available in connection with + the specified card. Initial list of case insensitive tokens: + none, set, & setcert. "Set" indicates usable with SET protocol + (i.e., is in a SET wallet) but does not have a SET certificate. + "Setcert" indicates same but does have a set certificate. + "None" indicates that automatic field fill is operating but + there is no SET wallet or the card is not entered in any SET + wallet. + + (18) A unique order ID generated by the consumer software. + + (19) URI indicating version of this set of fields. Usually a hidden + field. Equal to "http://www.ecml.org/version/1.0" for this + version. + + (20) A flag to indicate that this web-page/aggregate is the final one + for this transaction. Usually a hidden field. + +5. Security Considerations + + The information called for by many of these fields is sensitive and + should be protected if being sent over the public Internet or through + other channels where it can be observed. Mechanisms for such + protection are not specified herein but channel encryption such as + SSL/TLS [RFC 2246] or IPSec [RFC 2411] would be appropriate in many + cases. + + + + +Eastlake & Goldstein Informational [Page 10] + +RFC 2706 ECom Field Names October 1999 + + + User control over release of such information is needed to protect + the user's privacy. + + Any multi-web-page or other multi-aggregate field fill in or data + provision mechanism should check for the Ecom_TransactionComplete + field and cease automated fill when it is encountered until fill is + further authorized. + +References + + ISO 3166 - Codes for the representation of names of countries, + + + ISO 7812 - Identification card - Identification of issuers - Part 1: + Numbering system + + HTTP4.0 - HTML 4.0 Specification, + + RFC 2026 - Bradner, S., "The Internet Standards Process -- Revision + 3", BCP 9, RFC 2026, October 1996. + + RFC 2246 - Dierks, T. and C. Allen, "The TLS Protocol: Version 1.0", + RFC 2246, January 1999. + + RFC 2411 - Thayer, R., Doraswany, N. and R. Glenn, "IP Security: + Document Roadmap", RFC 2411, November 1998. + + IOTP - Internet Open Trading Protocol, being specified in the + IETF TRADE working group, D. Burdett + + SET - Secure Electronic Transaction, + + + XML - Extensible Markup Language (XML) 1.0, + , T. Bray, J. + Paoli, C. M. Sperberg-McQueen + + + + + + + + + + + + + + + +Eastlake & Goldstein Informational [Page 11] + +RFC 2706 ECom Field Names October 1999 + + +Authors' Addresses + + Donald E. Eastlake, 3rd + IBM, J1-N63 + 17 Skyline Drive + Hawthorne, NY 10532 USA + + Phone: +1-914-784-7913 + Fax: +1-914-784-3833 + EMail: dee3@us.ibm.com + + + Ted Goldstein + Brodia Networks, Inc. + 221 Main Street, Suite 1530 + San Francisco, CA 94105 USA + + Phone: +1 415-495-3100 x222 + Fax: +1 415-495-3177 + EMail: tgoldstein@brodia.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Eastlake & Goldstein Informational [Page 12] + +RFC 2706 ECom Field Names October 1999 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Eastlake & Goldstein Informational [Page 13] + -- cgit v1.2.3