HTTP State Management Mechanism
draft-ietf-httpstate-cookie-23
Yes
(Peter Saint-Andre)
(Ron Bonica)
(Sean Turner)
No Objection
(David Harrington)
(Ralph Droms)
(Robert Sparks)
(Russ Housley)
(Stewart Bryant)
(Tim Polk)
Note: This ballot was opened for revision 23 and is now closed.
Alexey Melnikov Former IESG member
(was Discuss)
Yes
Yes
(2010-12-20)
Unknown
5.1.1. Dates year = 1*4DIGIT ( non-digit *OCTET ) Do people really use 1 digit and 3 digit years? I very much doubt that a single digit year is allowed, so may I suggest: year = 2*4DIGIT ( non-digit *OCTET )
Peter Saint-Andre Former IESG member
Yes
Yes
()
Unknown
Ron Bonica Former IESG member
Yes
Yes
()
Unknown
Sean Turner Former IESG member
(was Discuss)
Yes
Yes
(2011-01-22)
Unknown
Adrian Farrel Former IESG member
(was Discuss)
No Objection
No Objection
(2010-12-13)
Unknown
Section 1 Please don't be so timid. OLD This document attempts to specify the syntax and semantics of these headers as they are actually used on the Internet. NEW This document specifies the syntax and semantics of these headers as they are actually used on the Internet. END --- Section 10.2 You have: [Netscape] Netscape Communications Corp., "Persistent Client State -- HTTP Cookies", 1999, <http://web.archive.org/web/ 20020803110822/http://wp.netscape.com/newsref/std/ cookie_spec.html>. 1. Are you sure this is the best version of the spec? The document is headed: "Preliminary Specification - Use with caution" 2. RFC Erratum 1491 reads: Section 12 says: [Netscape] "Persistent Client State -- HTTP Cookies", available at <http://www.netscape.com/newsref/std/cookie_spec.html>, undated. It should say: [Netscape] "Persistent Client State -- HTTP Cookies", available at <http://www.netscape.com/newsref/std/cookie_spec.html>, undated. Copy avalaible at <http://curl.haxx.se/rfc/cookie_spec.html> Can you confirm that you do not need to add a "copy available" statement to this document? (See http://www.rfc-editor.org/errata_search.php?eid=1491) --- Erratum 2644 seems to have been submitted after the date of your I-D. I assume that this Erratum will be rejected as soon as your I-D becomes an RFC. (See http://www.rfc-editor.org/errata_search.php?eid=2644) --- Section 2.1 In particular, the algorithms defined in this specification are intended to be easy to understand and are not intended to be performant. Do you really mean "performant" which my dictionary gives only as a noun meaning " a perforemer". I found http://weblogs.asp.net/jgalloway/archive/2007/05/10/performant-isn-t-a-word.aspx
David Harrington Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2011-01-03)
Unknown
I agree with the Discusses from Alexey, Robert, Tim, and for the most part with Sean. I do not agree with the Discuss from Adrian. Obviously the document can make those actions.
Ralph Droms Former IESG member
No Objection
No Objection
()
Unknown
Robert Sparks Former IESG member
(was Discuss)
No Objection
No Objection
(2011-02-18)
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Stewart Bryant Former IESG member
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
(was Discuss)
No Objection
No Objection
(2010-12-16)
Unknown
I found the following Note at the end of 4.1.1 confusing: NOTE: Some user agents represent dates using 32-bit UNIX time_t values. Some of these user agents might contain bugs that cause them to process dates after the year 2038 incorrectly. After considering this for a while, I concluded that the point is that user agents might convert the dates into UNIX time_t values for storage and processing, and implementation bugs mean that dates after 2038 are not interpreted correctly. If that is correct, then maybe the following would be an appropriate substitution: NOTE: Some user agents store and process dates in cookies as 32-bit UNIX time_t values. Implementation bugs in the libraries supporting time_t processing on some systems may cause such user agents to process dates after the year 2038 incorrectly.