Electronic Commerce Modeling Language (ECML) Version 2 Specification
draft-ietf-trade-ecml2-spec-13

[Ballot discuss]
For certificates, what forms of URL are acceptable?  All?  Is this a pointer to a certificate chain?  What format is the certificate in?

Users don't necessarily use passwords just because they have pre-established accounts.  Nor does a certificate necessarily suffice if there's no prior account setup.

[Note]: 'Lots of changes are likely to be needed to address IESG
concerns, so this document needs fairly comprehensive
re-review once it is updated.' added by Ned Freed

[Ballot comment]
I think I understand the "Important Note" at the beginning of 2.1.1 - the minimum size values given in the field list are recommendations for the smallest length of the text input buffer for field values that implementers could safely present to users of these forms (i.e. if the buffer were shorter, users would almost certainly want to provide values that exceeded the buffer). However, it took me several readings to arrive at this conclusion, and the text itself could be a lot clearer.

2.1.2, footnote 8: The international access code in the NANP is not "1", it is "011". "1" is the direct distance dialing prefix. And yes, as Steve notes, we have large documents in the IETF (RFC2806 and its bis) that describe the proper representation of telephone numbers.

Finally, along the lines of Russ's Discuss, I'm really surprised that channel security is touted in the Sec Cons rather than object security. For a payment token, I'd think that non-repudiation would be a valuable security property. While non-repudiation is mentioned in the document, it is attributed to an alphabet soup of presumably complementary technologies without any specific indication of where one should turn if this property is desired.

[Ballot discuss]
There are standards for representing telephone numbers.  These should be cited....

For certificates, what forms of URL are acceptable?  All?  Is this a pointer to a certificate chain?  What format is the certificate in?

Users don't necessarily use passwords just because they have pre-established accounts.  Nor does a certificate necessarily suffice if there's no prior account setup.

[Ballot discuss]
In section 2.2, there is a note giving the ECMA Schema version as:


  (20) URI [RFC 2396]] indicating version of this set of fields.
  Usually a hidden field.  Equal to
  "http://ecml.trade.wg.ietf.arpa/version/2.0" for this version.

This looks like dereferencable URI, but there is no ietf.arpa in
the current DNS, and I know of no plans for one.  I'd suggest
using one of the IANA registries like RFC 3553 params (the
params namespace registry is present, but unpopulated, see:
http://www.iana.org/assignments/params)

That same section says:


  (26) A URL that can be invoked to inquire about the transaction.
  This is usually a hidden field.

and
    (35) Uniform Resource Locator [RFC 2396].

(referring to:
user certificate          Ecom_User_Certificate_URL          128  (35))

Any limits to the URL schema allowed?  Is this mailto: style, or
http: style in terms of what "inquire about" means?

Lastly, this pair:

  user data gender          Ecom_UserData_Gender                1  (36)

and its list:


  (36) A single capital letter, M=male, F=Female, N=Neuter,
  H=Hermaphrodite, U=Unknown.

sets off every alarm bell in my California-saturated head.  If this
list is derived from somewhere else and a reference can be given,
fine.  But having the IETF decide that these 5 were the listable
genders seems like a reeeeaaallly bad idea.  Punting this to someone else's
lawyers if at all possible would make me breathe easier.

[Ballot discuss]
In section 2.2, there is a note giving the ECMA Schema version as:


  (20) URI [RFC 2396]] indicating version of this set of fields.
  Usually a hidden field.  Equal to
  "http://ecml.trade.wg.ietf.arpa/version/2.0" for this version.

This looks like dereferencable URI, but there is no ietf.arpa in
the current DNS, and I know of no plans for one.  I'd suggest
using one of the IANA registries like RFC 3553 params (the
params namespace registry is present, but unpopulated, see:
http://www.iana.org/assignments/params)

That same section says:


  (26) A URL that can be invoked to inquire about the transaction.
  This is usually a hidden field.

and
    (35) Uniform Resource Locator [RFC 2396].

(referring to:
user certificate          Ecom_User_Certificate_URL          128  (35))

Any limits to the URL schema allowed?  Is this mailto: style, or
http: style in terms of what "inquire about" means?

Lastly, this pair:

user data gender          Ecom_UserData_Gender                1  (36)

and its list:


  (36) A single capital letter, M=male, F=Female, N=Neuter,
  H=Hermaphrodite, U=Unknown.

sets off every alarm bell in my California-saturated head.  If this is
list is derived from somewhere else and a reference can be given,
fine.  But having the IETF decide that these 5 were the listable
genders seems like a reeeeaaallly bad idea.  Punting this to someone else's
lawyers if at all possible would make me breathe easier.

[Ballot discuss]
Frankly, I have general problems with the scope of this work; it seems to need a
much tighter applicability statement (given that they are defining a "Voucher
Component and VTS-API specifications" but not a standard protocol). 

I also think this needs a good bit more review by folks who might have
to use it, as a lot of seems to be based on assumptions that might or might
not hold true generally. A good example of this is in the "Conditions" processing
(sections 4 &  6.10).  The initial description of the Conditions in section 4 says:

  Condition Component

    Provides any other applicable restrictions. This is intended to
    cover contracts between the issuer and holder of the
    voucher in natural language form.


"Natural language form" implied to me "free text" as opposed to "structured text",
but the  description in 6.10 says:


  The  element may contain any element used to specify
  any other restrictions or conditions applied that limit the use of
  the voucher. The sub-elements contained in this element are
  depending on the application of the voucher and are left to the
  other domain-specific specifications. Domain-specific elements can
  be extended as sub-elements using [XML-ns].

That seems to imply that  can be structured in certain contexts,
but that the structure there might relate only to the context, which leaves it
a bit up in the air as to whether someone getting a voucher needs to preserve
markup here.

The last line related to  is:

  If the  element is omitted, it will be generally
  interpreted that there are no other restrictions or conditions on
  using the voucher.

If the structure of this is application dependent, the interpretation of this
pretty much has to be as well.  There is no way to prevent someone from
saying "in my application, no conditions will mean there are no conditions
under which you can use this".  If this is retained, it seems like it has to be
given as deployment advice, rather than a default configuration.

[Ballot discuss]
The first paragraph of the security considerations says:

  The information called for by many of these fields is sensitive and
  should be secured if being sent over the public Internet or through
  other channels where it can be observed.  Mechanisms for such
  protection are not specified herein but channel encryption such as
  TLS [RFC 2246] or IPSec [RFC 2411] would be appropriate in many
  cases.

This discussion should be expanded to cover integrity and authentication.
The specification includes support for digital signatures, and this
feature should be highlighted here.  Also, is there any reason that
an application-layer encryption is not appropriate, such as XMLENC or
CMS?