RFC 3505

Electronic Commerce Modeling Language (ECML): Version 2 Requirements

📅 published March 2003, from ietf

Electronic Commerce Modeling Language (ECML): Version 2 Requirements 🎀

okay bestie, lets get into this RFC 3505 🧚 it's the requirements doc for ECML v2, and it's giving "here's the wishlist before we build the thing." 💅

RFC 3505, the Network Working Group doc by Donald E. Eastlake 3rd from Motorola. It's Informational (not a standard, just info for the community 🦋) and it's dated March 2003. The header doesn't list anything it obsoletes or updates, so this one stands on its own ✨

Status of This Memo ✨

this memo gives info to the Internet community. it does NOT specify an Internet standard of any kind 🙈 distribution is unlimited, so go wild 🌈

Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract 💜

this doc lists the design principles, scope, and requirements for the Electronic Commerce Modeling Language (ECML) version 2 spec. it covers requirements for the Extensible Markup Language (XML) syntax, the data model, the format, and payment processing. literally the whole vibe ✨

Table of Contents 🍓

   1. Introduction.................................................... 2
      1.1 Relationship to Other Standards............................. 2
   2. Design Principles and Scope..................................... 2
   3. Requirements.................................................... 3
      3.1 Payment Processing Elements................................. 3
      3.2 Payment Processing Types.................................... 3
      3.3 XML Data Model and Syntax................................... 4
      3.4 Implementation.............................................. 4
      3.5 Detailed Requests........................................... 4
   4. Security Considerations......................................... 5
   5. References...................................................... 5
   6. Acknowledgments................................................. 6
   7. Authors' Addresses.............................................. 7
   8. Full Copyright Statement........................................ 8

1. Introduction 🌸

okay so ECML Version 2.0 is going to describe the syntax of a class of data objects called Payment Processing Objects 💖 that means a hierarchy of data elements and an XML syntax for payment transaction info, for both electronic wallets and Business to Business (B2B) payment types. the list is giving main character energy: credit card, electronic check, line of credit, ACH (Automated Clearing House,), Mobile Phone Payments, and PDA Payments 💅

this doc lays out the design principles, scope, and requirements across three things: (1) the scope of work available to the WG, (2) the ECML version 2 spec, and (3) apps that implement the spec. it covers requirements for the payment element syntax, the data model, the format, the implementation, and external requirements. the way it marks levels of requirement is so clear 🔥 things that are required are designated as "MUST", things that are optional are designated by "MAY", and things that are optional but recommended are designated as "SHOULD" ✨

1.1 Relationship to Other Standards 🦋

ok the set of fields in here started with the ECML Alliance [ECML], who made the North American / HTML form field oriented Versions 1 and 1.1 of ECML [RFC 3106]. control and development of future versions has since moved over to the IETF 🫶

the ECML Version 1 fields were initially derived from, and are consistent with, the W3C P3P base data schema [P3P BASE]. Version 2 extends the fields to cover [P3P ECOM] and some extra fields from [ISO 8583], [JCM], or other sources 🌈

ngl this part is important: ECML Version 2.0 is NOT a replacement or alternative to TLS [RFC 2246], SET [SET], EMV [EMV], XML [XML], or IOTP [RFC 2801] 🙈 those are important standards that handle stuff like confidentiality, non-repudiated transactions, automatic payment scheme selection, and smart card support. ECML is the payment-data layer, not the whole security stack 💜

2. Design Principles and Scope 🧚

the design goals are literally giving planning 💅

  1. the spec MUST describe the fields needed to process a payment between a consumer and a merchant, or between two businesses, with a focus on the XML syntax and content.
  2. keep the added fields beyond the ECML v1.1 [RFC 3106] ones to a minimum 🫶
  3. keep ALL existing functionality from ECML v1.1. in essence, ECML v2 should be a superset of ECML v1.1 💖
  4. make the standard more flexible so it can handle other forms of payment. these include ACH, Mobile Phone, PDA, Purchasing Card, and electronic check. see [P3P ECOM, JCM], etc. 🦋
  5. allow for a common and uniform DTD with back-end payment systems like Enterprise Resource Provision (ERP), Card Line Item Detail (LID) Level II & Level III, etc. ✨
  6. allow use with Business to Business (B2B) payment vehicles, like B2B Wallets, Marketplaces, etc. 👑
  7. create a usage / implementation guide section to cover extra use cases for the functionality included 🎀
  8. ECML version 2 MAY include the concept of an offer 🍓
  9. ECML version 2 SHOULD be developed as part of the broader Web design philosophy: decentralization, URIs, Web data, modularity / layering / extensibility, and assertions as statements about statements. [Berners-Lee, WebData, XML, XML Name] in that context, this standard SHOULD take advantage of existing provider (and infrastructure) primitives 🌸

3. Requirements 💜

ECML v2 MUST cover the data types and other requirements listed in this section. it SHOULD also provide for asserting and querying relevant element values. the checklist starts now 🔥

3.1 Payment Processing Elements 💅

  1. Cost
  2. Receipt
  3. Currency
  4. Card
  5. Payment
  6. Bank/Telco

3.2 Payment Processing Types ✨

  1. All current Processing types for ECML 1.1 [RFC 3106].
  2. Automated Clearing house [ACH]
  3. Electronic check [eCheck]
  4. Mobile phone payments
  5. PDA payments

3.3 XML Data Model and Syntax 🧚

  1. a well-formed DTD, and possibly a schema, needs to be developed to include the new fields in this standard 🎀
  2. a W3C Note MAY be drafted to document changes from [W3C ECOM] 🦋

3.4 Implementation 🌈

  1. the ECML version 2 spec SHOULD meet the requirements of these applications:
    • a. Internet Open Trading Protocol v1.0 [IOTP]
    • b. check against representative ACH, electronic check, and Mobile Phone payment setup
  2. test all XML DTDs, schemas, and XML examples included in the spec to insure that they are well-formed XML 💖
  3. compare completeness against (in accordance with the standard's goals:)
    1. ECML v1.1 [RFC 3106]
    2. Using P3P for E-Commerce [P3P NOTE]
    3. Financial transaction card originated messages [ISO 8583]
    4. ebXML

3.5 Detailed Requests 🍓

the following are specific comments received on claimed deficiencies in ECML v1.1, and they all SHOULD be considered for possible inclusion in ECML v2 👑

  1. increase the Last Name field minimum required support to at least 22 characters 💅
  2. improved internationalization support 🌍
  3. longer minimum supported telephone number and email fields 📞
  4. provide a "translation field" that specifies a mapping between existing fields and ECML specified fields. such a field in ECML v2 (normally hidden when presented in HTML) would let ECML work with no change to existing fields or code. ECML code could fill in existing fields based on the ECML field they map to. this one is genuinely clever 🧚✨

4. Security Considerations 🔥

⚠️ this section is serious, bestie. many ECML fields hold sensitive private info, so the security stuff is not optional 💀

many ECML fields contain sensitive private information. ECML depends on:

  • the security of the transmission infrastructure used to send such private information
  • the security of the applications that store or release such sensitive information

ECML need not add any security mechanisms to this infrastructure or these applications. however, the ECML v2 specification MUST include adequate warnings and suggested courses of action to protect this information. protect the info, periodt 🛡️💜

5. References 🦋

the full reference list, copied exactly so nothing gets lost 🫶

   [ACH]         Automated Clearing House <http://www.nacha.org>

   [Berners-Lee] "Axioms of Web Architecture: URIs",
                 <http://www.w3.org/DesignIssues/Axioms.html>, "Web
                 Architecture from 50,000 feet",
                 <http://www.w3.org/DesignIssues/Architecture.html>

   [eCheck]      Electronic Check <http://www.echeck.org>

   [ECML]        Electronic Commerce Modeling Language, The ECML
                 Alliance, <http://www.oasis-open.org/cover/ecml.html>.

   [HTML]        "HTML 3.2 Reference Specification", Hyper Text Markup
                 Language, <http://www.w3.org/TR/REC-html32.html>, D.
                 Raggett, January 1997.

   [ISO 8583]    "Financial transaction card originated messages --
                 Interchange message specifications", International
                 Standards Organization, 1993.

   [JCM]         "Java Commerce Messages", Sun Microsystems, IBM, April
                 1998.

   [EMV]         The EuroCard, MasterCard, Visa chip card protocol
                 standard.  <http://www.emvco.org>

   [RFC 2026]    Bradner, S., "The Internet Standards Process --
                 Revision 3", BCP 9, RFC 2026, October 1996.

   [RFC 2246]    Dierks, T. and C. Allen, "The TLS Protocol: Version
                 1.0", RFC 2246, January 1999.

   [RFC 2801]    "Internet Open Trading Protocol - IOTP Version 1.0", D.
                 Burdett, April 2000.

   [RFC 3106]    Eastlake, D. and T. Goldstein, "ECML v1.1: Field Names
                 for E-Commerce", RFC 3106, April 2001.

   [P3P BASE]    "The Platform for Privacy Preferences 1.0 (P3P1.0)
                 Specification", L. Cranor, M. Langheinrich, M.
                 Marchiori, M. Presler-Marshall, J. Reagle, December
                 2000, <http://www.w3.org/TR/WD-P3P/basedata.html>.

   [P3P ECOM]    "Using P3P for E-Commerce", J. Coco, S. Klein, D.
                 Schutzer, S. Yen, A. Slater, November 1999,
                 <http://www.w3.org/TR/P3P-for-ecommerce>.

   [SET]         "Secure Electronic Transaction",
                 <http://www.setco.org/set_specifications.html>.

   [WebData]     "Web Architecture: Describing and Exchanging Data",
                 <http://www.w3.org/1999/04/WebData>

   [XML]         "Extensible Markup Language (XML) 1.0 (Second
                 Edition)", <http://www.w3.org/TR/REC-xml>, T. Bray, J.
                 Paoli, C.  M.  Sperberg-McQueen.

   [XML Name]    "Namespaces in XML", Tim Bray, Dave Hollander, Andrew
                 Layman, 14 January 1999.
                 <http://www.w3.org/TR/REC-xml-names>

6. Acknowledgements 💖

Jon W. Parsons and David Shepherd contributed substantially to this document. thank you, queens 👑🫶

7. Authors' Addresses 🧚

   Donald E. Eastlake 3rd
   Motorola
   155 Beaver Street
   Milford, MA 01757 USA

   Phone:  +1-508-851-8280 (w)
           +1-508-634-2066 (h)
   EMail:  Donald.Eastlake@motorola.com

Copyright (C) The Internet Society (2003). All Rights Reserved. 🦋

Okay bestie, the legal stuff is important, so I'm keeping every bit of it. 💅 You're allowed to copy this document and share it with others, and you can even write derivative works that comment on or explain it, or help people implement it. You can publish and distribute those too, in whole or in part, with no restrictions at all. The one catch is that the copyright notice and this paragraph have to stay on every copy and every derivative work. 🫶

What you can't do is modify this document itself. That means no removing the copyright notice or the references to the Internet Society or other Internet organizations. There are two exceptions. The first is when you need it for developing Internet standards, in which case you have to follow the copyright procedures in the Internet Standards process. The second is when you need to translate it into a language other than English. 🌸

The permissions above are perpetual, meaning they will never be revoked by the Internet Society or its successors or assigns. Forever and ever. 💜

This document and the information in it are provided "AS IS". THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 😭

Acknowledgement 🌈

Funding for the RFC Editor function is currently provided by the Internet Society. 🎀 Thank you to the Internet Society for keeping the RFC Editor running. Honestly, we'd be lost without them! 👑

📦 where this page comes from