idnits 2.17.1 draft-ietf-trade-ecml2-spec-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1566. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1558), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? == 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 a Security Considerations section. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** 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 182: '... MUST be allowed for on data entry. ...' RFC 2119 keyword, line 1261: '...e data content. Such content SHOULD be...' RFC 2119 keyword, line 1282: '... is REQUIRED that the Ecom_SchemaVer...' RFC 2119 keyword, line 1284: '... SHOULD appear on every web page tha...' RFC 2119 keyword, line 1291: '...ctivation, it is RECOMMENDED that thes...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2004) is 7104 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'IANA' is defined on line 1438, but no explicit reference was found in the text == Unused Reference: 'RFC 1766' is defined on line 1458, but no explicit reference was found in the text == Unused Reference: 'EMV' is defined on line 1479, but no explicit reference was found in the text == Unused Reference: 'RFC 2026' is defined on line 1496, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO 3166' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO 4217' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO 5218' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO 7812' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO 8583' ** Obsolete normative reference: RFC 1766 (Obsoleted by RFC 3066, RFC 3282) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 3066 (Obsoleted by RFC 4646, RFC 4647) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2411 (Obsoleted by RFC 6071) -- Obsolete informational reference (is this intentional?): RFC 2706 (Obsoleted by RFC 3106) -- Obsolete informational reference (is this intentional?): RFC 3852 (Obsoleted by RFC 5652) Summary: 17 errors (**), 0 flaws (~~), 6 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Donald E. Eastlake 3rd 3 Motorola Laboratories 4 Expires April 2005 October 2004 6 Electronic Commerce Modeling Language (ECML): 7 Version 2 Specification 8 10 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 or will be disclosed, and any of which I become aware will be 14 disclosed, in accordance with RFC 3668. 16 Distribution of this document is unlimited. Comments should be sent 17 to the author or the IETF TRADE working group . 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than a "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Copyright (C) The Internet Society 2004. All Rights Reserved. 38 Abstract 40 Electronic commerce frequently requires a substantial exchange of 41 information in order to complete a purchase or other transaction, 42 especially the first time the parties communicate. A standard set of 43 hierarchically organized payment related information field names in 44 an XML syntax are defined so that this task can be more easily 45 automated. This is the second version of an Electronic Commerce 46 Modeling Language (ECML) and is intended to meet the requirements of 47 RFC 3505. 49 Acknowledgements 51 The following, listed is alphabetic order, have contributed to the 52 material herein: 53 Ray Bellis, Steve Bellovin, Scott Hollenbeck, Russ Housley, Jon 54 Parsons, Lauri Piikivi, David Shepherd, and James J. Peter. 56 Table of Contents 58 Status of this Memo........................................1 59 Abstract...................................................1 60 Acknowledgements...........................................2 61 Table of Contents..........................................2 63 1. Introduction............................................3 64 1.2 History and Relationship to Other Standards............3 66 2. Field Definitions, DTD, and Schema......................4 67 2.1 Field List and Descriptions............................4 68 2.1.1 The Field List.......................................4 69 2.1.2 Field Foot Notes.....................................8 71 2.2 Exemplar XML Syntax...................................13 72 2.2.1 ECML v2 XML DTD.....................................13 74 2.2.2 ECML v2 XML Schema..................................19 76 3. Usage Notes for ECML v2................................27 77 3.1 Presentation of the Fields............................27 78 3.2 Methods and Flow of Setting the Fields................27 79 4. Security and Privacy Considerations....................28 80 5. IANA Considerations....................................29 81 5.1 ECML v2 Schema Template...............................29 82 5.2 ECML v2 URN Template..................................30 83 5.2.1 Subregistration of v2.0.............................30 84 5.3 IANA Registries.......................................30 86 Normative References......................................32 87 Informative References....................................33 89 Appendix: Changes from v1.1 to v2.........................35 91 Copyright and Disclaimer..................................36 92 Authors Addresses.........................................36 93 File name and Expiration..................................36 95 1. Introduction 97 Numerous parties are conducting business on the Internet using ad hoc 98 fields and forms. The data formats and structure can vary 99 considerably from one party to another. Where forms are filled out 100 manually, some users find the diversity confusing and the process of 101 manually filling in these forms can be tedious and error prone. 103 Software tools, including electronic wallets, can help this 104 situation. Such tools can assist in conducting online transactions 105 by storing billing, shipping, payment, preference, and similar 106 information and using this information to automatically complete the 107 data sets required by interactions. For example, software that fills 108 out forms has been successfully built into browsers, as proxy 109 servers, as helper applications to browsers, as stand-alone 110 applications, as browser plug-ins, and as server-based applications. 111 But the proliferation of more automated transactions software has 112 been hampered by the lack of standards. 114 ECML (Electronic Commerce Modeling Language) provides a set of 115 hierarchical payment oriented data structures that will enable 116 automated software, including electronic wallets from multiple 117 vendors, to supply and query for needed data in a more uniform 118 manner. 120 Version 2.0 extends ECML Version 1.0 [RFC 2706] and 1.1 [RFC 3106] as 121 described in the Appendix to this document. These enhancements 122 include support for additional payment mechanisms and transaction 123 information and use of XML as the exemplar syntax. 125 ECML is designed to provide a simple baseline useful in a variety of 126 contexts. Likely uses for ECML v2 are consumer payment information 127 input and business-to-business transactions. At this time, the first 128 is still likely to occur through HTML forms. The second is more 129 likely to use XML documents. 131 1.2 History and Relationship to Other Standards 133 The ECML fields were initially derived from the W3C P3P base data 134 schema [P3P BASE] by the ECML Alliance as described in [RFC 2706, 135 3106]. Technical development and change control of ECML was then 136 transferred to the IETF. In version 2, ECML is extended by the fields 137 in a W3C P3P Note related to eCommerce [P3P ECOM], by [ISO 8583], and 138 other sources. Its primary exemplar form is now an XML syntax. 140 2. Field Definitions, DTD, and Schema 142 ECML v2 is the definition and naming of a hierarchically structured 143 set of fields and the provision of an optional XML syntax for their 144 transmission. These fields can be encoded in other syntaxes. 145 Regardless of the encoding used, they can be transmitted via a 146 variety of protocols. 148 Section 2.1 below lists and describes the fields, Section 2.2.1 149 provides an XML DTD for use with the fields, and Section 2.2.2 150 provides an XML schema. 152 To conform to this document, field names must be named and 153 hierarchically structured as closely to the structure and naming 154 listed below as practical given the syntax and transaction protocol 155 in use. (NOTE: this does not impose any restriction on human visible 156 labeling of fields, just on their name or names and structure as used 157 in on-the-wire communication.) 159 2.1 Field List and Descriptions 161 The fields are listed below. along with the minimum data entry size 162 to allow. Implementations may accept larger data sizes, where that 163 makes sense, and, for some applications, will need to allow for 164 larger data sizes. 166 Note that these fields are hierarchically organized as indicated in 167 this table by the embedded underscore ("_") characters. Appropriate 168 data transmission mechanisms may use this to request and send 169 aggregates, such as Ecom_Payment_Card_ExpDate to encompass all of a 170 set of card expiry date components or Ecom_ShipTo to encompass all 171 the ship to address components that a consumer is willing to provide. 172 The labeling, marshalling, unmarshalling of the components of such 173 aggregates depends on the data transfer protocol used. The suggested 174 syntax is XML as specified in section 2.2. 176 2.1.1 The Field List 178 The table below is the ECML v2 field list. 180 The NAME column gives the structured string name of each field as 181 explained above. The MIN column below is the minimum data size that 182 MUST be allowed for on data entry. It is NOT the minimum size for 183 valid contents of the field and merchant software should, in many 184 cases, be prepared to receive a longer or shorter value. Merchant 185 dealing with areas where, for example, the state/province name or 186 phone number is longer than the MIN given below must obviously permit 187 longer data entry. In some cases, however, there is a maximum size 188 that makes sense and where this is the case, it is usually documented 189 in a Note for the field. 191 The following fields are typically used to communicate from the 192 customer to the merchant: 194 FIELD NAME MIN Notes 196 ship to title Ecom_ShipTo_Postal_Name_Prefix 4 ( 1) 197 ship to first name Ecom_ShipTo_Postal_Name_First 15 (54) 198 ship to middle name Ecom_ShipTo_Postal_Name_Middle 15 ( 2) 199 ship to last name Ecom_ShipTo_Postal_Name_Last 15 (54) 200 ship to name suffix Ecom_ShipTo_Postal_Name_Suffix 4 ( 3) 201 ship to company name Ecom_ShipTo_Postal_Company 20 202 ship to street line1 Ecom_ShipTo_Postal_Street_Line1 20 ( 4) 203 ship to street line2 Ecom_ShipTo_Postal_Street_Line2 20 ( 4) 204 ship to street line3 Ecom_ShipTo_Postal_Street_Line3 20 ( 4) 205 ship to city Ecom_ShipTo_Postal_City 22 206 ship to state/province Ecom_ShipTo_Postal_StateProv 2 ( 5) 207 ship to zip/postal code Ecom_ShipTo_Postal_PostalCode 14 ( 6) 208 ship to country Ecom_ShipTo_Postal_CountryCode 2 ( 7) 209 ship to phone Ecom_ShipTo_Telecom_Phone_Number 10 ( 8) 210 ship to email Ecom_ShipTo_Online_Email 40 ( 9) 212 bill to title Ecom_BillTo_Postal_Name_Prefix 4 ( 1) 213 bill to first name Ecom_BillTo_Postal_Name_First 15 (54) 214 bill to middle name Ecom_BillTo_Postal_Name_Middle 15 ( 2) 215 bill to last name Ecom_BillTo_Postal_Name_Last 15 (54) 216 bill to name suffix Ecom_BillTo_Postal_Name_Suffix 4 ( 3) 217 bill to company name Ecom_BillTo_Postal_Company 20 218 bill to street line1 Ecom_BillTo_Postal_Street_Line1 20 ( 4) 219 bill to street line2 Ecom_BillTo_Postal_Street_Line2 20 ( 4) 220 bill to street line3 Ecom_BillTo_Postal_Street_Line3 20 ( 4) 221 bill to city Ecom_BillTo_Postal_City 22 222 bill to state/province Ecom_BillTo_Postal_StateProv 2 ( 5) 223 bill to zip/postal code Ecom_BillTo_Postal_PostalCode 14 ( 6) 224 bill to country Ecom_BillTo_Postal_CountryCode 2 ( 7) 225 bill to phone Ecom_BillTo_Telecom_Phone_Number 10 ( 8) 226 bill to email Ecom_BillTo_Online_Email 40 ( 9) 228 receipt to (32) 229 receipt to title Ecom_ReceiptTo_Postal_Name_Prefix 4 ( 1) 230 receipt to first name Ecom_ReceiptTo_Postal_Name_First 15 (54) 231 receipt to middle name Ecom_ReceiptTo_Postal_Name_Middle 15 ( 2) 232 receipt to last name Ecom_ReceiptTo_Postal_Name_Last 15 (54) 233 receipt to name suffix Ecom_ReceiptTo_Postal_Name_Suffix 4 ( 3) 234 receipt to company name Ecom_ReceiptTo_Postal_Company 20 235 receipt to street line1 Ecom_ReceiptTo_Postal_Street_Line1 20 ( 4) 236 receipt to street line2 Ecom_ReceiptTo_Postal_Street_Line2 20 ( 4) 237 receipt to street line3 Ecom_ReceiptTo_Postal_Street_Line3 20 ( 4) 238 receipt to city Ecom_ReceiptTo_Postal_City 22 239 receipt to state/province Ecom_ReceiptTo_Postal_StateProv 2 ( 5) 240 receipt to postal code Ecom_ReceiptTo_Postal_PostalCode 14 ( 6) 241 receipt to country Ecom_ReceiptTo_Postal_CountryCode 2 ( 7) 242 receipt to phone Ecom_ReceiptTo_Telecom_Phone_Number 10 ( 8) 243 receipt to email Ecom_ReceiptTo_Online_Email 40 ( 9) 245 name on card Ecom_Payment_Card_Name 30 (10) 247 card type Ecom_Payment_Card_Type 4 (11) 248 card number Ecom_Payment_Card_Number 19 (12) 249 card verification value Ecom_Payment_Card_Verification 4 (13) 250 card issuer number Ecom_Payment_Card_IssueNumber 2 (53) 252 card expire date day Ecom_Payment_Card_ExpDate_Day 2 (14) 253 card expire date month Ecom_Payment_Card_ExpDate_Month 2 (15) 254 card expire date year Ecom_Payment_Card_ExpDate_Year 4 (16) 255 card valid date day Ecom_Payment_Card_ValidFrom_Day 2 (14) 256 card valid date month Ecom_Payment_Card_ValidFrom_Month 2 (15) 257 card valid date year Ecom_Payment_Card_ValidFrom_Year 4 (16) 259 card protocols Ecom_Payment_Card_Protocol 20 (17) 261 loyalty card name Ecom_Loyalty_Card_Name 30 (10) 262 loyalty card type Ecom_Loyalty_Card_Type 20 (52) 263 loyalty card number Ecom_Loyalty_Card_Number 40 (34) 264 loyalty card verification Ecom_Loyalty_Card_Verification 4 (13) 265 loyalty card expire day Ecom_Loyalty_Card_ExpDate_Day 2 (14) 266 loyalty card expire month Ecom_Loyalty_Card_ExpDate_Month 2 (15) 267 loyalty card expire year Ecom_Loyalty_Card_ExpDate_Year 2 (16) 268 loyalty card valid day Ecom_Loyalty_Card_ValidFrom_Day 2 (14) 269 loyalty card valid month Ecom_Loyalty_Card_ValidFrom_Month 2 (15) 270 loyalty card valid year Ecom_Loyalty_Card_ValidFrom_Year 4 (16) 272 consumer order ID Ecom_ConsumerOrderID 20 (18) 274 user ID Ecom_User_ID 40 (19) 275 user password Ecom_User_Password 20 (19) 276 user certificate Ecom_User_Certificate_URL 128 (55) 277 user data country Ecom_UserData_Country 2 ( 7) 278 user data language Ecom_UserData_Language 30 (33) 279 user data gender Ecom_UserData_Gender 1 (36) 280 user data birth day Ecom_UserData_BirthDate_Day 2 (14) 281 user data birth month Ecom_UserData_BirthDate_Month 2 (15) 282 user data birth year Ecom_UserData_BirthDate_Year 4 (16) 283 user data preferences Ecom_UserData_Preferences 60 (34) 284 schema version Ecom_SchemaVersion 30 (20) 286 wallet id Ecom_WalletID 40 (21) 287 wallet URL Ecom_Wallet_Location 128 (35) 289 customer device ID Ecom_Device_ID 20 (37) 290 customer device type Ecom_Device_Type 20 (38) 292 end transaction flag Ecom_TransactionComplete - (22) 294 The following fields are typically used to communicate from the 295 merchant to the consumer: 297 FIELD NAME Min Notes 299 merchant home domain Ecom_Merchant 128 (23) 300 processor home domain Ecom_Processor 128 (24) 301 transaction identifier Ecom_Transaction_ID 128 (25) 302 transaction URL inquiry Ecom_Transaction_Inquiry 500 (26) 303 transaction amount Ecom_Transaction_Amount 128 (27) 304 transaction currency Ecom_Transaction_CurrencyCode 3 (28) 305 transaction date Ecom_Transaction_Date 80 (29) 306 transaction type Ecom_Transaction_Type 24 (30) 307 transaction signature Ecom_Transaction_Signature 160 (31) 309 end transaction flag Ecom_TransactionComplete - (22) 311 The following fields are used to communicate between the merchant and 312 a processor acting for the merchant (such a processor is commonly 313 called an acquirer and is frequently a bank): 315 FIELD NAME Min Notes 317 merchant identifier Ecom_Merchant_ID 8 318 merchant terminal Ecom_Merchant_Terminal_ID 8 (39) 319 merchant terminal data Ecom_Merchant_Terminal_Data 128 320 transaction process code Ecom_Transaction_ProcessingCode 6 (40) 321 transaction reference Ecom_Transaction_Reference_ID 12 322 transaction acquirer Ecom_Transaction_Acquire_ID 13 (41) 323 transaction forward Ecom_Transaction_Forward_ID 13 (42) 324 transaction trace Ecom_Transaction_Trace_Audit 6 (43) 325 transaction effective date Ecom_Transaction_Effective_Date 4 (44) 326 transaction CID Ecom_Transaction_CID 8 327 transaction POS Ecom_Transaction_POSCode 12 (45) 328 transaction private use Ecom_Transaction_PrivateUseData 166 329 transaction response Ecom_Transaction_ResponseData 27 330 transaction approval code Ecom_Transaction_ApprovalCode 12 (46) 331 transaction retrieval code Ecom_Transaction_RetrievalCode 128 332 transaction response action Ecom_Transaction_ActionCode 13 (47) 333 transaction reason Ecom_Transaction_ReasonCode 4 334 transaction AAV Ecom_Transaction_AAV 3 335 transaction settlement date Ecom_Transaction_Settle_Date 4 (48) 336 transaction capture date Ecom_Transaction_Capture_Date 4 (49) 337 transaction Track 1 Ecom_Transaction_Track1 39 (50) 338 transaction Track 2 Ecom_Transaction_Track2 39 (51) 340 2.1.2 Field Foot Notes 342 ( 1) For example: Mr., Mrs., Ms., Dr. This field is commonly omitted. 344 ( 2) May also be used for middle initial. 346 ( 3) For example: Ph.D., Jr. (Junior), 3rd, Esq. (Esquire). This 347 field is commonly omitted. 349 ( 4) Address lines must be filled in the order line1, then line2, and 350 last line3. Thus, for example, it is an error for line1 to be 351 null if lines2 or line3 is not. 353 ( 5) 2 characters are the minimum for the US and Canada, other 354 countries may require longer fields. For the US use 2 character 355 US Postal state abbreviation. 357 ( 6) Minimum field lengths for Postal Code will vary based on 358 international market served. Use 5 character or 5+4 ZIP for the 359 US and 6 character postal code for Canada. The size given, 14, 360 is believed to be the maximum required anywhere in the world. 362 ( 7) Use [ISO 3166] standard two letter country codes. 364 ( 8) 10 digits are the minimum for numbers within the North American 365 Numbering Plan (: US, Canada and a number 366 of Caribbean and smaller Pacific nations (but not Cuba)), other 367 countries may require longer fields. Telephone numbers are 368 complicated by differing international access codes, variant 369 punctuation of area/city codes within countries, etc. While it 370 is desirable for telephone numbers to be in standard 371 international format [E.164], it may be necessary to use 372 heuristics or human examination based on the telephone number 373 and addresses given to figure out how to actually call a 374 customer since people may enter local formatted numbers without 375 area/access codes. It is recommend that an "x" be placed before 376 extension numbers and that the "x" and extension number appear 377 after all other parts of the number. 379 ( 9) For example: jsmith@example.com 380 (10) The name of the cardholder as it appears on the card. 382 (11) Case insensitive. Use up to the first 4 letters of the 383 association name (see also note 102): 385 AMER American Express 386 BANK Bankcard (Australia) 387 DC DC (Japan) 388 DINE Diners Club 389 DISC Discover 390 JCB JCB 391 MAST Mastercard 392 NIKO Nikos (Japan) 393 SAIS Saison (Japan) 394 UC UC (Japan) 395 UCAR UCard (Taiwan) 396 VISA Visa 398 (12) Includes the check digit at the end but no spaces or hyphens 399 [ISO 7812]. The min given, 19, is the longest number permitted 400 under the ISO standard. 402 (13) An additional cardholder verification number printed on the card 403 (but not embossed or recorded on the magnetic stripe) such as 404 the American Express CIV, MasterCard CVC2, and Visa CVV2 values. 406 (14) The day of the month. Values: 1-31. A leading zero is ignored 407 so, for example, 07 is valid for the seventh day of the month. 409 (15) The month of the year. Jan - 1, Feb - 2, March - 3, etc.; 410 Values: 1-12. A leading zero is ignored so, for example, 07 is 411 valid for July. 413 (16) The value in the wallet cell is always four digits, e.g., 1999, 414 2000, 2001, ... 416 (17) A space separated list of protocols available in connection with 417 the specified card. Initial list of case insensitive tokens: 418 none 419 set 420 setcert 421 iotp 422 echeck 423 simcard 424 phoneid 425 "Set" indicates usable with SET protocol (i.e., is in a SET 426 wallet) but does not have a SET certificate [SET]. "Setcert" 427 indicates usable with SET and has a set certificate [SET]. 428 "iotp" indicates the IOTP protocol [RFC 2801] is supported at 429 the customer. "echeck" indicates that the eCheck protocol 431 [eCheck] is supported at the customer. "simcard" indicates 432 ability to use the transaction instrument built into a Cellphone 433 subscriber for identification. "phoneid" indicates use for the 434 transaction of a billable phone number. "None" indicates that 435 automatic field fill is operating but there is no further 436 information. 438 (18) A unique order ID string generated by the consumer software. 440 (19) The user ID and password fields can be used in cases where the 441 user has a pre-established account with the merchant to which 442 access is authenticated by such values. For that use one would 443 expect an application to require exactly one user ID and one 444 password field be present. 446 (20) URI [RFC 2396]] indicating version of this set of fields. Equal 447 to "urn:ietf:params:ecml:v2.0" for this version. See section 5 448 below. (see also note 101) 450 (21) A string to identify the source and version of form fill 451 software that is acting on behalf of a user. Should contain 452 company and/or product name and version. Example "Wallets Inc., 453 SuperFill, v42.7". ( see also note 101) 455 (22) A flag to indicate that this web-page/aggregate is the final one 456 for this transaction. (see also note 101) 458 (23) Merchant domain name [RFC 1034] such as www.merchant.example. 459 (see also note 101) 461 (24) Domain name [RFC 1034] of the gateway transaction processor that 462 is actually accepting the payment on behalf of the merchant such 463 as www.processor.example. (see also note 101) 465 (25) A Transaction identification string whose format is specific to 466 the processor. 468 (26) A URL [RFC 2396] that can be invoked to inquire about the 469 transaction. (see also notes 100) 471 (27) The amount of the transaction in ISO currency format [ISO 4217]. 472 This is two integer numbers with a period in between but no 473 other currency marks (such as a $ dollar sign). 475 (28) This is the three letter ISO currency code [ISO 4217]. For 476 example, for US dollars it is USD. 478 (29) ISO Transaction date. 480 (30) The type of the transaction if known. Currently a value from 481 the following list: 482 debit 483 credit 485 (31) A digital signature base64 encoded [RFC 2045]. (see also note 486 101) 488 (32) The ReceiptTo fields are used when the BillTo entity, location, 489 or address and the ReceiptTo entity, location, or address are 490 different. For example, when using some forms of Corporate 491 Purchasing Cards or Agent Purchasing Cards, the individual card 492 holder would be in the ReceiptTo fields and the corporate or 493 other owner would be in the BillTo fields. 495 (33) An IETF Language Tag as defined in [RFC 3066]. 497 (34) User preferences as specified by the merchant. (see also note 498 102) 500 (35) Uniform Resource Locator [RFC 2396] for accessing the customer's 501 "wallet" software. (see also note 100) 503 (36) A single capital letter, M=male, F=Female, U=Unknown [ISO 5218]. 505 (37) An immutable device identification or serial number. (see also 506 note 102) 508 (38) User understandable device brand name. (see also note 102) 510 (39) [ISO 8583] field "card acceptor terminal identification". 512 (40) [ISO 8583] field "processing code". 514 (41) [ISO 8583] field "acquiring institution identification code". 516 (42) [ISO 8583] field "forwarding institution identification code". 518 (43) [ISO 8583] field "system trace audit field". 520 (44) [ISO 8583] field "date effective". 522 (45) [ISO 8583] field "point of sale date code". 524 (46) [ISO 8583] field "approval code". 526 (47) [ISO 8583] field "action code". 528 (48) [ISO 8583] field "date settlement". 530 (49) [ISO 8583] field "date capture". 532 (50) [ISO 8583] field "trace 1 data". 534 (51) [ISO 8583] field "trace 2 data". 536 (52) User recognizable loyalty card brand name. Values for this field 537 are not controlled and there is no IANA or other registry for 538 them. (see also note 102) 540 (53) The card issuer number required by the UK based Switch and Solo 541 acquirers. 543 (54) The field names "first_name" and "last_name" have been retained 544 for compatibility with earlier versions of ECML. However, 545 "last_name" should be understood to refer to family or inherited 546 names(s) while "first_name" is the first given or non-inherited 547 name and "middle_name" is the subsequent given or non-inherited 548 name or names if any. 550 (55) Uniform Resource Locator [RFC 2396] for accessing the user's 551 X.509v3 certificate encoded as binary DER. (see also note 100) 553 Meta notes (referenced by other notes): 555 (100) ECML, being a basic field naming and structuring convention, 556 does not impose any particular requirements on these URLs. It 557 is to be expected that most applications that make use of ECML 558 will impose such limitations and perform checking to be sure 559 that provided URLs conform to such limitations before 560 attempting to invoke them. 562 (101) This is a field which, when presented in a web page, is usually 563 hidden. 565 (102) An ASCII [ASCII] character string with no leading or trailing 566 white space. 568 2.2 Exemplar XML Syntax 570 The following sections provide an XML DTD and an XML Schema that 571 express the ECML fields with ECML v2 naming and ECML v2 hierarchical 572 structure. In case of conflict between this DTD and Schema, the 573 Schema should prevail. Note that the ECML v2 naming and structure may 574 be used in non-XML syntaxes. 576 The ECML v2 XML syntax is deliberately liberal on the assumption that 577 specific applications making use of ECML will impose their own 578 additional constraints. 580 For internationalization of ECML, use the general XML character 581 encoding provisions [XML] (which mandate support of UTF-8 and UTF-16 582 and permit support of other character sets) and the xml:lang 583 attribute, which may be used to specify language information. 585 2.2.1 ECML v2 XML DTD 587 The following is an XML DTD for ECML v2. 589 591 594 605 606 610 611 615 616 620 622 628 629 638 639 646 647 650 651 654 655 658 659 662 663 668 669 672 673 678 679 682 683 693 694 702 703 710 711 718 719 726 727 730 731 734 735 739 740 745 747 753 754 762 763 772 773 777 778 785 786 793 794 801 803 806 807 811 812 816 817 821 822 826 827 831 832 836 837 841 842 846 848 2.2.2 ECML v2 XML Schema 850 The following is an XML Schema for ECML v2. 852 853 855 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 896 897 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 947 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 993 994 996 999 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1018 1019 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1051 1053 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1070 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1131 1133 1135 1137 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1150 1151 1152 1153 1154 1155 1156 1158 1160 1162 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1182 1184 1186 1188 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1232 1234 3. Usage Notes for ECML v2 1236 This section provides a general usage guide for ECML v2. 1238 3.1 Presentation of the Fields 1240 ECML v2 merely names fields and specifies their content and 1241 hierarchical organization. It does not constrain the order or 1242 completeness of communication of or query for these fields. 1244 Some parties may wish to provide or ask for more information, some 1245 less by omitting fields. Some may ask for the information they want 1246 in one interaction or web page, others may ask for parts of the 1247 information at different times in multiple interactions or different 1248 web pages. For example, it is common to ask for "ship to" information 1249 earlier, so shipping cost can be computed, before the payment method 1250 information. Some parties may require that all the information they 1251 request be provided while other make much information optional. Other 1252 variations are likely. 1254 Every element may be flagged as a query or assertion by including, 1255 when XML syntax is in use, the optional Mode attribute with the value 1256 "Query" or "Assert" respectively. The Mode attribute effects all 1257 descendant elements until overridden by a lower level element with a 1258 Mode attribute. Thus it is easy to indicate that all of the elements 1259 in an ECML v2 structure are present as queries or assertions. 1261 Query elements may have data content. Such content SHOULD be 1262 interpreted as a default value to be returned if no better value is 1263 known. 1265 There is no way with Version 2.0 of ECML to indicate what query 1266 fields a party considers mandatory to be answered. From this point of 1267 view, all fields queried are optional to complete. However, a party 1268 may give an error or re-present a request for information if some 1269 field it requires is not completed, just as it may if a field is 1270 completed in a manner it considers erroneous. 1272 3.2 Methods and Flow of Setting the Fields 1274 There are a variety of methods of communication possible between the 1275 parties by which each can indicate what fields it wants the other to 1276 provide. Probably the easiest method for currently deployed mass 1277 software is as fields in an [HTML] form. Other possibilities are to 1278 use an [XML] exchange, the IOTP Authenticate transaction [RFC 2801], 1279 or proprietary protocols. 1281 So that browser software can tell what version it is dealing with, it 1282 is REQUIRED that the Ecom_SchemaVersion field be included in every 1283 transactions when ECML is being used on the web. Ecom_SchemaVersion 1284 SHOULD appear on every web page that has any Ecom fields. It is 1285 usually a hidden field in HTML Forms. 1287 User action or the appearance of the Ecom_SchemaVersion field are 1288 examples of triggers that can be used to initiate a facility capable 1289 of providing information in response to an ECML based query or 1290 utilizing information from ECML assertions. Because some web software 1291 may require user activation, it is RECOMMENDED that these be at least 1292 one user visible Ecom field on every web page with any Ecom fields 1293 present when ECML is used via the web. 1295 Because, under some circumstances, communications can proceed very 1296 slowly, it may not be clear to an automated processing function when 1297 it is finished receiving ECML fields on a web page or the like. For 1298 this reason, it is RECOMMENDED that the Ecom_SchemaVersion field be 1299 the last Ecom field on a web page. 1301 Transfer or requests for information can extend over several 1302 interactions or web pages. Without further provision, a facility 1303 could either require re-starting on each page or possibly violate or 1304 appear to violate privacy by continuing to provide personal data 1305 beyond with end of the transaction with a particular business. For 1306 this reason the Ecom_TransactionComplete field, which is normally 1307 hidden when part of an HTML Form, is provided. It is RECOMMENDED that 1308 it appear on the last interaction or web page involved in a 1309 transaction, just before an Ecom_SchemaVersion field, so that multi- 1310 interaction automated logic receives a hint as to when to stop if it 1311 chooses to check for this field. 1313 4. Security and Privacy Considerations 1315 The information called for by many of these fields is sensitive. It 1316 should be protected from unauthorized modification and kept 1317 confidential if stored in a location or transmitted over a channel 1318 where it might otherwise be observed. In addition, the authenticity 1319 of the information will be a concern in many systems. 1321 Mechanisms for such protection and authentication are not specified 1322 herein but might, depending on circumstances, include object security 1323 protocols, such as XMLDSIG [RFC 3275], XML encryption [XMLENC], or 1324 CMS [RFC 3852], or channel security such as TLS [RFC 2246] or IPSec 1325 [RFC 2411]. Systems in which an ECML field or fields are stored and 1326 later forwarded will likely find object security to be the most 1327 appropriate. 1329 When information is being requested from a user, their control over 1330 release of such information is needed to protect their privacy. 1332 Software that is installed on a shared or public terminals should be 1333 configurable such that memory of any sensitive or individual identity 1334 information is fully disabled. This is vital to protect the privacy 1335 of library patrons, students, and customers using public terminals, 1336 and children who might, for example, use a form on a public terminal 1337 without realizing that their information is being stored. 1339 When sensitive or individual identification information is stored, 1340 the operator or user should have an option to protect the 1341 information, for example with a password without which the 1342 information will be unavailable, even to someone who has access to 1343 the file(s) in which it is being stored. 1345 Any multi-page/screen or other multi-aggregate field fill in or data 1346 provision mechanism SHOULD check for the Ecom_TransactionComplete 1347 field and cease automated fill when it is encountered until fill is 1348 further authorized. 1350 It should be remembered that default, hidden, and other values 1351 transferred to another party may be maliciously modified before being 1352 returned. 1354 5. IANA Considerations 1356 The sections below provide for 1357 1. registration of the ECML v2 XML schema contained in this document, 1358 2. a version URN for ECML versions, 1359 3. the subsidiary registration of particular ECML versions and the 1360 specific registration of Version 2.0, 1361 4. three additional IANA registries for elements appearing in three 1362 ECML v2 fields. 1364 5.1 ECML v2 Schema Template 1366 The ECML v2 schema give in section 2.2.2 above is registered as 1367 follows: 1369 URI: urn:ietf:params:xml:schema: 1371 Registrant Contact: The IESG 1373 XML: The XML Schema in section 2.2.2 above. 1375 5.2 ECML v2 URN Template 1377 As specified by the template below from [RFC 3553], 1378 urn:ietf:params:ecml is permanently registered with sub registration 1379 via RFC publication. 1381 Registry name: urn:ietf:params:ecml 1383 Specification: RFC XXXX - (draft-ietf-trade-ecml2-spec-*.txt) 1385 Repository: RFC XXXX - (draft-ietf-trade-ecml2-spec-*.txt) 1387 Index value: Values subordinate to urn:ietf:params:ecml are 1388 registered by RFC publication. As provided in [RFC 3553], once 1389 such a value is registered, it may never change. 1391 5.2.1 Subregistration of v2.0 1393 The subordinate value "v2.0" is hereby permanently registered so that 1394 the URN 1396 urn:ietf:params:ecml:v2.0 1398 is used to indicate an ECML field or fields that conform to this 1399 specification. Although it is not anticipated that deeper values 1400 subordinate to this URN will need to be registered, if necessary they 1401 are registered by IESG approval.. 1403 5.3 IANA Registries 1405 There are three fields described in Section 2.1.2 that require the 1406 establishment of IANA registries as described below: 1408 Ecom_Payment_Card_Type 1409 A registry of case insensitive alphanumeric ASCII [ASCII] card 1410 type designations from one to four characters in length with no 1411 white space. See section 2.1.2, note 11, for the initial 12 1412 designations. Designations are added based on expert approval. 1413 Applicants for registration will normally be required to already 1414 have an ISO Issuer Identification Number (IIN) or set of IINs. 1416 Ecom_Payment_Card_Protocol 1417 This field holds a space separated list of protocols designated 1418 by case insensitive alphanumeric ASCII [ASCII] tokens from this 1419 registry or the token "none". See section 2.1.2, note 17, for 1420 the initial seven registered tokens (including "none") and 1421 further information. Tokens are added to the registry based on 1422 expert approval. 1424 Ecom_Transaction_Type 1425 A case insensitive alphabetic ASCII [ASCII] value indicating the 1426 type of transaction. See section 2.1.2, note 30, for the 1427 initial two registered values. Values are added based on expert 1428 approval. 1430 Normative References 1432 [ASCII] - USA Standard Code for Information Interchange, X3.4 1433 American National Standards Institute; New York, 1968. 1435 [E.164] - ITU-T Recommendation E.164/I.331 (05/97): The International 1436 Public Telecommunication Numbering Plan. 1997. 1438 [IANA] - Internet Assigned Numbers Authority, Official Names for 1439 Character Sets, ed. Keld Simonsen et al. . 1442 [ISO 3166] - "Codes for the representation of names of countries and 1443 their subdivisions -- Part 1: Country codes", ISO 3166-1, 1997. 1445 [ISO 4217] - "Codes for the representation of currencies and funds", 1446 ISO 4217, 2001. 1448 [ISO 5218] - "Information interchange -- Representation of human 1449 sexes", ISO 5218, 1977. 1451 [ISO 7812] - "Identification card - Identification of issuers - Part 1452 1: Numbering system", ISO 7812-1, 2000. 1454 [ISO 8583] - "Financial transaction card originated messages - 1455 Interchange message specifications - Part 1: Messages, elements and 1456 code values", ISO 8583-1, 2001. 1458 [RFC 1766] - "Tags for the Identification of Languages", H. 1459 Alvestrand, March 1995. 1461 [RFC 2045] - "Multipurpose Internet Mail Extensions (MIME) Part One: 1462 Format of Internet Message Bodies", N. Freed, N. Borenstein, November 1463 1996. 1465 [RFC 2396] - "Uniform Resource Identifiers (URI): Generic Syntax", T. 1466 Berners-Lee, R. Fielding, L. Masinter, August 1998. 1468 [RFC 3066] - "Tags for the Identification of Languages", H. 1469 Alvestrand, January 2001. 1471 [XML] - Extensible Markup Language (XML) 1.0 (Second Edition), 1472 , T. Bray, J. Paoli, C. M. 1473 Sperberg-McQueen, E. Maler 1475 Informative References 1477 [eCheck] - 1479 [EMV] - 1481 [HTML] - "HTML 3.2 Reference Specification", < 1482 http://www.w3.org/TR/REC-html32.html>, D. Raggett, January 1997. 1484 [P3P BASE] - "The Platform for Privacy Preferences 1.0 (P3P1.0) 1485 Specification", L. Cranor, M. Langheinrich, M. Marchiori, M. Presler- 1486 Marshall, J. Reagle, December 2000, . 1489 [P3P ECOM] - "Using P3P for E-Commerce", J. Coco, S. Klien, D. 1490 Schutzer, S. Yen, A. Slater, November 1999, 1491 . 1493 [RFC 1034] - "Domain names - concepts and facilities", P.V. 1494 Mockapetris, Nov-01-1987. 1496 [RFC 2026] - "The Internet Standards Process -- Revision 3", S. 1497 Bradner, October 1996. 1499 [RFC 2246] - "The TLS Protocol: Version 1.0", T. Dierks, C. Allen. 1500 January 1999. 1502 [RFC 2411] - "IP Security: Document Roadmap", R. Thayer, N. 1503 Doraswany, R. Glenn, November 1998. 1505 [RFC 2706] - "ECML v1: Field Names for E-Commerce", D. Eastlake, T. 1506 Goldstein, September 1999. 1508 [RFC 2801] - "Internet Open Trading Protocol - IOTP Version 1.0", D. 1509 Burdett, April 2000. 1511 [RFC 3106] - "ECML v1.1: Field Specifications for E-Commerce", D. 1512 Eastlake, T. Goldstein, April 2001. 1514 [RFC 3275] - "(Extensible Markup Language) XML-Signature Syntax and 1515 Processing", D. Eastlake 3rd, J. Reagle, D. Solo, March 2002. 1517 [RFC 3553] - "An IETF URN Sub-namespace for Registered Protocol 1518 Parameters", M. Mealling, L. Masinter, T. Hardie, G. Klyne, June 1519 2003. 1521 [RFC 3852] - "Cryptographic Message Syntax (CMS)", R. Housley, July 1522 2004. 1524 [SET] - Secure Electronic Transaction, 1525 1527 [XMLENC] - "XML Encryption Syntax and Processing", D. Eastlake 3rd, 1528 J. Reagle, http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/, 1529 December 2002. 1531 Appendix: Changes from v1.1 to v2 1533 Substantial rewording of text to change the emphasis from HTML Form 1534 Fields to XML Syntax. 1536 Addition of the merchant -> processor fields. 1538 Addition of the Ecom_Wallet_Location and Ecom_User_Certificate_URL 1539 fields. 1541 Addition of the "Mode" attribute. 1543 Addition of the ECom_Payment_Card_IssueNumber, Loyalty Card fields, 1544 Device ID, Valid From, and User Data fields. 1546 Addition of an XML schema. 1548 Some minor fixes related to telephone numbers. 1550 Addition of IANA Considerations section. 1552 Updating of RFC references for obsoleted RFCs. 1554 Copyright and Disclaimer 1556 Copyright (C) The Internet Society 2004. This document is subject to 1557 the rights, licenses and restrictions contained in BCP 78 and except 1558 as set forth therein, the authors retain all their rights. 1560 This document and the information contained herein are provided on an 1561 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1562 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1563 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1564 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1565 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1566 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1568 Author's Addresses 1570 Donald E. Eastlake 3rd 1571 Motorola Laboratories 1572 155 Beaver Street 1573 Milford, MA 01757 USA 1575 Phone: 1-508-786-7554 (work) 1576 1-508-634-2066 (home) 1577 EMail: Donald.Eastlake@motorola.com 1579 File name and Expiration 1581 This file is draft-ietf-trade-ecml2-spec-13.txt. 1583 It expires April 2005.