IESG Comments on draft-ietf-trade-ecml2-spec-08.txt

[Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com>]

IESG Comments on draft-ietf-trade-ecml2-spec-08.txt

==================================
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.

==================================
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.

==================================
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.

==================================
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?