HTTP State Management Mechanism
Note: This ballot was opened for revision 23 and is now closed.
(Ron Bonica) Yes
(Alexey Melnikov) (was Discuss) Yes
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) Yes
(Sean Turner) (was Discuss) Yes
(Jari Arkko) No Objection
Comment (2011-01-03 for -** No value found for 'p.get_dochistory.rev' **)
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.
(Stewart Bryant) No Objection
(Ralph Droms) No Objection
(Adrian Farrel) (was Discuss) No Objection
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) No Objection
(Russ Housley) No Objection
(Tim Polk) (was Discuss) No Objection
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.