Electronic Commerce Modeling Language (ECML) Version 2 Specification
RFC 4112

Note: This ballot was opened for revision 13 and is now closed.

(Steven Bellovin; former steering group member) Discuss

Discuss [Treat as non-blocking comment] (2004-10-19 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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 steering group member) Yes

Yes ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Scott Hollenbeck; former steering group member) (was Discuss) Yes

Yes ()
No email
send info

(Alex Zinin; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Bert Wijnen; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Bill Fenner; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Jon Peterson; former steering group member) No Objection

No Objection (2003-12-04 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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 steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection (2004-10-11)
No email
send info
A better reference for CMS is RFC 3852.

(Ted Hardie; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Thomas Narten; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info