RFC 3106
ECML v1.1: Field Specifications for E-Commerce
RFC 3106 📮 ECML v1.1: Field Specifications for E-Commerce 💖
Okay bestie, this one is a whole vibe. 🦋 It's RFC 3106, an Informational doc (so it's not an Internet standard, just useful info for the community 🫶), written by D. Eastlake of Motorola and T. Goldstein of Brodia. It was published in April 2001 and it obsoletes RFC 2706 (the ECML v1.0 spec) ✨. Yes, this is the glow-up edition of ECML.
Status of this Memo 🌸
This memo gives information to the Internet community. It does not specify an Internet standard of any kind, so it's more of a "here's what you should know" doc than a rulebook. Distribution is unlimited, so share it with everyone 💅.
Copyright Notice 🎀
The Internet Society holds the copyright (2001). All Rights Reserved. 🔒
IESG Note: 🌈
This document specifies version 1.1 of ECML and obsoletes RFC 2706, which specifies version 1.0. Both versions are products of the ECML Alliance (more on them in Section 1.1). Heads up, though: as of when this RFC got published, version 2.0 of ECML was still in development at the IETF in the TRADE Working Group 👀.
Abstract ✨
Okay so here's the tea. Customers often have to type a ton of info into an online merchant's site just to finish a purchase, especially the first time they visit 😭. The first version of an Electronic Commerce Modeling Language (ECML) defines a standard set of fields so that this can be automated, for example by wallet software that fills everything in for you 🧚. Even if you're typing it by hand, you'll be less confused by every site if lots of merchants use these same standard fields 💜. Some fields are also defined for merchant-to-consumer communication 🍓.
Acknowledgements 🫶
Huge thanks to these people, listed alphabetically, who contributed a lot to the material in this document:
George Burne
Joe Coco
Jon Parsons
James Salsman
David Shepherd
Kevin WellerTable of Contents 📑
1. Introduction.................................................. 2
1.1 The ECML Alliance............................................ 3
1.2 Relationship to Other Standards.............................. 4
1.3 Areas Deferred to Future Versions............................ 4
2. Field Definitions and DTD..................................... 4
2.1 Field List and Descriptions.................................. 4
2.1.1 Field List................................................. 5
2.1.2 Field Foot Notes........................................... 7
2.2 Use in HTML.................................................. 10
2.3 An ECML 1.1 XML DTD.......................................... 11
3. Using The Fields.............................................. 13
3.1 Presentation of the Fields................................... 13
3.2 Methods and Flow of Setting the Fields....................... 14
3.3 HTML Example................................................ 14
4. Security and Privacy Considerations........................... 16
References....................................................... 16
Appendix: Changes from ECML 1.0.................................. 18
Authors' Addresses............................................... 19
Full Copyright Statement......................................... 201. Introduction 🧚♀️
Okay so right now, tons of merchants are running businesses on the Internet using HTML forms 🛍️. The problem is that every merchant formats their forms differently, so end-users get super confused, and filling them in by hand is just tedious 😩. The result? Reportedly around two thirds of merchant forms get abandoned partway through the fill-in process. Rough 💀.
Electronic wallets are the glow-up that could fix this 👑. A digital wallet is an app or service that helps consumers with online transactions by storing their billing, shipping, payment, and preference info, then using it to auto-complete merchant interactions 💳. Checkout becomes way smoother, and you don't have to think about a merchant's form every single time 🙌. Wallets that fill in forms have already been built into browsers, proxy servers, helper apps for browsers, stand-alone apps, browser plug-ins, and server-based apps. But the wallet situation has been held back by a lack of standards 😤.
ECML (Electronic Commerce Modeling Language, <www.ecml.org>) gives web merchants a set of simple guidelines so that electronic wallets from different vendors can fill in their web forms 🎀. The big payoff is that more people will find online shopping easy and irresistible 🛒✨.
Version 1.1 is an upgrade over Version 1.0 [RFC 2706], and the appendix to this document covers what changed 📝. The big new thing is support for communication from the merchant to the wallet 💌. The wallet can use that info to show transaction details and maybe signed receipts 🧾. The format of those receipt signatures isn't specified in this document, so that's a different story 🤷♀️.
Multiple wallets and multiple merchants can work together with ECML, and it's an open standard 🌍. ECML is designed to be simple, and neither Version 1.0 nor Version 1.1 adds new technology to the web 🙅♀️. A merchant can adopt ECML and get support from multiple wallets by making very simple changes to their site 💅. And the best part: using ECML requires no license 🥳.
1.1 The ECML Alliance 🤝
The fields in this document were developed by the ECML Alliance (www.ecml.org). The Alliance includes, in alphabetical order, the fifteen Steering Committee members listed below, plus lots of General Members, some of whom are listed on the ECML website 🌟.
1. American Express (www.americanexpress.com>
2. AOL (www.aol.com)
3. Brodia (www.brodia.com)
4. Compaq (www.compaq.com)
5. CyberCash (www.cybercash.com)
6. Discover (www.discovercard.com)
7. FSTC (www.fstc.org)
8. IBM (www.ibm.com)
9. Mastercard (www.mastercard.com)
10. Microsoft (www.microsoft.com)
11. Novell (www.novell.com>
12. SETCo (www.setco.org)
13. Sun Microsystems (www.sun.com)
14. Trintech (www.trintech.com>
15. Visa International (www.visa.com)1.2 Relationship to Other Standards 🧩
The ECML fields were first derived from the W3C P3P base data schema, and they're consistent with it, found at:
<http://www.w3.org/TR/WD-P3P/basedata.html>ECML Version 1.1 is not a replacement for or alternative to SSL/TLS [RFC 2246], SET [SET], XML [XML], or IOTP [RFC 2801] 🙅♀️. Those are important standards with main-character energy, offering things like non-repudiatable transactions, automatable payment scheme selection, and smart card support 💪.
ECML can be used with any payment mechanism 💳. It just lets a merchant publish consistent, simple web forms 📋. Info on using the ECML fields with the W3C P3P protocol is at the link below, and it also includes some proposed extension fields 🔗. Those extension fields may be included in a future version of ECML 🔮.
<http://www.w3.org/TR/P3P-for-ecommerce>1.3 Areas Deferred to Future Versions ⏭️
Some topics got pushed to future versions, because they're a lot to handle right now 😅. These include business purchasing cards, non-card payment mechanisms, wallet activation, privacy-related mechanisms, additional payment mechanisms, currency exchange, and any sort of "negotiation" 🫠. Hidden or other special fields were kept to a minimum too 🤫.
2. Field Definitions and DTD 📚
The ECML Standard is basically all about defining and naming fields 🏷️. Those fields can be encoded in a bunch of different syntaxes and protocols 🌈.
Section 2.1 lists and describes the fields, Section 2.2 gives extra notes on using them in HTML, and Section 2.3 provides an XML DTD for use with the fields 💖.
2.1 Field List and Descriptions 📝
Here are the fields, along with the minimum data entry size each one should allow 📏. Heads up: these fields are organized hierarchically, marked by the embedded underscore ("_") characters 🧸. Data transmission mechanisms can use this structure to request and send aggregates. For example, Ecom_Payment_Card_ExpDate covers all of the date components, and Ecom_ShipTo covers all of the ship-to components the consumer is willing to provide 🚚. How the components of these aggregates get labeled, marshalled, and unmarshalled depends on the data transfer protocol being used 🔧.
(Part 1 of 4. More coming, bestie, so stay tuned! 🦋💅)
2.1.1 Field List ✨
IMPORTANT NOTE: okay bestie, read this first 🫶 The "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, so merchant software should, in most cases, be ready to receive a longer or shorter value 💅
Merchants 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 though, there's a maximum size that makes sense, and when that happens it gets documented in a Note for the field 📝
These fields are used to communicate from the customer to the merchant 🛍️
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 company name Ecom_ShipTo_Postal_Company 20
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 company name Ecom_BillTo_Postal_Company 20
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
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)
receipt to (32)
receipt to title Ecom_ReceiptTo_Postal_Name_Prefix 4 ( 1)
receipt to first name Ecom_ReceiptTo_Postal_Name_First 15
receipt to middle name Ecom_ReceiptTo_Postal_Name_Middle 15 ( 2)
receipt to last name Ecom_ReceiptTo_Postal_Name_Last 15
receipt to name suffix Ecom_ReceiptTo_Postal_Name_Suffix 4 ( 3)
receipt to company name Ecom_ReceiptTo_Postal_Company 20
receipt to street line1 Ecom_ReceiptTo_Postal_Street_Line1 20 ( 4)
receipt to street line2 Ecom_ReceiptTo_Postal_Street_Line2 20 ( 4)
receipt to street line3 Ecom_ReceiptTo_Postal_Street_Line3 20 ( 4)
receipt to city Ecom_ReceiptTo_Postal_City 22
receipt to state/province Ecom_ReceiptTo_Postal_StateProv 2 ( 5)
receipt to postal code Ecom_ReceiptTo_Postal_PostalCode 14 ( 6)
receipt to country Ecom_ReceiptTo_Postal_CountryCode 2 ( 7)
receipt to phone Ecom_ReceiptTo_Telecom_Phone_Number 10 ( 8)
receipt to 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)
user ID Ecom_User_ID 40 (19)
user password Ecom_User_Password 20 (19)
schema version Ecom_SchemaVersion 30 (20)
wallet id Ecom_WalletID 40 (21)
end transaction flag Ecom_TransactionComplete - (22)And these fields go the other way, from the merchant to the consumer 📬
FIELD NAME Min Notes
merchant home domain Ecom_Merchant 128 (23)
processor home domain Ecom_Processor 128 (24)
transaction identifier Ecom_Transaction_ID 128 (25)
transaction URL inquiry Ecom_Transaction_Inquiry 500 (26)
transaction amount Ecom_Transaction_Amount 128 (27)
transaction currency Ecom_Transaction_CurrencyCode 3 (28)
transaction date Ecom_Transaction_Date 80 (29)
transaction type Ecom_Transaction_Type 40 (30)
transaction signature Ecom_Transaction_Signature 160 (31)
end transaction flag Ecom_TransactionComplete - (22)
FIELD NAME Min NotesIMPORTANT NOTE: same deal as before, the "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, so merchant software should, in most cases, be ready to receive a longer or shorter value 🌸
Merchants 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 💜 Sometimes there's a maximum size that makes sense, and when there is, it's documented in a Note for the field ✨
2.1.2 Field Foot Notes
okay so the foot notes are where the juicy details live 🫶 here's the tea:
( 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) bestie pls remember the address lines get filled in order: line1, then line2, and last line3 📦
( 5) 2 characters are the minimum for the US and Canada, but other countries may need longer fields 🌍 for the US, use the 2 character US Postal state abbreviation 🦋
( 6) the minimum field lengths for Postal Code depend on which international market you're serving 🌸 use 5 characters or 5+4 ZIP for the US, and 6 characters for a Canadian postal code. the size given, 14, is believed to be the maximum needed anywhere in the world 🌈
( 7) use the [ISO 3166] standard two letter codes 🗺️ for country names, see http://www.din.de/gremien/nas/nabd/iso3166ma/index.html 💜
( 8) 10 digits are the minimum for numbers local to the North American Numbering Plan (http://www.nanpa.com: US, Canada, and a bunch of smaller Caribbean and Pacific nations, but not Cuba) 📞 other countries may need longer fields. phone numbers are lowkey chaotic bc of differing international access codes, variant punctuation of area/city codes within countries, and 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 👑
(11) use the first 4 letters of the association name 💳
AMER American Express
BANK Bankcard (Australia)
DC DC (Japan)
DINE Diners Club
DISC Discover
JCB JCB
MAST Mastercard
NIKO Nikos (Japan)
SAIS Saison (Japan)
UC UC (Japan)
UCAR UCard (Taiwan)
VISA Visa(12) includes the check digit at the 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. a leading zero is ignored, so for example, 07 is valid for the seventh day of the month 📅
(15) the month of the year. Jan - 1, Feb - 2, March - 3, etc.; values: 1-12. a leading zero is ignored, so for example, 07 is valid for July 🌞
(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 🦄 the initial list of case insensitive tokens is:
none
set
setcert
iotp
echeck
simcard
phoneid"Set" indicates usable with SET protocol (i.e., is in a SET wallet) but does not have a SET certificate. "Setcert" indicates the same, but does have a set certificate. "iotp" indicates the IOTP protocol [RFC 2801] is supported at the customer. "echeck" indicates that the eCheck protocol [eCheck] is supported at the customer. "simcard" indicates use the transaction instrument built into a Cellphone subscriber for identification. "phoneid" indicates use the transaction instrument of a phone bill instrument. "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) the user ID and password fields are used in cases where the user has a pre-established account with the merchant 🔑
(20) URI indicating the version of this set of fields. usually a hidden field. equal to http://www.ecml.org/version/1.1 for this version 🏷️
(21) a string to identify the source and version of the form fill software that is acting on behalf of the user. should contain company and/or product name and version. example: Wallets Inc., SuperFill, v42.7 usually a hidden field 🛠️
(22) a flag to indicate that this web-page/aggregate is the final one for this transaction. usually a hidden field 🏁
(23) merchant domain name, such as www.merchant.example. this is usually a hidden field 🏪
(24) gateway transaction processor who is actually accepting the payment on behalf of the merchant in the home domain, such as www.processor.example. this is usually a hidden field 🏦
(25) a transaction identification string whose format is specific to the processor. this is usually a hidden field 🆔
(26) a URL that can be invoked to inquire about the transaction. this is usually a hidden field 🔍
(27) the amount of the transaction in ISO currency format. this is two integer numbers with a period in between, but no other currency marks (such as a $ dollar sign). this is usually a hidden field 💸
(28) this is the three letter ISO currency code. for example, for US dollars it is USD. this is usually a hidden field 💵
(29) ISO Transaction date. this is usually a hidden field 🗓️
(30) the type of the transaction (either debit or credit) if known. this is usually a hidden field 🪙
(31) the signature of the encoded certificate. this is usually a hidden field ✍️
(32) the Receipt To fields are used when the Bill To entity, location, or address and the Receipt To entity, location, or address are different 🧾 for example, when using some forms of Corporate Purchasing Cards or Agent Purchasing Cards, the individual card holder would be in the Receipt To fields and the corporate or other owner would be in the Bill To fields. main character energy for the payer 👑
2.2 Use in HTML
the normal use of ECML in HTML is as a form, with input field names identical to the ones in section 2.1 above 🌸 generally, <INPUT> tags with type text, hidden, and password must be supported, and so must <SELECT> tags 🎀
internationalization in HTML is kinda limited ngl 🙈 the information available with the HTML form Method as to character set and language SHOULD be used 💜
2.3 An ECML 1.1 XML DTD
okay this part is giving schema 🤓 below is an XML DTD that can be used for the XML encoding of ECML v1.1 Fields 🧚
for internationalization of [XML] ECML, use the general XML character encoding provisions. those mandate support of UTF-8 and UTF-16 and permit support of other character sets, and the xml:lang attribute may be used to specify language information 🌈
<!-- Electronic Commerce Modeling Language 1.1 -->
<!ELEMENT Ecom ( #PCDATA | ShipTo | BillTo | ReceiptTo | Payment |
User | Transaction | TransactionComplete )* >
<!ATTLIST Ecom
id ID #IMPLIED
ConsumerOrderID CDATA #IMPLIED
Merchant CDATA #IMPLIED
Processor CDATA #IMPLIED
SchemaVersion ( "http://www.ecml.org/version/1.0" |
"http://www.ecml.org/version/1.1" )
#IMPLIED
WalletID CDATA #IMPLIED >
<!ELEMENT ShipTo ( #PCDATA | Postal | Telecom | Online )* >
<!ATTLIST ShipTo
id ID #IMPLIED >
<!ELEMENT BillTo ( #PCDATA | Postal | Telecom | Online )* >
<!ATTLIST BillTo
id ID #IMPLIED >
<!ELEMENT ReceiptTo ( #PCDATA | Postal | Telecom | Online )* >
<!ATTLIST ReceiptTo
id ID #IMPLIED >
<!ELEMENT Postal ( #PCDATA | Name | Company |
Street | City | StateProv )* >
<!ATTLIST Postal
id ID #IMPLIED
PostalCode NMTOKEN #IMPLIED
CountryCode NMTOKEN #IMPLIED >
<!ELEMENT Name EMPTY >
<!ATTLIST Name
id ID #IMPLIED
Prefix NMTOKEN #IMPLIED
First NMTOKEN #IMPLIED
Middle NMTOKEN #IMPLIED
Last NMTOKEN #IMPLIED
Suffix NMTOKEN #IMPLIED >
<!ELEMENT Street EMPTY >
<!ATTLIST Street
id ID #IMPLIED
Line1 CDATA #REQUIRED
Line2 CDATA #IMPLIED
Line3 CDATA #IMPLIED >
<!ELEMENT Company #PCDATA >
<!ELEMENT City #PCDATA >
<!ELEMENT StateProv #PCDATA >
<!ELEMENT Telecom ( #PCDATA | Phone )* >
<!ELEMENT Phone EMPTY >
<!ATTLIST Phone
id ID #IMPLIED
Number CDATA #REQUIRED >
<!ELEMENT Online ( #PCDATA | Email )* >
<!ELEMENT Email EMPTY >
<!ATTLIST Email
id ID #IMPLIED
Address CDATA #REQUIRED >
<!ELEMENT Payment Card>
<!ELEMENT Card ExpDate >
<!ATTLIST Card
id ID #IMPLIED
Name CDATA #IMPLIED
Type NMTOKEN #IMPLIED
Number NMTOKEN #REQUIRED
Protocols NMTOKENS #IMPLIED
Verification NMTOKEN #IMPLIED >
<!ELEMENT ExpDate EMPTY >
<!ATTLIST ExpDate
id ID #IMPLIED
Day NMTOKEN #IMPLIED
Month NMTOKEN #REQUIRED
Year NMTOKEN #REQUIRED >
<!ELEMENT User ( #PCDATA | UserID | Password )* >
<!ATTLIST User
id ID #IMPLIED >
<!ELEMENT UserID #PCDATA >
<!ELEMENT Password #PCDATA >
<!ELEMENT Transaction ( #PCDATA | TransactionID | Inquiry |
TransDate | Signature )* >
<!ATTLIST Transaction
id ID #IMPLIED
Amount CDATA #IMPLIED
Currency NMTOKEN #IMPLIED
Type NMTOKEN #IMPLIED >
<!ELEMENT TransactionComplete EMPTY>3. Using The Fields
time to get practical 💅 to conform to this document, the field names must be structured and named as close to the structure and naming listed in Section 2 above as the transaction protocol in use permits 🎀 note: this does not put any restriction on the user visible labeling of fields, just on their names as used in communication ✨
3.1 Presentation of the Fields
there's no necessary implication as to the order or manner of presentation 🦋 some merchants may wish to ask for more information, and some less by omitting fields. some merchants may ask for the info they want in one interaction or web page, while others may ask for parts of it at different times, in multiple interactions or different web 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 others make much information optional. etc. 🫠
there is no way with Version 1.0 or 1.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 a field it requires is not completed, just as it may if a field is completed in a manner it considers erroneous 🚨
it is entirely up to the merchant when, and which, if any, of the merchant to consumer fields it presents 👑
3.2. Methods and Flow of Setting the Fields ✨
okay so there are a bunch of ways the customer and the merchant can chat about which fields the merchant wants filled in 💅. The easiest one for software that's already out there is putting them as fields in an [HTML] form (see section 2.2) 🎀. Other options are the IOTP Authenticate transaction [RFC 2801], an [XML] exchange, or proprietary protocols 🧚.
A user action or the appearance of the Ecom_SchemaVersion field can be the trigger that gets a facility going to fill in fields 🦋. Some wallets need the user to activate them, so there should be at least one user visible Ecom field on every page that has any Ecom fields to be filled in 🌸. It is also REQUIRED that the Ecom_SchemaVersion field, which is usually hidden, be included on every web page that has any Ecom fields 🔥.
Web pages can load super slowly, so an automated field fill-in function might not be able to tell when it's done filling in fields on a page 😭. That's why it is recommended that the Ecom_SchemaVersion field be the last Ecom field on a web page 💜.
The merchant might ask for info across several interactions or web pages. Without some extra rules, a facility could either have to restart on every page, or it could keep filling in fields on pages past the end of the transaction with that merchant, which could violate or look like it violates privacy 🙈. So there's the Ecom_TransactionComplete field, which is normally hidden ✨. It's recommended to put it on the last interaction or web page in a transaction, right before an Ecom_SchemaVersion field, so a multi-web-page automated fill-in logic can know when to stop if it chooses to check for this field 🫶.
3.3. HTML Example
Here's an example HTML form 💖:
<HTML>
<HEAD>
<title> eCom Fields Example </title>
</HEAD>
<BODY>
<FORM action="http://ecom.example.com" method="POST">
Please enter card information:
<p>Your name on the card
<INPUT type="text" name="Ecom_Payment_Card_Name" SIZE=40>
<br>The card number
<INPUT type="text" name="Ecom_Payment_Card_Number" SIZE=19>
<br>Expiration date (MM YY)
<INPUT type="text" name="Ecom_Payment_Card_ExpDate_Month" SIZE=2>
<INPUT type="text" name="Ecom_Payment_Card_ExpDate_Year" SIZE=4>
<INPUT type="hidden" name="Ecom_Payment_Card_Protocol">
<INPUT type="hidden" name="Ecom_SchemaVersion"
value="http://www.ecml.org/version/1.1">
<br>
<INPUT type="submit" value="submit"> <INPUT type="reset">
</FORM>
</BODY>
</HTML>Once all the pages are submitted, the merchant sends back a confirmation page 🎉. That page tells both the user and the wallet that the transaction is complete 🌈.
<HTML>
<HEAD>
<title> eCom Transaction Complete Example </title>
</HEAD>
<BODY>
<FORM>
Thank you for your order. It will be shipped in several days.
<INPUT type="hidden" name="Ecom_Merchant" value="www.merchant.example">
<INPUT type="hidden" name ="Ecom_Processor"
value="www.processor.example">
<INPUT type="hidden" name="Ecom_Transaction_ID" value="EF123456">
<INPUT type="hidden" name="Ecom_Transaction_Inquiry"
value="http://www.merchant.example/cgi-bin/inquire?ID=EF123456">
<INPUT type="hidden" name="Ecom_Transaction_Amount" value="789.00">
<INPUT type="hidden" name="Ecom_Transaction_Currency" value="USD">
<INPUT type="hidden" name="Ecom_Transaction_Date" value="July 14 2000">
<INPUT type="hidden" name="Ecom_Transaction_Type" value="credit">
<INPUT type="hidden" name="Ecom_Transaction_Signature"
value="ig6rh4;;20dfna00s34hj10s--s-45j30-22z92l-frwds-85">
<INPUT type="hidden" name="Ecom_TransactionComplete">
<INPUT type="hidden" name="Ecom_SchemaVersion"
value="http://www.ecml.org/version/1.1">
</FORM>
</BODY>
</HTML>4. Security and Privacy Considerations 🔐
Heads up, this part is seriously important 😭. Lots of these fields carry sensitive info, so it should be secured when it's sent over the public Internet or through any other channel where someone could observe it 👀.
The protection itself isn't specified in this document 💅. Channel encryption like TLS/SSL [RFC 2246] or IPSec [RFC 2411] would be a good fit in many cases ✨.
User control over whether this info gets released is needed to protect the user's privacy 🛡️💖.
A wallet installed on a shared or public terminal should be configurable so the ECML memory of address and other contact info is fully disabled 🏫. This is vital for protecting the privacy of library patrons, students, customers on public terminals, and kids who might use a form on a public terminal without realizing their info is being stored 🧒🌸.
When contact info is stored, the operator should get the option to protect it with a password 🔑. Without the password, the info might be unavailable even to someone who can access the file(s) it's stored in 🔒. This also gives a convenient way for multiple people to use their own ECML info from the same browser 👯♀️.
Any multi-web-page or other multi-aggregate field fill-in or data provision mechanism should check for the Ecom_TransactionComplete field and stop automated fill when it shows up, until fill is further authorized 🛑💅.
References 📚
[eCheck] <http://www.echeck.org>
[HTML] HTML 3.2 Reference Specification
<http://www.w3.org/TR/REC-html32.html>, D. Raggett,
January 1997.
[IANA] Internet Assigned Numbers Authority, Official Names for
Character Sets, ed. Keld Simonsen et al.
<ftp://ftp.isi.edu/in-notes/iana/assignments/character-
sets>.
[ISO 3166] Codes for the representation of names of countries,
<http://www.din.de/gremien/nas/nabd/iso3166ma>
[ISO 7812] "Identification card - Identification of issuers - Part 1:
Numbering system".
[RFC 1766] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001.
[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.
[RFC 2706] Eastlake, D. and T. Goldstein, "ECML v1: Field Names for
E-Commerce", RFC 2706, September 1999.
[RFC 2801] Burdett, D., "Internet Open Trading Protocol - IOTP
Version 1.0", RFC 2801, April 2000.
[SET] Secure Electronic Transaction,
<http://www.setco.org/set_specifications.html>
[XML] Extensible Markup Language (XML) 1.0 (Second Edition),
<http://www.w3.org/TR/REC-xml>, T. Bray, J. Paoli, C. M.
Sperberg-McQueen, E. Maler.Appendix: Changes from ECML 1.0 🦋
ECML 1.0 is documented in [RFC 2706] 📖.
(1) Fields were added for consumer to merchant transmission, listed below ✨. A * indicates multiple values 💅. Adding fields is a backward compatible change 🎀.
Ecom_*_Postal_Company
Ecom_User_ID
Ecom_User_Password
Ecom_WalletID(2) The Ecom_SchemaVersion field value changed to "http://www.ecml.org/version/1.1" 🔄.
(3) An XML DTD was added 🧾.
(4) "iotp", "echeck", "simcard", and "phoneid" were added as allowed tokens in Ecom_Payment_Card_Protocol 💳.
(5) A leading zero is now permitted in day and month number fields 📅.
(6) "Security Considerations" became "Security and Privacy Considerations", with more material added 🔐.
(7) Internationalization material was added to the HTML and XML subsections of Section 2 🌍.
(8) HTML form elements that must be supported are now enumerated (Section 2.2), including SELECT 📝.
(9) More credit card brand codes were added 💖.
(10) Fields for merchant to consumer transmissions were added, as follows 💌:
Ecom_Merchant
Ecom_Processor
Ecom_Transaction_*Authors' Addresses 🧑💻
Donald E. Eastlake, 3rd
Motorola, M2-450
20 Cabot Boulevard
Mansfield, MA 02048
Phone: +1-508-261-5434
Fax: +1-508-261-4447
EMail: Donald.Eastlake@motorola.com
Ted Goldstein
Brodia
221 Main Street, Suite 1530
San Francisco, CA 94105 USA
Phone: +1 415-495-3100 x222
Fax: +1 415-495-3177
EMail: tgoldstein@brodia.comFull Copyright Statement ⚖️
Copyright (C) The Internet Society (2001). 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 💜.
📦 where this page comes from
- ietf: rfc3106 2001-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms