idnits 2.17.1 draft-ietf-trade-ecml2-req-04.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 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 is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 (July 2001) is 8321 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) -- Looks like a reference, but probably isn't: '3106' on line 93 == Missing Reference: 'W3C ECOM' is mentioned on line 170, but not defined == Missing Reference: 'IOTP' is mentioned on line 176, but not defined == Missing Reference: 'P3P NOTE' is mentioned on line 187, but not defined == Unused Reference: 'Berners-Lee' is defined on line 233, but no explicit reference was found in the text == Unused Reference: 'HTML' is defined on line 242, but no explicit reference was found in the text == Unused Reference: 'RFC 2026' is defined on line 255, but no explicit reference was found in the text == Unused Reference: 'RFC 2246' is defined on line 258, but no explicit reference was found in the text == Unused Reference: 'WebData' is defined on line 282, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ACH' -- Possible downref: Non-RFC (?) normative reference: ref. 'Berners-Lee' -- Possible downref: Non-RFC (?) normative reference: ref. 'ECML' -- Possible downref: Non-RFC (?) normative reference: ref. 'HTML' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO 8583' -- Possible downref: Non-RFC (?) normative reference: ref. 'JCM' -- Possible downref: Non-RFC (?) normative reference: ref. 'EMV' ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2706 (Obsoleted by RFC 3106) ** Downref: Normative reference to an Informational RFC: RFC 2801 ** Downref: Normative reference to an Informational RFC: RFC 3106 -- Possible downref: Non-RFC (?) normative reference: ref. 'P3P BASE' -- Possible downref: Non-RFC (?) normative reference: ref. 'P3P ECOM' -- Possible downref: Non-RFC (?) normative reference: ref. 'SET' -- Possible downref: Non-RFC (?) normative reference: ref. 'WebData' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' Summary: 10 errors (**), 0 flaws (~~), 10 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Jon W. Parsons (SeraNova) 2 David Shepherd (IBM) 3 Donald E. Eastlake 3rd (Motorola) 4 Expires January 2002 July 2001 6 Electronic Commerce Modeling Language (ECML): 7 Version 2 Requirements 8 10 Status of this Memo 12 Distribution of this document is unlimited. Comments should be sent 13 to the authors or the IETF TRADE working group . 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC 2026. Internet-Drafts are 18 working documents of the Internet Engineering Task Force (IETF), its 19 areas, and its working groups. Note that other groups may also 20 distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) 2001, The Internet Society. All Rights Reserved. 37 Abstract 39 This document lists the design principles, scope, and requirements 40 for the Electronic Commerce Modeling Language (ECML) version 2 41 specification. It includes requirements as they relate to XML syntax, 42 data model, format, and payment processing. 44 Table of Contents 46 Status of this Memo........................................1 47 Copyright Notice...........................................1 48 Abstract...................................................1 50 Table of Contents..........................................2 52 1. Introduction............................................3 53 1.1 Relationship to Other Standards........................3 54 2. Design Principles and Scope.............................3 55 3. Requirements............................................4 56 3.1 Payment Processing Elements............................4 57 3.2 Payment Processing Types...............................5 58 3.3 XML Data Model and Syntax..............................5 59 3.4 Implementation.........................................5 60 3.5 Detailed Requests......................................5 61 4. Security Considerations.................................6 63 References.................................................7 65 Authors Addresses..........................................9 67 Full Copyright Statement..................................10 68 File name and Expiration..................................10 70 1. Introduction 72 ECML Version 2.0 will describe the syntax of a class of data objects 73 called Payment Processing Objects. This will involve the development 74 of a hierarchically organized set of data elements and an XML syntax 75 for payment transaction information for both electronic wallets and 76 Business to Business (B2B) payment types such as credit card, 77 electronic check, line of credit, ACH (Automated Clearing House,) 78 Mobile Phone Payments, and PDA Payments. 80 This document lists the design principles, scope, and requirements 81 over three things: (1) the scope of work available to the WG, (2) the 82 ECML version 2 specification, and (3) applications that implement the 83 specification. It includes requirements as they relate to the payment 84 element syntax, data model, format, implementation, and external 85 requirements. Those things that are required are designated as 86 "must", those things that are optional are designated by "may", those 87 things that are optional but recommended are designated as "should". 89 1.1 Relationship to Other Standards 91 The set of fields documented herein was started by the ECML Alliance 92 [ECML] which developed the North American / HTML form field oriented 93 Versions 1 and 1.1 of ECML [RFC 2706, 3106]. Control and development 94 of future versions of the standard has been transferred to the IETF. 96 The ECML Version 1 fields were initially derived from and are 97 consistent with the W3C P3P base data schema [P3P BASE]. Version 2 98 extends the fields provided to encompass [P3P ECOM] and selected 99 additional fields from [ISO 8583], [JCM], or other sources. 101 ECML Version 2.0 is not a replacement or alternative to TLS [RFC 102 2246], SET [SET], EMV [EMV], XML [XML], or IOTP [RFC 2801]. These are 103 important standards that provide functionality such as 104 confidentiality, non-repudiatable transactions, automatable payment 105 scheme selection, and smart card support. 107 2. Design Principles and Scope 109 1. The specification must describe the fields necessary to process a 110 payment between a consumer and merchant or between two businesses, 111 describing the XML syntax and content in particular. 113 2. Keep the addition of fields beyond those in ECML v1.1 [RFC 3106] 114 to a minimum. 116 3. Maintain all existing functionality from ECML v1.1. In essence, 117 ECML v2 should be a superset of ECML v1.1. 119 4. Increase the flexibility of the standard to include other forms of 120 payments. These include ACH, Mobile Phone, PDA, Purchasing Card 121 and electronic check. See [P3P ECOM, JCM], etc. 123 5. Allow for use of a common and uniform DTD with back-end payment 124 systems such as Enterprise Resource Provision (ERP), Card Line 125 Item Detail (LID) Level II & Level III, etc. 127 6. Allow for use of the standard with Business to Business (B2B) 128 payment vehicles, such as B2B Wallets, Marketplaces, etc. 130 7. Create a usage/implementation guide section of the specification 131 to cover additional use cases for functionality included. 133 8. ECML version 2 may include the concept of an offer. 135 9. ECML version 2 should be developed as part of the broader Web 136 design philosophy of decentralization, URIs, Web data, modularity 137 /layering / extensibility, and assertions as statements about 138 statements. [Berners-Lee, WebData, XML, XML Name] In this context, 139 this standard should take advantage of existing provider (and 140 infrastructure) primitives. 142 3. Requirements 144 ECML v2 must cover the data types and other requirements enumerated 145 in this section. It should provide for asserting and querying 146 relavent element values. 148 3.1 Payment Processing Elements 150 1. Cost 151 2. Receipt 152 3. Currency 153 4. Card 154 5. Payment 155 6. Bank/Telco 157 3.2 Payment Processing Types 159 1. All current Processing types for ECML 1.1 [RFC 3106]. 160 2. Automated Clearing hosue [ACH] 161 3. Electronic check [eCheck] 162 4. Mobile phone payments 163 5. PDA payments 165 3.3 XML Data Model and Syntax 167 1. A well-formed DTD and possibly schema need to be developed to 168 include new fields in this standard. 170 2. A W3C Note may be drafted to document changes from [W3C ECOM]. 172 3.4 Implementation 174 1. The ECML version 2 specification should meet the requirements 175 of the following applications: 176 a. Internet Open Trading Protocol v1.0 [IOTP] 178 b. Check against representative ACH, electronic check, and Mobile 179 Phone payment setup. 181 2. Test all XML DTDs, schemas and XML examples inculded the 182 specification to insure that they are well-formed XML. 184 3. Compare completeness against (in accordance with standard's 185 goals:) 186 1. ECML v1.1 [RFC 3106] 187 2. Using P3P for E-Commerce [P3P NOTE] 188 3. Financial transaction card originated messages [ISO 8583] 189 4. Java Commerce Messages [JCM] 190 5. cXML 191 6. ebXML 192 7. BizTalk 194 3.5 Detailed Requests 196 The following are specific comments received on claimed deficiencies 197 in ECML v1.1 and should all be considered for possible inclusion in 198 ECML v2. 200 1. Increase Last Name field minimum required support to at least 201 22 characters. 203 2. Improved Internationalization support. 205 3. Longer minimum supported telephone number and email fields. 207 4. Provide a "translation field" which would specify a mapping 208 between existing fields and ECML specified fields. The 209 addition of such a field in ECML v2 (which would normally be 210 hidden when presented in HTML) would permit ECML support with 211 no change to existing fields or code. ECML code could fill in 212 existing fields based on the ECML field they map to. 214 4. Security Considerations 216 Many ECML fields contain sensitive private information. ECML is 217 dependent upon 219 - the security of the transmission infrastructure used to send such 220 private inforamtion and 222 - the security of applications which store or release such sensitive 223 information. 225 ECML need not add any security mechansims to this infrastructure or 226 these applications. The ECML v2 specification must include adequate 227 warnings and suggested courses of action to protect this information. 229 References 231 [ACH] - Automated Clearning House 233 [Berners-Lee] - "Axioms of Web Architecture: URIs", 234 , "Web Architecture from 235 50,000 feet", 237 [eCheck] - Electronic Check 239 [ECML] - Electronic Commerce Modeling Language, The ECML Alliance, 240 . 242 [HTML] - "HTML 3.2 Reference Specification", Hyper Text Markup 243 Language, , D. Raggett, January 244 1997. 246 [ISO 8583] - "Financial transaction card originated messages -- 247 Interchange message specifications", International Standards 248 Organization, 1993. 250 [JCM] - "Java Commerce Messages", Sun Microsystems, IBM, April 1998. 252 [EMV] - The EuroCard, MasterCard, Visa chip card protocol standard. 253 255 [RFC 2026] - "The Internet Standards Process -- Revision 3", S. 256 Bradner, October 1996. 258 [RFC 2246] - "The TLS Protocol: Version 1.0", T. Dierks, C. Allen. 259 January 1999. 261 [RFC 2706] - "ECML v1: Field Names for E-Commerce", D. Eastlake, T. 262 Goldstein, October 1999. 264 [RFC 2801] - "Internet Open Trading Protocol - IOTP Version 1.0", D. 265 Burdett, April 2000. 267 [RFC 3106] - "ECML v1.1: Field Names for E-Commerce", D. Eastlake, T. 268 Goldstein, April 2001. 270 [P3P BASE] - "The Platform for Privacy Preferences 1.0 (P3P1.0) 271 Specification", L. Cranor, M. Langheinrich, M. Marchiori, M. 272 Presler-Marshall, J. Reagle, December 2000, 273 . 275 [P3P ECOM] - "Using P3P for E-Commerce", J. Coco, S. Klien, D. 276 Schutzer, S. Yen, A. Slater, November 1999, 277 . 279 [SET] - "Secure Electronic Transaction", 280 . 282 [WebData] - "Web Architecture: Describing and Exchanging Data", 283 285 [XML] - "Extensible Markup Language (XML) 1.0 (Second Edition)", 286 , T. Bray, J. Paoli, C. M. 287 Sperberg-McQueen. 289 [XML Name] - "Namespaces in XML", Tim Bray, Dave Hollander, Andrew 290 Layman, 14 January 1999. 292 Authors Addresses 294 Jon W. Parsons 295 SeraNova 296 10210 N. 25th Avenue 297 Phoenix, AZ 85012 299 Phone: +1-602-674-1853 300 EMail: jon.parsons@seranova.com 302 David Shepherd 303 IBM 304 Secure Payments Systems 305 P. O. Box 12195 306 3039 Cornwallis Road 307 Research Triangle Park, NC 27709-2195 USA 309 Phone: +1-919-254-5194 310 Email: dshepher@us.ibm.com 312 Donald E. Eastlake 3rd 313 Motorola 314 155 Beaver Street 315 Milford, MA 01757 USA 317 Phone: +1-508-261-5434 (w) 318 +1-508-634-2066 (h) 319 Email: Donald.Eastlake@motorola.com 321 Full Copyright Statement 323 Copyright (c) 2001 The Internet Society, All Rights Reserved. 325 This document and translations of it may be copied and furnished to 326 others, and derivative works that comment on or otherwise explain it 327 or assist in its implementation may be prepared, copied, published 328 and distributed, in whole or in part, without restriction of any 329 kind, provided that the above copyright notice and this paragraph are 330 included on all such copies and derivative works. However, this 331 document itself may not be modified in any way, such as by removing 332 the copyright notice or references to the Internet Society or other 333 Internet organizations, except as needed for the purpose of 334 developing Internet standards in which case the procedures for 335 copyrights defined in the Internet Standards process must be 336 followed, or as required to translate it into languages other than 337 English. 339 The limited permissions granted above are perpetual and will not be 340 revoked by the Internet Society or its successors or assigns. 342 This document and the information contained herein is provided on an 343 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 344 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 345 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 346 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 347 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 349 File name and Expiration 351 This file is draft-ietf-trade-ecml2-req-04.txt. 353 It expires January 2002.