Electronic Commerce Modeling Language (ECML) Version 2 Specification
Note: This ballot was opened for revision 13 and is now closed.
(Steven Bellovin) Discuss
Discuss (2004-10-19 for -)
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.
(Ned Freed) Yes
(Scott Hollenbeck) (was Discuss) Yes
(Margaret Cullen) No Objection
(Bill Fenner) No Objection
(Ted Hardie) (was Discuss) No Objection
(Russ Housley) (was Discuss) No Objection
A better reference for CMS is RFC 3852.
(Thomas Narten) No Objection
(Jon Peterson) No Objection
Comment (2003-12-04 for -)
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.