<xs:element ref="Postal"/>
<xs:element ref="Telecom"/>
<xs:element ref="Online"/>
</xs:choice>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="BillTo">
<xs:complexType mixed="true">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="Postal"/>
<xs:element ref="Telecom"/>
<xs:element ref="Online"/>
</xs:choice>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="ReceiptTo">
<xs:complexType mixed="true">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="Postal"/>
<xs:element ref="Telecom"/>
<xs:element ref="Online"/>
</xs:choice>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="Postal">
<xs:complexType mixed="true">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="Name"/>
<xs:element ref="Company"/>
<xs:element ref="Street"/>
<xs:element ref="City"/>
<xs:element ref="StateProv"/>
</xs:choice>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
<xs:attribute name="PostalCode" type="xs:NMTOKEN"
use="optional"/>
<xs:attribute name="CountryCode" type="xs:NMTOKEN"
use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="Telecom">
<xs:complexType mixed="true">
<xs:sequence maxOccurs="unbounded">
<xs:element name="Phone">
<xs:complexType>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
<xs:attribute name="Number"/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute ref="Mode" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="Online">
<xs:complexType mixed="true">
<xs:sequence maxOccurs="unbounded">
<xs:element name="Email">
<xs:complexType>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
<xs:attribute name="Address"/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute ref="Mode" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="Payment">
<xs:complexType>
<xs:sequence>
<xs:element name="Card">
<xs:complexType>
<xs:sequence>
<xs:element ref="ExpDate"/>
<xs:element ref="ValidDate" minOccurs="0"/>
</xs:sequence>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
<xs:attribute name="Name" use="optional"/>
<xs:attribute name="Type" type="xs:NMTOKEN"
use="optional"/>
<xs:attribute name="Number" type="xs:decimal"/>
<xs:attribute name="Protocols" type="xs:NMTOKENS"
use="optional"/>
<xs:attribute name="Verification"
type="xs:NMTOKEN" use="optional"/>
<xs:attribute name="Issuer" type="xs:NMTOKEN"
use="optional"/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute ref="Mode" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="Loyalty">
<xs:complexType>
<xs:sequence>
<xs:element ref="ExpDate"/>
<xs:element ref="ValidDate" minOccurs="0"/>
</xs:sequence>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
<xs:attribute name="Name" use="optional"/>
<xs:attribute name="Type" type="xs:NMTOKEN"
use="optional"/>
<xs:attribute name="Number" type="xs:NMTOKEN"/>
<xs:attribute name="Verification" type="xs:NMTOKEN"
use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="ExpDate">
<xs:complexType>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
<xs:attribute name="Day" type="xs:positiveInteger"/>
<xs:attribute name="Month" type="xs:positiveInteger"/>
<xs:attribute name="Year" type="xs:positiveInteger"/>
</xs:complexType>
</xs:element>
<xs:element name="ValidDate">
<xs:complexType>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
<xs:attribute name="Day" type="xs:positiveInteger"/>
<xs:attribute name="Month" type="xs:positiveInteger"/>
<xs:attribute name="Year" type="xs:positiveInteger"/>
</xs:complexType>
</xs:element>
<xs:element name="User">
<xs:complexType mixed="true">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="UserID"/>
<xs:element ref="Password"/>
</xs:choice>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
<xs:attribute name="CertificateURL" type="xs:anyURI"
use="optional"/>
<xs:attribute name="DataCountry" type="xs:NMTOKEN"
use="optional"/>
<xs:attribute name="DataLanguage" type="xs:language"
use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="Transaction">
<xs:complexType mixed="true">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="Id"/>
<xs:element ref="Code"/>
<xs:element ref="Date"/>
<xs:element ref="Data"/>
<xs:element ref="Inquiry"/>
<xs:element ref="Signature"/>
</xs:choice>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute name="Currency" type="xs:NMTOKEN"
use="optional"/>
<xs:attribute name="Type" type="xs:NMTOKEN"
use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="Date">
<xs:complexType>
<xs:sequence>
<xs:element ref="Effective" minOccurs="0"/>
<xs:element ref="Settle" minOccurs="0"/>
<xs:element ref="Capture" minOccurs="0"/>
</xs:sequence>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="Data">
<xs:complexType mixed="true">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="Trace"/>
<xs:element ref="PrivateUse"/>
<xs:element ref="Response"/>
<xs:element ref="AAV"/>
<xs:element ref="Track1"/>
<xs:element ref="Track2"/>
</xs:choice>
<xs:attribute ref="Mode" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="Merchant">
<xs:complexType>
<xs:sequence>
<xs:element name="Terminal">
<xs:complexType>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
<xs:attribute name="Data" use="optional"/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="AAV" type="EcomSimpleText"/>
<xs:element name="Capture">
<xs:complexType>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
<xs:attribute name="Day" type="xs:NMTOKEN"/>
<xs:attribute name="Month" type="xs:NMTOKEN"/>
<xs:attribute name="Year" type="xs:NMTOKEN"/>
</xs:complexType>
</xs:element>
<xs:element name="City" type="EcomSimpleText"/>
<xs:element name="Code">
<xs:complexType>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute name="Processing" use="optional"/>
<xs:attribute name="Approval" type="xs:NMTOKEN"
use="optional"/>
<xs:attribute name="Retrieval" type="xs:NMTOKEN"
use="optional"/>
<xs:attribute name="Action" type="xs:NMTOKEN"
use="optional"/>
<xs:attribute name="Reason" type="xs:NMTOKEN"
use="optional"/>
<xs:attribute name="POS" type="xs:NMTOKEN"
use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="Company" type="EcomSimpleText"/>
<xs:element name="Effective">
<xs:complexType>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
<xs:attribute name="Day" type="xs:NMTOKEN"/>
<xs:attribute name="Month" type="xs:NMTOKEN"/>
<xs:attribute name="Year" type="xs:NMTOKEN"/>
</xs:complexType>
</xs:element>
<xs:element name="Id">
<xs:complexType>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
<xs:attribute name="CID" type="xs:NMTOKEN"
use="optional"/>
<xs:attribute name="Reference" type="xs:NMTOKEN"
use="optional"/>
<xs:attribute name="Acquire" type="xs:NMTOKEN"
use="optional"/>
<xs:attribute name="Forward" type="xs:NMTOKEN"
use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="Inquiry">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:anyURI">
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="Name">
<xs:complexType>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
<xs:attribute name="Prefix" type="xs:NMTOKEN"
use="optional"/>
<xs:attribute name="First" type="xs:NMTOKEN"
use="optional"/>
<xs:attribute name="Middle" type="xs:NMTOKEN"
use="optional"/>
<xs:attribute name="Last" type="xs:NMTOKEN"
use="optional"/>
<xs:attribute name="Suffix" type="xs:NMTOKEN"
use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="Password" type="EcomSimpleText"/>
<xs:element name="PrivateUse" type="EcomSimpleText"/>
<xs:element name="Response" type="EcomSimpleText"/>
<xs:element name="Settle">
<xs:complexType>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
<xs:attribute name="Day" type="xs:NMTOKEN"/>
<xs:attribute name="Month" type="xs:NMTOKEN"/>
<xs:attribute name="Year" type="xs:NMTOKEN"/>
</xs:complexType>
</xs:element>
<xs:element name="Signature">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="StateProv" type="EcomSimpleText"/>
<xs:element name="Street">
<xs:complexType>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
<xs:attribute name="Line1"/>
<xs:attribute name="Line2" use="optional"/>
<xs:attribute name="Line3" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="Trace" type="EcomSimpleText"/>
<xs:element name="Track1" type="EcomSimpleText"/>
<xs:element name="Track2" type="EcomSimpleText"/>
<xs:element name="TransactionComplete">
<xs:complexType/>
</xs:element>
<xs:element name="UserID" type="EcomSimpleText"/>
</xs:schema>
3. Usage Notes for ECML v2
This section provides a general usage guide for ECML v2.
3.1. Presentation of the Fields
ECML v2 merely names fields and specifies their content and
hierarchical organization. It does not constrain the order or
completeness of communication of or query for these fields.
Some parties may wish to provide or ask for more information, and
some for less by omitting fields. Some may ask for the information
they want in one interaction or web page, and others may ask for
parts of the information at different times in multiple interactions
or different web pages. For example, it is common to ask for "ship
to" information earlier so that the shipping cost can be computed
before the payment method information. Some parties may require that
all the information they request be provided whereas others may make
much of the information optional. Other variations are likely.
Every element may be flagged as a query or assertion by including,
when XML syntax is in use, the optional Mode attribute with the value
"Query" or "Assert" respectively. The Mode attribute effects all
descendant elements until overridden by a lower level element with a
Mode attribute. Thus it is easy to indicate that all of the elements
in an ECML v2 structure are present as queries or assertions.
Query elements may have data content. Such content SHOULD be
interpreted as a default value to be returned if no better value is
known.
There is no way with Version 2.0 of ECML to indicate what query
fields a party considers mandatory to be answered. From this point
of view, all fields queried are optional to complete. However, a
party may give an error or re-present a request for information if
some field it requires is not completed, just as it may if a field is
completed in a manner that it considers erroneous.
3.2. Methods and Flow of Setting the Fields
A variety of methods of communication is possible between the parties
by which each can indicate what fields it wants the other to provide.
Probably the easiest method for currently deployed mass software is
through fields in an [HTML] form. Other possibilities include using
an [XML] exchange, the IOTP Authenticate transaction [RFC2801], or
proprietary protocols.
So that browser software can tell what version it is dealing with, it
is REQUIRED that the Ecom_SchemaVersion field be included in every
transaction when ECML is being used on the web. Ecom_SchemaVersion
SHOULD appear on every web page that has any Ecom fields. It is
usually a hidden field in HTML Forms.
User action or the appearance of the Ecom_SchemaVersion field are
examples of triggers that can be used to initiate a facility capable
of providing information in response to an ECML-based query or of
using information from ECML assertions. Because some web software
may require user activation, it is RECOMMENDED that there be at least
one user-visible Ecom field on every web page with any Ecom fields
present when ECML is used via the web.
Under some circumstances, communications can proceed very slowly, so
it may not be clear to an automated processing function when it is
finished receiving ECML fields on a web page or the like. For this
reason, it is RECOMMENDED that the Ecom_SchemaVersion field be the
last Ecom field on a web page.
Transfer or requests for information can extend over several
interactions or web pages. Without further provision, a facility
could either require re-starting on each page or possibly violate or
appear to violate privacy by continuing to provide personal data
beyond the end of the transaction with a particular business. For
this reason, the Ecom_TransactionComplete field, which is normally
hidden when it is part of an HTML Form, is provided. It is
RECOMMENDED that it appear on the last interaction or web page
involved in a transaction, just before an Ecom_SchemaVersion field,
so that multi-interaction automated logic receives a hint as to when
to stop if it chooses to check for this field.
4. Security and Privacy Considerations
The information called for by many of these fields is sensitive. It
should be protected from unauthorized modification and kept
confidential if it is stored in a location or transmitted over a
channel where it might otherwise be observed. In addition, the
authenticity of the information will be a concern in many systems.
Mechanisms for such protection and authentication are not specified
herein but might, depending on circumstances, include object security
protocols (such as XMLDSIG [RFC3275], XML encryption [XMLENC], or CMS
[RFC3852]), or channel security (such as TLS [RFC2246] or IPSec
[RFC2411]). Systems in which an ECML field or fields are stored and
later forwarded will likely find object security the most
appropriate.
When information is being requested from a user, the user’s control
over the release of such information is needed to protect the user’s
privacy.
Software that is installed on shared or public terminals should be
configurable so that memory of any sensitive or individual identity
information is fully disabled. This is vital to protect the privacy
of library patrons, students, and customers using public terminals,
and of children who might, for example, use a form on a public
terminal without realizing that their information is being stored.
When sensitive or individual identification information is stored,
the operator or user should have an option to protect the
information; for example, with a password without which the
information will be unavailable, even to someone who has access to
the file(s) in which it is being stored.
Any multi-page/screen or other multi-aggregate field fill-in or data
provision mechanism SHOULD check for the Ecom_TransactionComplete
field and cease automated fill when it is encountered until fill is
further authorized.
It should be remembered that default, hidden, and other values
transferred to another party may be maliciously modified before being
returned.
5. IANA Considerations
The sections below provide for:
1. registration of the ECML v2 XML schema contained in this
document,
2. a version URN for ECML versions,
3. the subsidiary registration of particular ECML versions and the
specific registration of Version 2.0, and
4. three additional IANA registries for elements appearing in three
ECML v2 fields.
5.1. ECML v2 Schema Template
The ECML v2 schema give in Section 2.2.2 above is registered as
follows:
URI: urn:ietf:params:xml:schema:ECMLv2
Registrant Contact: The IESG <iesg@ietf.org>
XML: The XML Schema in Section 2.2.2 above.
5.2. ECML v2 URN Template
As specified by the template below from [RFC3553],
urn:ietf:params:ecml is permanently registered with sub-registration
via RFC publication.
Registry name: urn:ietf:params:ecml
Specification: RFC 4112
Repository: RFC 4112
Index value: Values subordinate to urn:ietf:params:ecml are
registered by RFC publication. As provided in
[RFC3553], once such a value is registered, it may
never change.
5.2.1. Sub-registration of v2.0
The subordinate value "v2.0" is hereby permanently registered so that
the URN
urn:ietf:params:ecml:v2.0
is used to indicate an ECML field or fields that conform to this
specification. Although it is not anticipated that deeper values
subordinate to this URN will need to be registered, if necessary,
they are registered by IESG approval.
5.3. IANA Registries
There are three fields described in Section 2.1.2 that require the
establishment of IANA registries as described below:
Ecom_Payment_Card_Type
A registry of case-insensitive alphanumeric ASCII [ASCII]
card-type designations from one to four characters in length
with no white space. See Section 2.1.2, Note 11, for the
initial 12 designations. Designations are added based on
expert approval. Applicants for registration will normally be
required already to have an ISO Issuer Identification Number
(IIN) or set of IINs.
Ecom_Payment_Card_Protocol
This field holds a space-separated list of protocols designated
by case-insensitive alphanumeric ASCII [ASCII] tokens from this
registry or holds the token "none". See Section 2.1.2, note
17, for the initial seven registered tokens (including "none")
and further information. Tokens are added to the registry
based on expert approval.
Ecom_Transaction_Type
A case-insensitive alphabetic ASCII [ASCII] value indicating
the type of transaction. See Section 2.1.2, note 30, for the
initial two registered values. Values are added based on
expert approval.
6. Acknowledgements
The following, listed is alphabetic order, have contributed to the
material herein: Ray Bellis, Steve Bellovin, Scott Hollenbeck, Russ