idnits 2.17.1 draft-ietf-trade-ecml2-spec-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 14 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** 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 141: '...ard, field names MUST be structured an...' RFC 2119 keyword, line 157: '...protocol used. The RECOMMENDED syntax...' RFC 2119 keyword, line 634: '... is REQUIRED that the Ecom_SchemaVer...' RFC 2119 keyword, line 659: '...provided. It is RECOMMENDED that it a...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (February 2001) is 8468 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ISO 8583' is mentioned on line 122, but not defined == Unused Reference: 'IANA' is defined on line 706, but no explicit reference was found in the text == Unused Reference: 'ISO 7812' is defined on line 713, but no explicit reference was found in the text == Unused Reference: 'RFC 1766' is defined on line 725, but no explicit reference was found in the text == Unused Reference: 'RFC 2026' is defined on line 728, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ECML' -- Possible downref: Non-RFC (?) normative reference: ref. 'EMV' -- Possible downref: Non-RFC (?) normative reference: ref. 'HTML' -- 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 7812' -- Possible downref: Non-RFC (?) normative reference: ref. 'P3P BASE' -- Possible downref: Non-RFC (?) normative reference: ref. 'P3P ECOM' ** Obsolete normative reference: RFC 1766 (Obsoleted by RFC 3066, RFC 3282) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2411 (Obsoleted by RFC 6071) ** Obsolete normative reference: RFC 2706 (Obsoleted by RFC 3106) ** Downref: Normative reference to an Informational RFC: RFC 2801 -- Possible downref: Non-RFC (?) normative reference: ref. 'SET' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' Summary: 13 errors (**), 0 flaws (~~), 7 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Jon W. Parsons 2 American Express 3 Expires August 2001 February 2001 5 Electronic Commerce Modeling Language (ECML): 6 Version 2 Specification 7 9 Status of this Memo 11 This draft is intended to become a Proposed Standard. Distribution 12 of this document is unlimited. Comments should be sent to the author 13 or the IETF TRADE working group . 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC 2026. Internet-Drafts are 17 working documents of the Internet Engineering Task Force (IETF), its 18 areas, and its working groups. Note that other groups may also 19 distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) 2001, The Internet Society. All Rights Reserved. 36 Abstract 38 Electronic commerce frequently requires a substantial exchange of 39 information in order to complete a purchase or other transaction, 40 especially the first time the parties communicate. A standard set of 41 hierarchicly organized payment related information fields in an XML 42 syntax are defined as the second version of an Electronic Commerce 43 Modeling Language (ECML) so that this task can be more easily 44 automated, for example by wallet software. 46 Acknowledgements 48 The following persons, in alphabetic order, contributed substantially 49 to the material herein: 51 Donald Eastlake 3rd 53 David Shepherd 55 Table of Contents 57 Status of this Memo........................................1 58 Copyright Notice...........................................1 59 Abstract...................................................1 61 Acknowledgements...........................................2 62 Table of Contents..........................................2 64 1. Introduction............................................3 65 1.2 Relationship to Other Standards........................3 67 2. Field Definitions and DTD...............................4 68 2.1 Field List and Descriptions............................4 69 2.1.1 Field List...........................................4 70 2.1.2 Field Foot Notes.....................................7 71 2.2 ECML v2 XML DTD.......................................10 72 3. Usage Notes for ECML v2................................13 73 3.1 Presentation of the Fields............................13 74 3.2 Methods and Flow of Setting the Fields................14 75 4. Security and Privacy Considerations....................14 77 References................................................16 78 Appendix: Changes from v1.1 to v2.........................17 80 Full Copyright Statement..................................18 82 Author's Address..........................................19 83 File name and Expiration..................................19 85 1. Introduction 87 Today, numerous partries are successfully conducting business on the 88 Internet using ad hoc fields and forms. The data formats and 89 structure can vary considerably from one party to another. Where 90 forms are filled out manually, many users find the diversity 91 confusing and the process of manually filling in these forms to be 92 tedious and error prone. 94 Software tools including electronic wallets can help this situation. 95 Such tools can assist in conducting online transactions by storing 96 billing, shipping, payment, preference, and similar information and 97 using this information to automatically complete the data sets 98 required by interactions. For examplte, software that fills out 99 forms has been successfully built into browsers, as proxy servers, as 100 helper applications to browsers, as stand-alone applications, as 101 browser plug-ins, and as server-based applications. But the 102 proliferation of more automated transactions software has been 103 hampered by the lack of standards. 105 ECML (Electronic Commerce Modeling Language) provides a set of 106 hierarchical payment oriented data structures that will enable 107 automated software, including electronic wallets, from multiple 108 vendors to supply neede data in a more uniform manner. 110 Version 2.0 extends Verion 1.0 [RFC 2706] and 1.1 [RFC v1.1] as 111 described in the Appendix to this document. These enhancements 112 include support for additional payment mechanisms and a 114 This is an open standard. ECML is designed to be simple. 116 1.2 Relationship to Other Standards 118 The ECML fields were initially derived from the W3C P3P base data 119 schema [P3P BASE] by the ECML Alliance [ECML]. Technical development 120 and change control of ECML has now been trasnfered to the IETF. In 121 version 2, ECML is extended by the fields in a W3C P3P Note related 122 to eCommerce [P3P ECOM], by [ISO 8583], and by other sources. Its 123 primary form will be an XML syntax. 125 ECML Version 2.0 is not a replacement or alternative to TLS/SSL [RFC 126 2246], SET [SET], EMV [EMV], XML [XML], or IOTP [RFC 2801]. These are 127 important standards that provide functionality such as 128 confidentiality, non-repudiatable transactions, automatable payment 129 scheme selection, and smart card support. 131 2. Field Definitions and DTD 133 The ECML Standard is the definition and naming of a hierarcically 134 structured set of fields and the provision of an XML syntax for their 135 transmition. These fields can be encoded in other syntaxes and 136 transmitted via a variety of protocols. 138 Section 2.1 below lists and describes the fields and Section 2.2 139 provides an XML DTD for use with the fields. 141 To conform to this standard, field names MUST be structured and named 142 as closely to the structure and naming listed below as permitted by 143 the syntax and transaction protocol in use. (Note: this does not 144 impose any restriction on human visible labeling of fields, just on 145 their names as used in communication.) 147 2.1 Field List and Descriptions 149 The fields are listed below along with the minimum data entry size to 150 allow. Note that these fields are hierarchically organized as 151 indicated in this table by the embedded underscore ("_") characters. 152 Appropriate data transmission mechanisms may use this to request and 153 send aggregates, such as Ecom_Payment_Card_ExpDate to encompass all 154 the date components or Ecom_ShipTo to encompass all the ship to 155 components that a consumer is willing to provide. The labeling, 156 marshalling, unmarshalling of the components of such aggregates 157 depends on the data transfer protocol used. The RECOMMENDED syntax 158 is XML as described in Section 2.2. 160 2.1.1 Field List 162 IMPORTANT NOTE: "MIN" in the table below is the MINIMUM DATA SIZE TO 163 ALLOW FOR ON DATA ENTRY. It is NOT the minimum size for valid 164 contents of the field and merchant software should, in most 165 cases, be prepared to receive a longer or shorter value. 166 Merchant dealing with areas where, for example, the 167 state/province name or phone number is longer than the "Min" 168 given below must obviously permit longer data entry. In some 169 cases, however, there is a maximum size that makes sense and 170 where this is the case, it is documented in a Note for the 171 field. 173 The following fields are used to communicate from the customer 174 to the merchant: 176 FIELD NAME Min Notes 178 ship to title Ecom_ShipTo_Postal_Name_Prefix 4 ( 1) 179 ship to first name Ecom_ShipTo_Postal_Name_First 15 180 ship to middle name Ecom_ShipTo_Postal_Name_Middle 15 ( 2) 181 ship to last name Ecom_ShipTo_Postal_Name_Last 15 182 ship to name suffix Ecom_ShipTo_Postal_Name_Suffix 4 ( 3) 183 ship to company name Ecom_ShipTo_Postal_Company 20 184 ship to street line1 Ecom_ShipTo_Postal_Street_Line1 20 ( 4) 185 ship to street line2 Ecom_ShipTo_Postal_Street_Line2 20 ( 4) 186 ship to street line3 Ecom_ShipTo_Postal_Street_Line3 20 ( 4) 187 ship to city Ecom_ShipTo_Postal_City 22 188 ship to state/province Ecom_ShipTo_Postal_StateProv 2 ( 5) 189 ship to zip/postal code Ecom_ShipTo_Postal_PostalCode 14 ( 6) 190 ship to country Ecom_ShipTo_Postal_CountryCode 2 ( 7) 191 ship to phone Ecom_ShipTo_Telecom_Phone_Number 10 ( 8) 192 ship to email Ecom_ShipTo_Online_Email 40 ( 9) 194 bill to title Ecom_BillTo_Postal_Name_Prefix 4 ( 1) 195 bill to first name Ecom_BillTo_Postal_Name_First 15 196 bill to middle name Ecom_BillTo_Postal_Name_Middle 15 ( 2) 197 bill to last name Ecom_BillTo_Postal_Name_Last 15 198 bill to name suffix Ecom_BillTo_Postal_Name_Suffix 4 ( 3) 199 bill to company name Ecom_BillTo_Postal_Company 20 200 bill to street line1 Ecom_BillTo_Postal_Street_Line1 20 ( 4) 201 bill to street line2 Ecom_BillTo_Postal_Street_Line2 20 ( 4) 202 bill to street line3 Ecom_BillTo_Postal_Street_Line3 20 ( 4) 203 bill to city Ecom_BillTo_Postal_City 22 204 bill to state/province Ecom_BillTo_Postal_StateProv 2 ( 5) 205 bill to zip/postal code Ecom_BillTo_Postal_PostalCode 14 ( 6) 206 bill to country Ecom_BillTo_Postal_CountryCode 2 ( 7) 207 bill to phone Ecom_BillTo_Telecom_Phone_Number 10 ( 8) 208 bill to email Ecom_BillTo_Online_Email 40 ( 9) 210 receipt to (32) 211 receipt to title Ecom_ReceiptTo_Postal_Name_Prefix 4 ( 1) 212 receipt to first name Ecom_ReceiptTo_Postal_Name_First 15 213 receipt to middle name Ecom_ReceiptTo_Postal_Name_Middle 15 ( 2) 214 receipt to last name Ecom_ReceiptTo_Postal_Name_Last 15 215 receipt to name suffix Ecom_ReceiptTo_Postal_Name_Suffix 4 ( 3) 216 receipt to company name Ecom_ReceiptTo_Postal_Company 20 217 receipt to street line1 Ecom_ReceiptTo_Postal_Street_Line1 20 ( 4) 218 receipt to street line2 Ecom_ReceiptTo_Postal_Street_Line2 20 ( 4) 219 receipt to street line3 Ecom_ReceiptTo_Postal_Street_Line3 20 ( 4) 220 receipt to city Ecom_ReceiptTo_Postal_City 22 221 receipt to state/province Ecom_ReceiptTo_Postal_StateProv 2 ( 5) 222 receipt to postal code Ecom_ReceiptTo_Postal_PostalCode 14 ( 6) 223 receipt to country Ecom_ReceiptTo_Postal_CountryCode 2 ( 7) 224 receipt to phone Ecom_ReceiptTo_Telecom_Phone_Number 10 ( 8) 225 receipt to email Ecom_ReceiptTo_Online_Email 40 ( 9) 226 name on card Ecom_Payment_Card_Name 30 (10) 228 card type Ecom_Payment_Card_Type 4 (11) 229 card number Ecom_Payment_Card_Number 19 (12) 230 card verification value Ecom_Payment_Card_Verification 4 (13) 232 card expire date day Ecom_Payment_Card_ExpDate_Day 2 (14) 233 card expire date month Ecom_Payment_Card_ExpDate_Month 2 (15) 234 card expire date year Ecom_Payment_Card_ExpDate_Year 4 (16) 236 card protocols Ecom_Payment_Card_Protocol 20 (17) 238 consumer order ID Ecom_ConsumerOrderID 20 (18) 240 user ID Ecom_User_ID 40 (19) 241 user password Ecom_User_Password 20 (19) 243 schema version Ecom_SchemaVersion 30 (20) 245 wallet id Ecom_WalletID 40 (21) 247 end transaction flag Ecom_TransactionComplete - (22) 249 The following fields are used to communicate from the merchant to the 250 consumer: 252 FIELD NAME Min Notes 254 merchant home domain Ecom_Merchant 128 (23) 255 processor home domain Ecom_Processor 128 (24) 256 transaction identifier Ecom_Transaction_ID 128 (25) 257 transaction URL inquiry Ecom_Transaction_Inquiry 500 (26) 258 transaction amount Ecom_Transaction_Amount 128 (27) 259 transaction currency Ecom_Transaction_CurrencyCode 3 (28) 260 transaction date Ecom_Transaction_Date 80 (29) 261 transaction type Ecom_Transaction_Type 40 (30) 262 transaction signature Ecom_Transaction_Signature 160 (31) 264 end transaction flag Ecom_TransactionComplete - (22) 266 The following fields are used to communicate between the merchant and 267 the processor: 269 FIELD NAME Min Notes 271 merchant identifier Ecom_Merchant_ID 8 (*) 272 merchant terminal Ecom_Merchant_Terminal_ID 8 (*) 273 merchant terminal data Ecom_Merchant_Terminal_Data 128 (*) 274 transaction process code Ecom_Transaction_ProcessingCode 6 (*) 275 transaction reference Ecom_Transaction_Reference_ID 12 (*) 276 transaction acquirer Ecom_Transaction_Acquire_ID 13 (*) 277 transaction forward Ecom_Transaction_Forward_ID 13 (*) 278 transaction trace Ecom_Transaction_Trace_Audit 6 (*) 279 transaction effective date Ecom_Transaction_Effective_Date 4 (*) 280 transaction CID Ecom_Transaction_CID 8 (*) 281 transaction POS Ecom_Transaction_POSCode 12 (*) 282 transaction private use Ecom_Transaction_PrivateUseData 166 (*) 283 transaction response Ecom_Transaction_ResponseData 27 (*) 284 transaction approval code Ecom_Transaction_ApprovalCode 6 (*) 285 transaction retrieval code Ecom_Transaction_RetrievalCode 128 (*) 286 transaction response action Ecom_Transaction_ActionCode 13 (*) 287 transaction reason Ecom_Transaction_ReasonCode 4 (*) 288 transaction AAV Ecom_Transaction_AAV 3 (*) 289 transaction settlement date Ecom_Transaction_Settle_Date 4 (*) 290 transaction capture date Ecom_Transaction_Capture_Date 4 (*) 291 transaction Track 1 Ecom_Transaction_Track1 39 (*) 292 transaction Track 2 Ecom_Transaction_Track2 39 (*) 294 IMPORTANT NOTE: "MIN" in the table above is the MINIMUM DATA SIZE TO 295 ALLOW FOR ON DATA ENTRY. It is NOT the minimum size for valid 296 contents of the field and merchant software should, in most cases, be 297 prepared to receive a longer or shorter value. Merchant dealing with 298 areas where, for example, the state/province name or phone number is 299 longer than the "Min" given below must obviously permit longer data 300 entry. In some cases, however, there is a maximum size that makes 301 sense and this is documented in a Note for the field. 303 2.1.2 Field Foot Notes 305 ( 1) For example: Mr., Mrs., Ms., Dr. This field is commonly not used. 307 ( 2) May also be used for middle initial. 309 ( 3) For example: Ph.D., Jr. (Junior), 3rd, Esq. (Esquire). This field 310 is commonly not used. 312 ( 4) Address lines must be filled in the order line1, then line2, and 313 last line3. 315 ( 5) 2 characters are the minimum for the US and Canada, 316 other countries may require longer fields. 317 For the US use 2 character US Postal state abbreviation. 319 ( 6) Minimum field lengths for Postal Code will vary based on 320 international market served. Use 5 character or 5+4 ZIP for the US 321 and 6 character postal code for Canada. The size given, 14, is 322 believed to be the maximum required anywhere in the world. 324 ( 7) Use [ISO 3166] standard two letter codes. See 325 for country 326 names. 328 ( 8) 10 digits are the minimum for numbers local to the North American 329 Numbering Plan (: US, Canada and a number of 330 smaller Caribbean and Pacific nations (but not Cuba)), other countries 331 may require longer fields. Telephone numbers are complicated by 332 differing international access codes, variant punctuation of area/city 333 codes within countries, confusion caused by the fact that the 334 international access code in the NANP region is usually the same as 335 the "country code" for that area (1), etc. It will probably be 336 necessary to use heuristics or human examination based on the 337 telephone number and addresses given to figure out how to actually 338 call a customer. It is recommend that an "x" be placed before 339 extension numbers. 341 ( 9) For example: jsmith@example.com 343 (10) The name of the cardholder. 345 (11) Use the first 4 letters of the association name: 347 AMER American Express 348 BANK Bankcard (Australia) 349 DC DC (Japan) 350 DINE Diners Club 351 DISC Discover 352 JCB JCB 353 MAST Mastercard 354 NIKO Nikos (Japan) 355 SAIS Saison (Japan) 356 UC UC (Japan) 357 UCAR UCard (Taiwan) 358 VISA Visa 360 (12) Includes the check digit at end but no spaces or hyphens [ISO 361 7812]. The Min given, 19, is the longest number permitted under the 362 ISO standard. 364 (13) An additional cardholder verification number printed on the card 365 (but not embossed or recorded on the magnetic stripe) such as 366 American Express' CIV, MasterCard's CVC2, and Visa's CVV2 values. 368 (14) The day of the month. Values: 1-31. A leading zero is ignored 369 so, for example, 07 is valid for the seventh day of the month. 371 (15) The month of the year. Jan - 1, Feb - 2, March - 3, etc.; 372 Values: 1-12. A leading zero is ignored so, for example, 07 is valid 373 for July. 375 (16) The value in the wallet cell is always four digits, e.g., 1999, 376 2000, 2001, ... 378 (17) A space separated list of protocols available in connection with 379 the specified card. Initial list of case insensitive tokens: 380 none 381 set 382 setcert 383 iotp 384 echeck 385 simcard 386 phoneid 387 "Set" indicates usable with SET protocol (i.e., is in a SET wallet) 388 but does not have a SET certificate. "Setcert" indicates same but 389 does have a set certificate. "iotp" indicates the IOTP protocol [RFC 390 2801] is supported at the customer. "echeck" indicates that the 391 eCheck protocol [eCheck] is supported at the customer. "simcard" 392 indicates use the transaction instrument built into a Cellphone 393 subscriber for identification. "phoneid" indicates use the 394 transaction instrument of a phone bill instrument. "None" indicates 395 that automatic field fill is operating but there is no SET wallet or 396 the card is not entered in any SET wallet. 398 (18) A unique order ID generated by the consumer software. 400 (19) The user ID and password fields are used in cases where the user 401 has a pre-established account with the merchant. 403 (20) URI indicating version of this set of fields. Usually a hidden 404 field. Equal to "http://www.ecml.org/version/1.1" for this version. 406 (21) A string to identify the source and version of the form fill 407 software that is acting on behalf of the user. Should contain 408 company and/or product name and version. Example "Wallets Inc., 409 SuperFill, v42.7". Usually a hidden field. 411 (22) A flag to indicate that this web-page/aggregate is the final one 412 for this transaction. Usually a hidden field. 414 (23) Merchant domain name such as www.merchant.example. This is 415 usually a hidden field. 417 (24) Gateway transaction processor who is actually accepting the 418 payment on behalf of the merchant in home domain such as 419 www.processor.example. This is usually a hidden field. 421 (25) A Transaction identification string whose format is specific to 422 the processor. This is usually a hidden field. 424 (26) A URL that can be invoke to inquire about the transaction. This 425 is usually a hidden field. 427 (27) The amount of the transaction in ISO currency format. This is 428 two integer numbers with a period in between but no other currency 429 marks (such as a $ dollar sign). This is usually a hidden field. 431 (28) This is the three letter ISO currency code. For example, for US 432 dollars it is USD. This is usually a hidden field. 434 (29) ISO Transaction date. This is usually a hidden field. 436 (30) The type of the transaction (either debit or credit) if known. 437 This is usually a hidden field. 439 (31) The signature of the encoded certificate. This is usually a 440 hidden field. 442 (32) The Receipt To fields are used when the Bill To entity, 443 location, or address and the Receipto entity, location, or address 444 are different. For example, when using some forms of Corporate 445 Purchasing Cards or Agent Purchasing Cards, the individual card 446 holder would be in the Receipt To fields and the corporate or other 447 owner would be in the Bill To fields. 449 (*) TBD. 451 2.2 ECML v2 XML DTD 453 For internationalization of [XML] ECML, use the general XML character 454 encoding provisions, which mandate support of UTF-8 and UTF-16 and 455 permit support of other character sets, and the xml:lang attribute 456 which may be used to specify language information. 458 460 462 470 471 474 475 478 479 482 484 489 490 498 499 505 507 509 511 513 514 518 520 521 525 527 528 536 537 543 544 547 549 551 553 557 564 569 570 578 586 587 595 597 3. Usage Notes for ECML v2 599 This section provides a general usage guide for ECML v2. 601 3.1 Presentation of the Fields 603 This standard does not constrain the order or completeness of 604 communication of or query for these fields. 606 Some parties may wish to to provide or ask for more information, some 607 less by omitting fields. Some may ask for the information they want 608 in one interaction or web page, others may ask for parts of the 609 information at different times in multiple interactions or different 610 web pages. For example, it is common to ask for "ship to" information 611 earlier, so shipping cost can be computed, before the payment method 612 information. Some parties may require that all the information they 613 request be provided while other make much information optional. Etc. 615 There is no way with Version 2.0 of ECML to indicate what fields the 616 party considers mandatory [should this be?]. From the point of view 617 of software, all fields queried are optional to complete. However, a 618 party may give an error or re-present a request for information if 619 some field it requires is not completed, just as it may if a field is 620 completed in a manner it considers erroneous. 622 3.2 Methods and Flow of Setting the Fields 624 [The following is pretty web page oriented...] 626 There are a variety of methods of communication possible between the 627 parties by which one can indicate what fields it wants the other to 628 provide. Probably the easiest to use for currently deployed mass 629 software is as fields in an [HTML] form. Other possibilities are to 630 use an [XML] exchange, the IOTP Authenticate transaction [RFC 2801], 631 or proprietary protocols. 633 So that browser software can tell what version it is dealing with, it 634 is REQUIRED that the Ecom_SchemaVersion field be included in every 635 transactions when ECML is being used on the web. Ecom_SchemaVersion 636 must appear on every web page that has any Ecom fields and is usually 637 a hidden field. 639 User action or the appearance of the Ecom_SchemaVersion field are 640 examples of triggers that could be used to initiate a facility 641 capable of providing information in response to an ECML based query. 642 Because some web software may require user activation, there should 643 be at least one user visible Ecom field on every web page with any 644 Ecom fields present that are to be filled in when ECML is used via 645 the web. 647 Because, under some circumstances, communications can proceed very 648 slowly, it may not be clear to an automated field fill-in function 649 when it is finished filling in fields on a web page or the like. For 650 this reason, it is recommended that the Ecom_SchemaVersion field be 651 the last Ecom field on a web page. 653 Transfer or requests for information can extend over several 654 interactions or web pages. Without further provision, a facility 655 could either require re-starting on each page or possibly violate or 656 appear to violate privacy by continuing to provide personal data 657 beyond with end of the transaction with a particular business. For 658 this reason the Ecom_TransactionComplete field, which is normally 659 hidden, is provided. It is RECOMMENDED that it appear on the last 660 interaction or web page involved in a transaction, just before an 661 Ecom_SchemaVersion field, so that multi-interaction automated logic 662 can know when to stop if it chooses to check for this field. 664 4. Security and Privacy Considerations 666 The information called for by many of these fields is sensitive and 667 should be secured if being sent over the public Internet or through 668 other channels where it can be observed. Mechanisms for such 669 protection are not specified herein but channel encryption such as 670 TLS/SSL [RFC 2246] or IPSec [RFC 2411] would be appropriate in many 671 cases. 673 When information is being requested from a user, their control over 674 release of such information is needed to protect their privacy. 676 Software that is installed on a shared or public terminal should be 677 configurable such that memory of any sensitive or individual identity 678 information is fully disabled. This is vital to protect the privacy 679 of library patrons, students, and customers using public terminals, 680 and children who might, for example, use a form on a public terminal 681 without realizing that their information is being stored. 683 When sensitive or individual identification information is stored, 684 the operator/user should have an option to protect the information 685 with a password, without which the information will be unavailable, 686 even to someone who has access to the file(s) in which it is being 687 stored. This might also allow for a convenient method for multiple 688 users to use their own ECML information from the same software. 690 Any multi-page/screen or other multi-aggregate field fill in or data 691 provision mechanism should check for the Ecom_TransactionComplete 692 field and cease automated fill when it is encountered until fill is 693 further authorized. 695 References 697 [eCheck] - 699 [ECML] - 701 [EMV] - 703 [HTML] - "HTML 3.2 Reference Specification", < 704 http://www.w3.org/TR/REC-html32.html>, D. Raggett, January 1997. 706 [IANA] - Internet Assigned Numbers Authority, Official Names for 707 Character Sets, ed. Keld Simonsen et al. . 710 [ISO 3166] - Codes for the representation of names of countries, 711 713 [ISO 7812] - "Identification card - Identification of issuers - Part 714 1: Numbering system" 716 [P3P BASE] - "The Platform for Privacy Preferences 1.0 (P3P1.0) 717 Specification", L. Cranor, M. Langheinrich, M. Marchiori, M. 718 Presler-Marshall, J. Reagle, December 2000, 719 . 721 [P3P ECOM] - "Using P3P for E-Commerce", J. Coco, S. Klien, D. 722 Schutzer, S. Yen, A. Slater, November 1999, 723 . 725 [RFC 1766] - "Tags for the Identification of Languages", H. 726 Alvestrand. March 1995. 728 [RFC 2026] - "The Internet Standards Process -- Revision 3", S. 729 Bradner, October 1996. 731 [RFC 2246] - "The TLS Protocol: Version 1.0", T. Dierks, C. Allen. 732 January 1999. 734 [RFC 2411] - "IP Security: Document Roadmap", R. Thayer, N. 735 Doraswany, R. Glenn. November 1998. 737 [RFC 2706] - "ECML v1: Field Names for E-Commerce", D. Eastlake, T. 738 Goldstein, September 1999. 740 [RFC 2801] - "Internet Open Trading Protocol - IOTP Version 1.0", D. 741 Burdett, April 2000. 743 [RFC v1.1] - "ECML v1.1: Field Specifications for E-Commerce", D. 744 Eastlake, T. Goldstein, , in RFC Editor's queue for publication 746 as a non-WG Informational RFC. 748 [SET] - Secure Electronic Transaction, 749 751 [XML] - Extensible Markup Language (XML) 1.0 (Second Edition), 752 , T. Bray, J. Paoli, C. M. 753 Sperberg-McQueen, E. Maler 755 Appendix: Changes from v1.1 to v2 757 Substantial rewording of text to attempt to change the emphasis from 758 an HTML Form Field naming to XML Syntax. 760 Addition of the merhcant -> processor fields. 762 Full Copyright Statement 764 Copyright (C) 2001, The Internet Society. All Rights Reserved. 766 This document and translations of it may be copied and furnished to 767 others, and derivative works that comment on or otherwise explain it 768 or assist in its implementation may be prepared, copied, published 769 and distributed, in whole or in part, without restriction of any 770 kind, provided that the above copyright notice and this paragraph are 771 included on all such copies and derivative works. However, this 772 document itself may not be modified in any way, such as by removing 773 the copyright notice or references to the Internet Society or other 774 Internet organizations, except as needed for the purpose of 775 developing Internet standards in which case the procedures for 776 copyrights defined in the Internet Standards process must be 777 followed, or as required to translate it into languages other than 778 English. 780 The limited permissions granted above are perpetual and will not be 781 revoked by the Internet Society or its successors or assigns. 783 This document and the information contained herein is provided on an 784 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 785 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 786 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 787 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 788 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 790 Author's Address 792 Jon W. Parsons 793 American Express Corporation 794 Establishment Services Technologies 795 10010 W. 25TH AVE, MC 43-02-04 796 Phoenix AZ 85021 798 Phone: 1.602.766.5559 799 EMail: jon.w.parsons@aexp.com 801 File name and Expiration 803 This file is draft-ietf-trade-ecml2-spec-00.txt. 805 It expires August 2001.