Electronic Commerce Modeling Language (ECML) Version 2 Specification
draft-ietf-trade-ecml2-spec-13
Discuss
Yes
(Ned Freed)
(Scott Hollenbeck)
No Objection
(Alex Zinin)
(Bert Wijnen)
(Bill Fenner)
(Margaret Cullen)
(Ted Hardie)
(Thomas Narten)
Note: This ballot was opened for revision 13 and is now closed.
Steven Bellovin Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2004-10-19)
Unknown
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 Former IESG member
Yes
Yes
()
Unknown
Scott Hollenbeck Former IESG member
(was Discuss)
Yes
Yes
()
Unknown
Alex Zinin Former IESG member
No Objection
No Objection
()
Unknown
Bert Wijnen Former IESG member
No Objection
No Objection
()
Unknown
Bill Fenner Former IESG member
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
No Objection
No Objection
(2003-12-04)
Unknown
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.
Margaret Cullen Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
(2004-10-11)
Unknown
A better reference for CMS is RFC 3852.
Ted Hardie Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Thomas Narten Former IESG member
No Objection
No Objection
()
Unknown