idnits 2.17.1 draft-ietf-trade-ecmlv2-req-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 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 2 instances of lines with control characters in the document. 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 (November 2000) is 8563 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 72, but not defined == Missing Reference: 'LID' is mentioned on line 126, but not defined == Missing Reference: 'Berners-Lee' is mentioned on line 142, but not defined == Missing Reference: 'WebData' is mentioned on line 142, but not defined == Missing Reference: 'XFA' is mentioned on line 179, but not defined == Missing Reference: 'XFDL' is mentioned on line 179, but not defined == Unused Reference: 'HTML' is defined on line 198, but no explicit reference was found in the text == Unused Reference: 'IANA' is defined on line 201, but no explicit reference was found in the text == Unused Reference: 'ISO 3166' is defined on line 205, but no explicit reference was found in the text == Unused Reference: 'ISO 7812' is defined on line 208, but no explicit reference was found in the text == Unused Reference: 'RFC 1766' is defined on line 211, but no explicit reference was found in the text == Unused Reference: 'RFC 2026' is defined on line 214, but no explicit reference was found in the text == Unused Reference: 'RFC 2246' is defined on line 217, but no explicit reference was found in the text == Unused Reference: 'RFC 2411' is defined on line 220, but no explicit reference was found in the text == Unused Reference: 'RFC 2706' is defined on line 223, but no explicit reference was found in the text == Unused Reference: 'RFC 3XXX' is defined on line 226, but no explicit reference was found in the text == Unused Reference: 'P3P' is defined on line 229, but no explicit reference was found in the text -- 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' ** 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC 3XXX' -- Possible downref: Non-RFC (?) normative reference: ref. 'P3P' ** Downref: Normative reference to an Informational RFC: RFC 2801 (ref. 'IOTP') -- Possible downref: Non-RFC (?) normative reference: ref. 'SET' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' Summary: 11 errors (**), 0 flaws (~~), 18 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT J. Parsons/D. Shepherd 2 ECML/IETF 3 Expires: May 2001 November 2000 5 Electronic Commerce Modeling Language (ECML) 6 Version 2 Requirements 7 9 Status of this Memo 11 Distribution of this memo is unlimited. Comments should be sent to 12 the TRADE WG mailing list or the 13 authors. 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) 2000, The Internet Society. All Rights Reserved. 36 Abstract 38 This document lists the design principles, scope, and requirements 39 for the Electronic Commerce Modeling Language (ECML) version 2 40 specification. It includes requirements as they relate to the html 41 and XML syntax, data model, format, payment processing, and external 42 requirements. 44 Table of Contents 46 Status of this Memo........................................... 1 47 Abstact....................................................... 1 49 1. Introduction .............................................. 3 50 1.1 The ECML Alliance......................................... 3 51 1.2 Relationship to Other Standards........................... 3 53 2. Design Principles and Scope ............................... 4 55 3. Requirements .............................................. 5 56 3.1. Payment Processing Elements ............................. 5 57 3.2. Payment Processing Types ................................ 5 58 3.3. XML Data Model and Syntax ............................... 5 59 3.4 Implementation .......................................... 5 60 4. Security Considerations ................................... 6 62 References ................................................... 6 63 Acknowledgements ............................................. 7 64 Author's Address ............................................. 7 65 Full Copyright Statement ..................................... 7 67 1. Introduction 69 ECML Version 2.0 will describe the syntax of a class of data objects 70 called Payment Processing Objects. This will involve the development 71 of html tags and an XML syntax for payment transactions for both 72 electronic wallets and Business to Business [B2B] payment types such 73 as credit card, check, line of credit, ACH (Automated Clearing 74 House,) Mobile Phone Payments and PDA Payments. 76 This document lists the design principles, scope, and requirements 77 over three things: (1) the scope of work available to the WG, (2) the 78 ECML version 2 specification, and (3) applications that implement the 79 specification. It includes requirements as they relate to the 80 payment element syntax, data model, format, implementation, and 81 external requirements and coordination. Those things that are 82 required are designated as "must", those things that are optional are 83 designated by "may", those things that are optional but recommended 84 are designated as "should". 86 1.1 The ECML Alliance 88 The set of fields documented herein was started by the ECML 89 Alliance (www.ecml.org.) 91 1.2 Relationship to Other Standards 93 The ECML fields were initially derived from and are consistent with 94 the W3C P3P base data schema at 96 . 98 ECML Version 2.0 is not a replacement or alternative to SSL/TLS [RFC 99 2246], SET [SET], XML [XML], or IOTP [IOTP]. These are important 100 standards that provide functionality such as non-repudiatable 101 transactions, automatable payment scheme selection, and smart card 102 support. 104 ECML may be used with any payment mechanism. Information of the 105 use of the ECML fields with W3C P3P protocol is available at 106 . 108 2. Design Principles and Scope 110 1. The specification must describe the fields necessary to process an 111 html or XML payment, and describe the html or XML content in 112 particular. The html tags or XML syntax used to represent a 113 payment (using any payment method) is described as ECML version 2. 115 2. Keep the addition of fields from the previous specification [ECML 116 v1.1] to a minimum. 118 3. Maintain all existing functionality from ECML v1.1. 120 4. Increase the flexibility of the standard to include other forms of 121 payments. These are: ACH, Mobile Phone, PDA, Line of Credit, 122 Purchasing Card and eCheck. 124 5. Allow for use of the common and uniform DTD with back-end payment 125 systems such as Enterprise Resource Provision [ERP,] Card Line 126 Item Detail [LID] Level II & Level III, etc. 128 6. Allow for use of the standard with B2B payment vehicles, such as 129 B2B Wallets, Marketplaces, etc. 131 7. Fully test the specification to insure that it is well-formed XML. 133 8. Create an implementation guide to cover additional use cases for 134 functionality included in this document. 136 9. Consider for inclusion initial fields listed in "Using P3P for E- 137 Commerce," a W3C note dtd 29 Nov 1999. 139 10.ECML version 2 should be developed as part of the broader Web 140 design philosophy of decentralization, URIs, Web data, modularity 141 /layering / extensibility, and assertions as statements about 142 statements. [Berners-Lee, WebData] In this context, this standard 143 should take advantage of existing provider (and infrastructure) 144 primitives. 146 3. Requirements 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 160 2. ACH 161 3. eCheck 162 4. Line Of Credit (LOC) 163 5. Mobile phone payments 164 6. PDA payments 166 3.3 XML Data Model and Syntax 168 1. A well-formed DTD needs to be developed to include new fields in 169 this standard. 171 2. W3C Schema note may be drafted to document changes to the schema. 173 3.4 Implementation 175 1. The ECML version 2 specification should meet the requirements of 176 the following applications: 177 1. Internet Open Trading Protocol v1.0 [IOTP] 178 2. Financial Services Mark Up Language v2.0. 179 3. At least one forms application [XFA, XFDL] 180 2. Check against representative LOC, ACH, eCheck, Mobile Phone and 181 PDA processes. 182 3. Compare against (in accordance with standard's goals:) 183 1. Biztalk 184 2. cXML 185 3. EBXML 186 4. ISO 8583 188 4. Security Considerations 190 ECML is dependent upon the security of the infrastructure of 191 transmission providers that use the standard format. ECML does not 192 add any security to this infrastructure. 194 References 196 [eCheck] - 198 [HTML] - HTML 3.2 Reference Specification , D. Raggett, January 1997. 201 [IANA] - Internet Assigned Numbers Authority, Official Names for 202 Character Sets, ed. Keld Simonsen et al. . 205 [ISO 3166] - Codes for the representation of names of countries, 206 208 [ISO 7812] - "Identification card - Identification of issuers - Part 209 1: Numbering system" 211 [RFC 1766] - "Tags for the Identification of Languages", H. 212 Alvestrand. March 1995. 214 [RFC 2026] - "The Internet Standards Process -- Revision 3", S. 215 Bradner, October 1996. 217 [RFC 2246] - "The TLS Protocol: Version 1.0", T. Dierks, C. Allen. 218 January 1999. 220 [RFC 2411] - "IP Security: Document Roadmap", R. Thayer, N. 221 Doraswany, R. Glenn. November 1998. 223 [RFC 2706] - "ECML v1: Field Names for E-Commerce", D. Eastlake, T. 224 Goldstein, October 1999. 226 [RFC 3XXX] - "ECML v1.1: Field Names for E-Commerce", D. Eastlake, 227 T. Goldstein, xxx 2000 229 [P3P] - "Using P3P for E-Commerce", J. Coco, S. Klien, D. Schutzer, 230 S. Yen, A. Slater, November 1999 232 [IOTP] - [RFC 2801], D. Burdett. 234 [SET] - Secure Electronic Transaction, 235 237 [XML] - Extensible Markup Language (XML) 1.0 (Second Edition), 238 , T. Bray, J. Paoli, C. 239 M. Sperberg-McQueen 241 Acknowledgements 243 Many members of the ECML Alliance ECML V2 Working Group contributed 244 to this draft. 246 Author's Address 248 Jon W Parsons 249 American Express Corporation 250 Establishment Services/Network Development 251 3200 E. Camelback Road 75-03-02 252 Phoenix AZ 85016 254 Phone: 1.602.766.7731 255 EMail: jon.w.parsons@aexp.com 257 Dave Sheppherd 258 IBM 259 Secure Payments Systems 260 xxxx 261 Raliegh, NC 263 Phone: 1.919.254.5194 264 Email: dshepher@us.ibm.com 266 Full Copyright Statement 268 Copyright (c) 2000 The Internet Society & W3C (MIT, INRIA, Keio), All 269 Rights Reserved. 271 This document and translations of it may be copied and furnished to 272 others, and derivative works that comment on or otherwise explain it 273 or assist in its implementation may be prepared, copied, published 274 and distributed, in whole or in part, without restriction of any 275 kind, provided that the above copyright notice and this paragraph are 276 included on all such copies and derivative works. However, this 277 document itself may not be modified in any way, such as by removing 278 the copyright notice or references to the Internet Society or other 279 Internet organizations, except as needed for the purpose of 280 developing Internet standards in which case the procedures for 281 copyrights defined in the Internet Standards process must be 282 followed, or as required to translate it into languages other than 283 English. 285 The limited permissions granted above are perpetual and will not be 286 revoked by the Internet Society or its successors or assigns. 288 This document and the information contained herein is provided on an 289 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 290 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 291 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 292 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 293 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.