idnits 2.17.1 draft-ietf-trade-ecml2-req-01.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. 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 (March 2001) is 8441 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: 'B2B' is mentioned on line 75, but not defined == Missing Reference: 'ERP' is mentioned on line 122, but not defined == Missing Reference: 'LID' is mentioned on line 123, but not defined == Missing Reference: 'IOTP' is mentioned on line 175, but not defined == Missing Reference: 'P3P NOTE' is mentioned on line 184, but not defined == Unused Reference: 'HTML' is defined on line 229, but no explicit reference was found in the text == Unused Reference: 'RFC 2026' is defined on line 240, but no explicit reference was found in the text == Unused Reference: 'RFC 2246' is defined on line 243, but no explicit reference was found in the text == Unused Reference: 'RFC 2706' is defined on line 246, but no explicit reference was found in the text -- 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 -- 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: 8 errors (**), 0 flaws (~~), 11 warnings (==), 13 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 September 2001 March 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, payment processing, and external requirements. 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...............................4 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 62 References.................................................6 64 Authors Addresses..........................................8 66 Full Copyright Statement...................................9 67 File name and Expiration...................................9 69 1. Introduction 71 ECML Version 2.0 will describe the syntax of a class of data objects 72 called Payment Processing Objects. This will involve the development 73 a hierarchically organized set of data elements and an XML syntax for 74 payment transaction information for both electronic wallets and 75 Business to Business [B2B] payment types such as credit card, check, 76 line of credit, ACH (Automated Clearing House,) Mobile Phone 77 Payments, and PDA Payments. 79 This document lists the design principles, scope, and requirements 80 over three things: (1) the scope of work available to the WG, (2) the 81 ECML version 2 specification, and (3) applications that implement the 82 specification. It includes requirements as they relate to the payment 83 element syntax, data model, format, implementation, and external 84 requirements. Those things that are required are designated as 85 "must", those things that are optional are designated by "may", those 86 things that are optional but recommended are designated as "should". 88 1.1 Relationship to Other Standards 90 The set of fields documented herein was started by the ECML Alliance 91 [ECML] which developed the North American / HTML form field oriented 92 Version 1 of ECML [RFC 2706, v1.1]. Control and development of 93 future versions of the standard has been transferred to the IETF. 95 The ECML Version 1 fields were initially derived from and are 96 consistent with the W3C P3P base data schema [P3P BASE]. Version 2 97 extends the fields provided to encompass [P3P ECOM] and selected 98 additional fields from [ISO 8583], [JCM], or other sources. 100 ECML Version 2.0 is not a replacement or alternative to TLS [RFC 101 2246], SET [SET], EMV [EMV], XML [XML], or IOTP [RFC 2801]. These are 102 important standards that provide functionality such as 103 confidentiality, non-repudiatable transactions, automatable payment 104 scheme selection, and smart card support. 106 2. Design Principles and Scope 108 1. The specification must describe the fields necessary to process a 109 payment describing the XML syntax and content in particular. 111 2. Keep the addition of fields beyond those in ECML v1.1 [RFC v1.1] 112 to a minimum. 114 3. Maintain all existing functionality from ECML v1.1. In essence, 115 ECML v2 should be a superset of ECML v1.1. 117 4. Increase the flexibility of the standard to include other forms of 118 payments. These include ACH, Mobile Phone, PDA, Line of Credit, 119 Purchasing Card and eCheck. See [P3P ECOM, JCM], etc. 121 5. Allow for use of a common and uniform DTD with back-end payment 122 systems such as Enterprise Resource Provision [ERP], Card Line 123 Item Detail [LID] Level II & Level III, etc. 125 6. Allow for use of the standard with B2B payment vehicles, such as 126 B2B Wallets, Marketplaces, etc. 128 7. Test all XML DTDs and XML examples in the specification to insure 129 that they are well-formed XML. 131 8. Create an usage/implementation guide section of the specification 132 to cover additional use cases for functionality included. 134 9. ECML version 2 may include the concept of an offer. 136 10. ECML version 2 should be developed as part of the broader Web 137 design philosophy of decentralization, URIs, Web data, modularity 138 /layering / extensibility, and assertions as statements about 139 statements. [Berners-Lee, WebData] In this context, this standard 140 should take advantage of existing provider (and infrastructure) 141 primitives. 143 3. Requirements 145 3.1 Payment Processing Elements 147 1. Cost 148 2. Receipt 149 3. Currency 150 4. Card 151 5. Payment 152 6. Bank/Telco 154 3.2 Payment Processing Types 156 1. All current Processing types for ECML 1.1 157 2. ACH 158 3. eCheck 159 4. Line Of Credit (LOC) 160 5. Mobile phone payments 161 6. PDA payments 163 3.3 XML Data Model and Syntax 165 1. A well-formed DTD needs to be developed to include new fields 166 in this standard. 168 2. W3C Schema note may be drafted to document changes to the 169 schema. 171 3.4 Implementation 173 1. The ECML version 2 specification should meet the requirements 174 of the following applications: 175 1. Internet Open Trading Protocol v1.0 [IOTP] 176 2. Others ??? 178 2. Check against representative LOC, ACH, eCheck, Mobile Phone and 179 PDA processes. 181 3. Compare completeness against (in accordance with standard's 182 goals:) 183 1. [ECML v1.1] 184 2. [P3P NOTE] 185 3. [ISO 8583] 186 4. [JCM] 187 5. cXML 188 6. EBXML 189 7. BizTalk 191 3.5 Detailed Requests 193 The following are specific comments received on claimed deficiencies 194 in ECML v1.1 and should all be considered for possible inclusion in 195 ECML v2. 197 1. Increase Last Name field minimum required support to at least 198 22 characters. 200 2. Improved Internationalization support. 202 3. Longer minimum supported telephone number and email fields. 204 4. Provide a "translation field" which would specify a mapping 205 between existing fields and ECML specified fields. The 206 addition of such a field in ECML v2 (which would normally be 207 hidden when presented in HTML) would permit ECML support with 208 no change to existing fields or code. ECML code could fill in 209 existing fields based on the ECML field they map to. 211 4. Security Considerations 213 Some ECML fields contain sensitive private information. ECML is 214 dependent upon the security of the infrastructure of transmission 215 providers that use the standard format. ECML does not add any 216 security to this infrastructure. See the ECML v2 specification for 217 more detailed privacy and security considerations. 219 References 221 [Berners-Lee] - "Axioms of Web Architecture: URIs", 222 , "Web Architecture from 223 50,000 feet", 225 [eCheck] - 227 [ECML] - The ECML Alliance, . 229 [HTML] - "HTML 3.2 Reference Specification", 230 , D. Raggett, January 1997. 232 [ISO 8583] - "Financial transaction card originated messages -- 233 Interchange message specifications", International Standards 234 Organization, 1993. 236 [JCM] - "Java Commerce Messages", Sun Microsystems, IBM, April 1998. 238 [EMV] - 240 [RFC 2026] - "The Internet Standards Process -- Revision 3", S. 241 Bradner, October 1996. 243 [RFC 2246] - "The TLS Protocol: Version 1.0", T. Dierks, C. Allen. 244 January 1999. 246 [RFC 2706] - "ECML v1: Field Names for E-Commerce", D. Eastlake, T. 247 Goldstein, October 1999. 249 [RFC 2801] - "Internet Open Trading Protocol - IOTP Version 1.0", D. 251 Burdett, April 2000. 253 [RFC v1.1] - "ECML v1.1: Field Names for E-Commerce", D. Eastlake, T. 254 Goldstein, draft-eastlake-ecom-fields2-05.txt, in RFC Editor's queue 255 for publication as an non-WG Informational RFC. 257 [P3P BASE] - "The Platform for Privacy Preferences 1.0 (P3P1.0) 258 Specification", L. Cranor, M. Langheinrich, M. Marchiori, M. 259 Presler-Marshall, J. Reagle, December 2000, 260 . 262 [P3P ECOM] - "Using P3P for E-Commerce", J. Coco, S. Klien, D. 263 Schutzer, S. Yen, A. Slater, November 1999, 264 . 266 [SET] - "Secure Electronic Transaction", 267 . 269 [WebData] - "Web Architecture: Describing and Exchanging Data", 270 272 [XML] - "Extensible Markup Language (XML) 1.0 (Second Edition)", 273 , T. Bray, J. Paoli, C. M. 274 Sperberg-McQueen. 276 Authors Addresses 278 Jon W. Parsons 279 SeraNova 280 10210 N. 25th Avenue 281 Phoenix, AZ 85012 283 Phone: +1-602-674-1853 284 EMail: jon.parsons@seranova.com 286 David Shepherd 287 IBM 288 Secure Payments Systems 289 P. O. Box 12195 290 3039 Cornwallis Road 291 Research Triangle Park, NC 27709-2195 USA 293 Phone: +1-919-254-5194 294 Email: dshepher@us.ibm.com 296 Donald E. Eastlake 3rd 297 Motorola 298 155 Beaver Street 299 Milford, MA 01757 USA 301 Phone: +1-508-261-5434 (w) 302 +1-508-634-2066 (h) 303 Email: Donald.Eastlake@motorola.com 305 Full Copyright Statement 307 Copyright (c) 2001 The Internet Society, All Rights Reserved. 309 This document and translations of it may be copied and furnished to 310 others, and derivative works that comment on or otherwise explain it 311 or assist in its implementation may be prepared, copied, published 312 and distributed, in whole or in part, without restriction of any 313 kind, provided that the above copyright notice and this paragraph are 314 included on all such copies and derivative works. However, this 315 document itself may not be modified in any way, such as by removing 316 the copyright notice or references to the Internet Society or other 317 Internet organizations, except as needed for the purpose of 318 developing Internet standards in which case the procedures for 319 copyrights defined in the Internet Standards process must be 320 followed, or as required to translate it into languages other than 321 English. 323 The limited permissions granted above are perpetual and will not be 324 revoked by the Internet Society or its successors or assigns. 326 This document and the information contained herein is provided on an 327 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 328 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 329 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 330 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 331 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 333 File name and Expiration 335 This file is draft-ietf-trade-ecml2-req-01.txt. 337 It expires September 2001.