doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc3505.txt b/doc/rfc/rfc3505.txt
new file mode 100644
index 0000000..cdc26fc
--- /dev/null
+++ b/doc/rfc/rfc3505.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                        D. Eastlake
+Request for Comments: 3505                                      Motorola
+Category: Informational                                       March 2003
+
+
+             Electronic Commerce Modeling Language (ECML):
+                         Version 2 Requirements
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This document lists the design principles, scope, and requirements
+   for the Electronic Commerce Modeling Language (ECML) version 2
+   specification.  It includes requirements as they relate to Extensible
+   Markup Language (XML) syntax, data model, format, and payment
+   processing.
+
+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
+
+
+
+
+
+
+
+
+
+Eastlake                     Informational                      [Page 1]
+
+RFC 3505                 ECML: v2 Requirements                March 2003
+
+
+1. Introduction
+
+   ECML Version 2.0 will describe the syntax of a class of data objects
+   called Payment Processing Objects.  This will involve the development
+   of a hierarchically organized set of data elements and an XML syntax
+   for payment transaction information for both electronic wallets and
+   Business to Business (B2B) payment types such as credit card,
+   electronic check, line of credit, ACH (Automated Clearing House,)
+   Mobile Phone Payments, and PDA Payments.
+
+   This document lists the design principles, scope, and requirements
+   over three things: (1) the scope of work available to the WG, (2) the
+   ECML version 2 specification, and (3) applications that implement the
+   specification.  It includes requirements as they relate to the
+   payment element syntax, data model, format, implementation, and
+   external requirements.  Those things that are required are designated
+   as "must", those things that are optional are designated by "may",
+   those things that are optional but recommended are designated as
+   "should".
+
+1.1 Relationship to Other Standards
+
+   The set of fields documented herein was started by the ECML Alliance
+   [ECML] which developed the North American / HTML form field oriented
+   Versions 1 and 1.1 of ECML [RFC 3106].  Control and development of
+   future versions of the standard has been transferred 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 provided to encompass [P3P ECOM] and selected
+   additional fields from [ISO 8583], [JCM], or other sources.
+
+   ECML Version 2.0 is not a replacement or alternative to TLS [RFC
+   2246], SET [SET], EMV [EMV], XML [XML], or IOTP [RFC 2801].  These
+   are important standards that provide functionality such as
+   confidentiality, non-repudiated transactions, automatic payment
+   scheme selection, and smart card support.
+
+2. Design Principles and Scope
+
+   1. The specification must describe the fields necessary to process a
+      payment between a consumer and merchant or between two businesses,
+      describing the XML syntax and content in particular.
+
+   2. Keep the addition of fields beyond those in ECML v1.1 [RFC 3106]
+      to a minimum.
+
+
+
+
+
+Eastlake                     Informational                      [Page 2]
+
+RFC 3505                 ECML: v2 Requirements                March 2003
+
+
+   3. Maintain all existing functionality from ECML v1.1.  In essence,
+      ECML v2 should be a superset of ECML v1.1.
+
+   4. Increase the flexibility of the standard to include other forms of
+      payments.  These include ACH, Mobile Phone, PDA, Purchasing Card
+      and electronic check.  See [P3P ECOM, JCM], etc.
+
+   5. Allow for use of a common and uniform DTD with back-end payment
+      systems such as Enterprise Resource Provision (ERP), Card Line
+      Item Detail (LID) Level II & Level III, etc.
+
+   6. Allow for use of the standard with Business to Business (B2B)
+      payment vehicles, such as B2B Wallets, Marketplaces, etc.
+
+   7. Create a usage/implementation guide section of the specification
+      to cover additional use cases for 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 of decentralization, URIs, Web data, modularity
+      /layering / extensibility, and assertions as statements about
+      statements.  [Berners-Lee, WebData, XML, XML Name] In this
+      context, this standard should take advantage of existing provider
+      (and infrastructure) primitives.
+
+3. Requirements
+
+   ECML v2 must cover the data types and other requirements enumerated
+   in this section.  It should provide for asserting and querying
+   relevant element values.
+
+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
+
+
+
+Eastlake                     Informational                      [Page 3]
+
+RFC 3505                 ECML: v2 Requirements                March 2003
+
+
+3.3 XML Data Model and Syntax
+
+   1. A well-formed DTD and possibly schema need to be developed to
+      include 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 specification should meet the requirements of
+      the following 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 the
+      specification to insure that they are well-formed XML.
+
+   3. Compare completeness against (in accordance with 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 should all be considered for possible inclusion in
+   ECML v2.
+
+   1. Increase 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" which would specify a mapping
+      between existing fields and ECML specified fields.  The addition
+      of such a field in ECML v2 (which would normally be hidden when
+      presented in HTML) would permit ECML support with no change to
+      existing fields or code.  ECML code could fill in existing fields
+      based on the ECML field they map to.
+
+
+
+
+Eastlake                     Informational                      [Page 4]
+
+RFC 3505                 ECML: v2 Requirements                March 2003
+
+
+4. Security Considerations
+
+   Many ECML fields contain sensitive private information.  ECML is
+   dependent upon:
+
+   - the security of the transmission infrastructure used to send such
+     private information
+
+   - the security of applications which store or release such sensitive
+     information.
+
+   ECML need not add any security mechanisms to this infrastructure or
+   these applications.  The ECML v2 specification must include adequate
+   warnings and suggested courses of action to protect this information.
+
+5. References
+
+   [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.
+
+
+
+Eastlake                     Informational                      [Page 5]
+
+RFC 3505                 ECML: v2 Requirements                March 2003
+
+
+   [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                     Informational                      [Page 6]
+
+RFC 3505                 ECML: v2 Requirements                March 2003
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                     Informational                      [Page 7]
+
+RFC 3505                 ECML: v2 Requirements                March 2003
+
+
+8.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                     Informational                      [Page 8]
+