HTTP State Management Mechanism
RFC 6265

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

(Ron Bonica) Yes

Alexey Melnikov (was Discuss) Yes

Comment (2010-12-20)
No email
send info
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' **)
No email
send info
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

Comment (2010-12-13)
No email
send info
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

Comment (2010-12-16)
No email
send info
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.

(Robert Sparks) (was Discuss) No Objection