HTTP State Management Mechanism
draft-ietf-httpstate-cookie-23

[Ballot comment]
This is a well written document. I balloting Yes on this document not because Cookies are pretty, but because this is the best attempt to describe them properly.

[Ballot discuss]
This is an updated discuss.  All of my original discussses were addressed except for #5 (did I miss it?).

This is a well written document, but I've got a couple of things I'd like to discuss:

#1) addressed

#2) addressed

#3) addressed

#4) addressed

#5) Section 8.3/8.5: Should point out that the format for signature/encryption is server specific.

#6) addressed

#7) addressed

#8) addressed

#9) addressed

[Ballot discuss]
[Updated as per -21]

This is a well written document. I am contemplating voting Yes on this document once my issues (see below) are discussed/resolved, not because Cookies are pretty, but because this is the best attempt to describe them properly.

9) From Lisa Dusseault's Apps Area Review:

Section 3. "Origin servers can send a Set-Cookie response header with
any response.".  Do we happen to know if it's more common for user
agents to handle, or ignore Set-Cookie response headers on error
responses?  I'd be surprised if user-agents do handle them including
on 500-level, 400-level and particularly on a 100 Continue response,
but I haven't tested it.  Is it part of your tests?  So while this
statement is factual, it might not help servers much.  If my
assumption about some clients ignoring the header on some classes of
responses is correct, I would add that information to the document in
a non-normative sentence.

[Ballot discuss]
This discuss was motivated in part by Richard Barnes' Gen-ART review.  Richard noted that:

"Many of these integrity issues are caused by user agents accepting cookies from outside the context where they would send them, in particular with the Secure and Path attributes.  It seems like this document, in specifying the desired/proper behavior of user agents, should require behavior that would mitigate these attacks.  In direct parallel to the handling of the Domain attribute:
1. Set-Cookies with the Secure flag should only be accepted over secure channels
2. Set-Cookies with the Path attribute set should only be accepted if the path value matches the request-uri of the request
(That is, update Steps 7 and 8 of S5.3 to match Steps 6 and 9/10)

The author responded:
"I agree that these would be desirable changes to the cookie protocol.
However, the http-state working group is not chartered to change the
cookie protocol.  In particular, the charter reads as follows:

    The working group must not introduce any new syntax or new semantics
    not already in common use."

I understand that this document cannot impose new rules or syntax.  However, as written this document
appears to *prohibit* clients from extending the algorithm to protect themselves:  User agents are required
to implement algorithms "equivalent to" the algorithms specified in Section 5  to process dates (section 5.1.1),
paths (5.1.4), parse a set cookie string (Section 5.2), and the processing the cookie (Section 5.3, which was
at the heart of Richard's issues), processing the cookie header (section 5.4), etc.  This does not leave an
implementer with any wiggle room, forcing them to accept insecure processing rules.

This document should not prohibit clients from doing additional processing to enhance their own security,
especially since the processing rules proposed by Richard apparently would not affect interoperability with
a well-behaved server. 

I believe that a better model is the PKIX path validation processing algorithm, where "functionally equivalent"
implementations are required but are explicitly permitted to extend the model to enhance security.  For example,
some implementers have chosen to require that a certificate and CRL be signed by the same cryptographic key
to guard against name collisions.  This is not required by PKIX but implementations that include this feature
are still compliant.

Is there a good reason why extensions to the user agent's processing cannot be extended as Richard suggested?

[Ballot comment]
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.

[Ballot comment]
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 )

[Ballot discuss]
[Updated as per -20]

This is a well written document. I am contemplating voting Yes on this document once my issues (see below) are discussed/resolved, not because Cookies are pretty, but because this is the best attempt to describe them properly.

7) In Section 5.4:

  NOTE: Despite its name, the cookie-string is actually a sequence of
  octets, not a sequence of characters.  To convert the cookie-string
  (or components thereof) into a sequence of characters (e.g., for
  presentation to the user), the user agent might wish use the UTF-8
  character encoding [RFC3629] to decode the octet sequence.

Clients can't assume that an arbitrary sequence of octets generated by the server would be a valid UTF-8.
This needs to be clarified.

9) From Lisa Dusseault's Apps Area Review:

Section 3. "Origin servers can send a Set-Cookie response header with
any response.".  Do we happen to know if it's more common for user
agents to handle, or ignore Set-Cookie response headers on error
responses?  I'd be surprised if user-agents do handle them including
on 500-level, 400-level and particularly on a 100 Continue response,
but I haven't tested it.  Is it part of your tests?  So while this
statement is factual, it might not help servers much.  If my
assumption about some clients ignoring the header on some classes of
responses is correct, I would add that information to the document in
a non-normative sentence.

[Ballot comment]
5.1.1.  Dates

  year            = 1*4DIGIT ( non-digit *OCTET )

Do people really use 1 digit and 3 digit years?

[Ballot discuss]
[Note that I might have a couple of extra issues before the IESG telechat.]

This is a well written document. I am contemplating voting Yes on this document once my issues (see below) are discussed/resolved, not because Cookies are pretty, but because this is the best attempt to describe them properly.

7) In Section 5.4:

  NOTE: Despite its name, the cookie-string is actually a sequence of
  octets, not a sequence of characters.  To convert the cookie-string
  (or components thereof) into a sequence of characters (e.g., for
  presentation to the user), the user agent might wish use the UTF-8
  character encoding [RFC3629] to decode the octet sequence.

I would like to understand why the information about UTF-8 is here and why it only applies to server.


9) From Lisa Dusseault's Apps Area Review:

Section 3. "Origin servers can send a Set-Cookie response header with
any response.".  Do we happen to know if it's more common for user
agents to handle, or ignore Set-Cookie response headers on error
responses?  I'd be surprised if user-agents do handle them including
on 500-level, 400-level and particularly on a 100 Continue response,
but I haven't tested it.  Is it part of your tests?  So while this
statement is factual, it might not help servers much.  If my
assumption about some clients ignoring the header on some classes of
responses is correct, I would add that information to the document in
a non-normative sentence.

[Ballot comment]
#1) Section 4: It's odd that following is in Section 4, which is titled Server Requirements:

  User agents,
  however, MUST implement the requirements in Section 5 to ensure
  interoperability with servers making use of the full semantics.

Shouldn't it be in Section 5?

#2) In Section 5.2, add "(see Section 7.1)" to the end of:

For example, the user agent might wish to block responses to "third-party" requests from setting cookies.

#3) In Section 5.4, add "(see Section 7.1)" to the end of:

For example, the user agent might wish to block sending cookies during "third-party" requests.

[Ballot discuss]
[These are my preliminary discusses.  I might find more later.]

This is a well written document, but I've got a couple of things I'd like to discuss:

#1) I'd like to see a new security consideration section that addresses persistent cookies.  I think we need to mention how expiry date can be abused.  Is there some kind of recommendation we can give on their lifetimes?  Are cookies good for 2, 5, 20 years okay?

#2) I'd like to see a new privacy|security consideration that says what's being touted as "private browsing" doesn't protect cookies it only stops the history from being updated.

#3) Section 7.1:  I understand it's hard to have one policy for third-party cookies.  But, couldn't we say that assuming sites aren't behaving badly or somehow otherwise sharing tracking data that users that wish to not be tracked by third-parties ensure that third-party cookies be blocked?

#4) Section 7.2:  It's not a protocol thing, but should we really make the following two SHOULDs:

User agents should provide users with a mechanism for managing the
  cookies stored in the cookie store.

User agents should provide users with a mechanism for disabling
  cookies.

#5) Section 8.3/8.5: Should point out that the format for signature/encryption is server specific.

#6) Section 8.3, last paragraph:

a) The last paragraph, I believe, discusses "sidejacking" and "cookie monster" attacks (or is that the 1st paragraph in 8.5?).  Is it worth explicitly mentioning the name of these attacks?

b) To that end, can we add something like (I'm not wed to the words) the following to the end of the paragraph in 8.3:

For example, a webmail server that is initially accessed via HTTPS but later exchanges mail (and cookies) over HTTP will expose whatever cookie (and mail) is exchanged between the client and server.  Sidejacking is when a MITM intercepts the HTTP exchanges.  If a server incorrectly sets the Secure attribute and sends a cookie that otherwise should have been sent over a secure channel, a MITM can access the cookie (sometimes called a cookie monster attack). 

#7) Sec 8:  Where would we say something about how when multiple users use the same machine, they're not protected from one another?

#8) Sec 8: Shouldn't we have a section on cross-site scripting attacks (i.e., scripts that make browser send cookies to malicious servers that should not receive them) and how http-only helps?  I.e., servers should set httpOnly to stop these?

#9) Sec 4.2/8 ?: Where are cookie poising attack discussed (i.e., client returns a different cookie than the one set by the server)?

[Ballot comment]
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.

[Ballot discuss]
This is a preliminary discuss.  I intend to add additional issues, but would like to alert the authors to the
following issues now.

(1) User agents are required to implement algorithms "equivalent to" the algorithms specified in Section 5
to process dates (section 5.1.1), paths (5.1.4), parse a set cookie string (Section 5.2),

[Ballot comment]
Please consider moving the SHOULD in the first of the two NOTE:s at the end of 4.1.1 out of the NOTE.

Consider noting in the discussion of "public suffixes" that the problems this mechanism attempts
to avoid are still present in deeper heirarchies (A server at math.example.edu will be able to
set cookies for example.edu, potentially affecting the behavior of infosec.example.edu)

[Ballot discuss]
In 4.1.1 (Syntax) - Why is the specification part of this proposed standard allowing implementations to
violate the grammar defined by this standard? The SHOULD NOT in the first paragraph of this section must
be a MUST NOT. If the intent is to make sure clients are liberal in what they accept because existing
servers may generate non-conformant grammar, just say that (and if possible, point to what they might
need to expect). If the intent is to allow servers that are compliant to generate messages not covered
by this grammar, then the grammar is incorrect. If that's the case, the grammar should be extended to
allow the alternate behavior and the document's prose can say that servers SHOULD NOT use those parts
of the grammar.

[Ballot comment]
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, .

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
                ,
                undated.

    It should say:

    [Netscape] "Persistent Client State -- HTTP Cookies", available at
                ,
                undated.

                Copy avalaible at

  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

[Ballot discuss]
Discuss-Discuss

This issue is for discussion within the IESG and no action is required
of the authors at this stage.

  Therefore, in relation to previous IETF specifications of HTTP state
  management mechanisms, this document requests the following actions:

  1.  Change the status of [RFC2109] to Historic (it has already been
      obsoleted by [RFC2965]).

  2.  Change the status of [RFC2965] to Historic.

  3.  Indicate that [RFC2965] is obsoleted by this document.

Can this document do all those thing?

[Ballot discuss]
[Note that I might have a couple of extra issues before the IESG telechat.]

This is a well written document. I am contemplating voting Yes on this document once my issues (see below) are discussed/resolved, not because Cookies are pretty, but because this is the best attempt to describe them properly.

1) In Section 4.1.1:

max-age-av        = "Max-Age=" 1*DIGIT

Does this value have any practical limit? Are implementations
expected to accept 128bit values?

Are leading zeroes allowed here?


  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.

Does this affect Max-Age? If it does, I think you need to add an ABNF comment
to describe the limitation.

2). In Section 4.1.1:

  The portions of the set-cookie-string produced by the cookie-av term
  are known as attributes.  To maximize compatibility with user agents,
  servers SHOULD NOT produce two attributes with the same name in the
  same set-cookie-string.

What should happen in multiple attributes with the same name are included?

  Servers SHOULD NOT include more than one Set-Cookie header field in
  the same response with the same cookie-name.

How should a client handle multiple of these?

3).  In Section 4.1.2.3:

  The Domain attribute specifies those hosts to which the cookie will
  be sent.  For example, if the value of the Domain attribute is
  "example.com", the user agent will include the cookie in the Cookie
  header when making HTTP requests to example.com, www.example.com, and
  www.corp.example.com.  (Note that a leading %x2E ("."), if present,
  is ignored even though that character is not permitted.)

What about the trailing dot?

4) In Section 4.1.2.5:

  The Secure attribute limits the scope of the cookie to "secure"
  channels (where "secure" is defined by the user agent).  When a
  cookie has the Secure attribute, the user agent will include the
  cookie in an HTTP request only if the request is transmitted over a
  secure channel (typically HTTP over Secure Sockets Layer (SSL),

(Comment) IETF is trying to actively deprecate use of SSL 2.0.
I think it would be better if you combine this with
"HTTP over TLS" below, especially considering that there is no
separate spec for SSL 3.0 that I am aware of.

  HTTP
  over Transport Layer Security (TLS) [RFC2818], and TLS [RFC5246]
  itself).

It is not clear to me what is "and TLS [RFC5246] itself". How is this
different from RFC 2818?

6) In Section 5.1.3:

  o  The domain string and the string are identical.

Is comparison case-insensitive?

I think this needs to clarify that domain canonicalization
(as per Section 5.1.2) is done first.

7) In Section 5.4:

  NOTE: Despite its name, the cookie-string is actually a sequence of
  octets, not a sequence of characters.  To convert the cookie-string
  (or components thereof) into a sequence of characters (e.g., for
  presentation to the user), the user agent might wish use the UTF-8
  character encoding [RFC3629] to decode the octet sequence.

I would like to understand why the information about UTF-8 is here, and if it needs to be here why the text is not normative.

8) In Section 9:

Considering that this document moves RFC 2965 to Historic,
I think this section should also mark Cookie2 and Set-Cookie2
header fields as obsoleted in the IANA registry.

9) From Lisa Dusseault's Apps Area Review:

Section 3. "Origin servers can send a Set-Cookie response header with
any response.".  Do we happen to know if it's more common for user
agents to handle, or ignore Set-Cookie response headers on error
responses?  I'd be surprised if user-agents do handle them including
on 500-level, 400-level and particularly on a 100 Continue response,
but I haven't tested it.  Is it part of your tests?  So while this
statement is factual, it might not help servers much.  If my
assumption about some clients ignoring the header on some classes of
responses is correct, I would add that information to the document in
a non-normative sentence.

[Ballot comment]
2.2.  Syntax Notation

  This specification uses the Augmented Backus-Naur Form (ABNF)
  notation of [RFC5234].

  The following core rules are included by reference, as defined in
  [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
  (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
  HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
  sequence of data), SP (space), HTAB (horizontal tab), CHAR (any US-
  ASCII character),

The definition in RFC 5234 excludes NUL.

  VCHAR (any visible US-ASCII character), and WSP
  (whitespace).

2.3.  Terminology

  The term string means a sequence of octets.

Including NUL octets?


5.1.1.  Dates

  5.  Abort these steps and fail to parse the cookie-date if

      *  at least one of the found-day-of-month, found-month, found-
          year, or found-time flags is not set,

      *  the day-of-month-value is less than 1 or greater than 31,

      *  the year-value is less than 1601,

      *  the hour-value is greater than 23,

      *  the minute-value is greater than 59, or

      *  the second-value is greater than 59.

It would be good to clarify that leap seconds are not allowed.

5.1.1.  Dates

  year            = 1*4DIGIT ( non-digit *OCTET )

Do people really use 1 digit and 3 digit years?

[Ballot discuss]
[Note that I might have a couple of extra issues before the IESG telechat.]

This is a well written document. I am contemplating voting Yes on this document once my issues (see below) are discussed/resolved, not because Cookies are pretty, but because this is the best attempt to describe them properly.

1) In Section 4.1.1:

max-age-av        = "Max-Age=" 1*DIGIT

Does this value have any practical limit? Are implementations
expected to accept 128bit values?

Are leading zeroes allowed here?


  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.

Does this affect Max-Age? If it does, I think you need to add an ABNF comment
to describe the limitation.

2). In Section 4.1.1:

  The portions of the set-cookie-string produced by the cookie-av term
  are known as attributes.  To maximize compatibility with user agents,
  servers SHOULD NOT produce two attributes with the same name in the
  same set-cookie-string.

What should happen in multiple attributes with the same name are included?

  Servers SHOULD NOT include more than one Set-Cookie header field in
  the same response with the same cookie-name.

How should a client handle multiple of these?

3).  In Section 4.1.2.3:

  The Domain attribute specifies those hosts to which the cookie will
  be sent.  For example, if the value of the Domain attribute is
  "example.com", the user agent will include the cookie in the Cookie
  header when making HTTP requests to example.com, www.example.com, and
  www.corp.example.com.  (Note that a leading %x2E ("."), if present,
  is ignored even though that character is not permitted.)

What about the trailing dot?

4) In Section 4.1.2.5:

  The Secure attribute limits the scope of the cookie to "secure"
  channels (where "secure" is defined by the user agent).  When a
  cookie has the Secure attribute, the user agent will include the
  cookie in an HTTP request only if the request is transmitted over a
  secure channel (typically HTTP over Secure Sockets Layer (SSL),

(Comment) IETF is trying to actively deprecate use of SSL 2.0.
I think it would be better if you combine this with
"HTTP over TLS" below, especially considering that there is no
separate spec for SSL 3.0 that I am aware of.

  HTTP
  over Transport Layer Security (TLS) [RFC2818], and TLS [RFC5246]
  itself).

It is not clear to me what is "and TLS [RFC5246] itself". How is this
different from RFC 2818?

6) In Section 5.1.3:

  o  The domain string and the string are identical.

Is comparison case-insensitive?

I think this needs to clarify that domain canonicalization
(as per Section 5.1.2) is done first.

7) In Section 5.4:

  NOTE: Despite its name, the cookie-string is actually a sequence of
  octets, not a sequence of characters.  To convert the cookie-string
  (or components thereof) into a sequence of characters (e.g., for
  presentation to the user), the user agent might wish use the UTF-8
  character encoding [RFC3629] to decode the octet sequence.

I would like to understand why the information about UTF-8 is here, and if it needs to be here why the text is not normative.

8) In Section 9:

Considering that this document moves RFC 2965 to Historic,
I think this section should also mark Cookie2 and Set-Cookie2
header fields as obsoleted in the IANA registry.

[Ballot comment]
2.2.  Syntax Notation

  This specification uses the Augmented Backus-Naur Form (ABNF)
  notation of [RFC5234].

  The following core rules are included by reference, as defined in
  [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
  (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
  HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
  sequence of data), SP (space), HTAB (horizontal tab), CHAR (any US-
  ASCII character),

The definition in RFC 5234 excludes NUL.

  VCHAR (any visible US-ASCII character), and WSP
  (whitespace).

2.3.  Terminology

  The term string means a sequence of octets.

Including NUL octets?

5.1.1.  Dates

  year            = 1*4DIGIT ( non-digit *OCTET )

Do people really use 1 digit and 3 digit years?

[Ballot discuss]
[Note that I might have a couple of extra issues before the IESG telechat.]

This is a well written document. I am contemplating voting Yes on this document once my issues (see below) are discussed/resolved, not because Cookies are pretty, but because this is the best attempt to describe them properly.

1) In Section 4.1.1:

max-age-av        = "Max-Age=" 1*DIGIT

Does this value have any practical limit? Are implementations
expected to accept 128bit values?

Are leading zeroes allowed here?


  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.

Does this affect Max-Age? If it does, I think you need to add an ABNF comment
to describe the limitation.

2). In Section 4.1.1:

  The portions of the set-cookie-string produced by the cookie-av term
  are known as attributes.  To maximize compatibility with user agents,
  servers SHOULD NOT produce two attributes with the same name in the
  same set-cookie-string.

What should happen in multiple attributes with the same name are included?

  Servers SHOULD NOT include more than one Set-Cookie header field in
  the same response with the same cookie-name.

How should a client handle multiple of these?

3).  In Section 4.1.2.3:

  The Domain attribute specifies those hosts to which the cookie will
  be sent.  For example, if the value of the Domain attribute is
  "example.com", the user agent will include the cookie in the Cookie
  header when making HTTP requests to example.com, www.example.com, and
  www.corp.example.com.  (Note that a leading %x2E ("."), if present,
  is ignored even though that character is not permitted.)

What about the trailing dot?

4) In Section 4.1.2.5:

  The Secure attribute limits the scope of the cookie to "secure"
  channels (where "secure" is defined by the user agent).  When a
  cookie has the Secure attribute, the user agent will include the
  cookie in an HTTP request only if the request is transmitted over a
  secure channel (typically HTTP over Secure Sockets Layer (SSL),

(Comment) IETF is trying to actively deprecate use of SSL 2.0.
I think it would be better if you combine this with
"HTTP over TLS" below, especially considering that there is no
separate spec for SSL 3.0 that I am aware of.

  HTTP
  over Transport Layer Security (TLS) [RFC2818], and TLS [RFC5246]
  itself).

It is not clear to me what is "and TLS [RFC5246] itself". How is this
different from RFC 2818?

5) In 5.1.1:

5.1.1.  Dates

  5.  Abort these steps and fail to parse the cookie-date if

      *  at least one of the found-day-of-month, found-month, found-
          year, or found-time flags is not set,

      *  the day-of-month-value is less than 1 or greater than 31,

      *  the year-value is less than 1601,

      *  the hour-value is greater than 23,

      *  the minute-value is greater than 59, or

      *  the second-value is greater than 59.

So leap seconds are not allowed?

6) In Section 5.1.3:

  o  The domain string and the string are identical.

Is comparison case-insensitive?

I think this needs to clarify that domain canonicalization
(as per Section 5.1.2) is done first.

7) In Section 5.4:

  NOTE: Despite its name, the cookie-string is actually a sequence of
  octets, not a sequence of characters.  To convert the cookie-string
  (or components thereof) into a sequence of characters (e.g., for
  presentation to the user), the user agent might wish use the UTF-8
  character encoding [RFC3629] to decode the octet sequence.

I would like to understand why the information about UTF-8 is here, and if it needs to be here why the text is not normative.

8) In Section 9:

Considering that this document moves RFC 2965 to Historic,
I think this section should also mark Cookie2 and Set-Cookie2
header fields as obsoleted in the IANA registry.

Document Shepherd Write-Up for
http://tools.ietf.org/html/draft-ietf-httpstate-cookie-19
"HTTP State Management Mechanism"

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

The Document Shepherd is Jeff Hodges.

The document has been reviewed and is ready for forwarding to IESG for
publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?

The document had one official WG Last Call, and has been revised and
re-reviewed several times since issuance of WG Last Call. It received
considerable review from working group participants, several of whom are
implementors of the (sub)protocol.  Commenters include (in no particular order) Dan Witte, Daniel Stenberg, Bjoern Hoehrmann, Julian Reschke, Anne van Kesteren, Roy T. Fielding, Mark Pauley, Yngve Nysaeter Pettersen, Bil Corry, Dan Winship, and others.

The Document Shepherd does not have concerns about the depth or breadth
of the reviews.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

The document should undergo the usual Gen-ART and secdir reviews.
Otherwise the Document Shepherd does not have concerns over the level and
breadth of review for this document. This is a moderate length document
although with some involved algorithms -- schedules for external reviews should keep that in mind.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

The document shepherd has no concerns with this document.

There have been no IPR disclosures on this document. Disclosure number 1199 was filed on RFC2965. This spec will obsolete RFC2965 and requests that RFC2965 and RFC2109 be re-classified as Historic.

This draft borrows from RFC2109 and so asserts pre-RFC5378 IPR boilerplate.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

Among the people currently active in the WG there is a wide consensus
behind the document. No objections have been raised to this version of the
document.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

Nobody has threatened an appeal or otherwise indicated extreme discontent.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

idnits 2.12.05 returns a few other warnings that do not appear to be
substantive. The Document Shepherd believes that the document contains
all needed information.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

The draft contains both normative and informative references.

The draft contains a normative reference to an obsoleted specification,
RFC3490, and an annotation is given in its References entry pointing back to the text where this is explicitly explained (in Section 6.3). This is due to the intricacies of referencing IDNA {2008,2003}, of which this document is a test case by virtue of being one of the first to do so.

Otherwise the draft normatively references only standards-track RFCs.

The draft contains informative references to both RFC2109 and RFC2965 (the
latter obsoletes the former) because RFC2109 more closely resembles (but
doesn't actually specify) how HTTP cookies are implemented and utilized on
today's Internet, and references to both are necessary to accurately convey the present state, and history, of cookie standardization.

The draft contains informative references to three non-IETF documents.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

The draft contains a non-empty IANA Considerations section, and the Document Shepherd believes that it properly references the appropriate registry and properly specifies new entries in that registry.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

The draft contains various ABNF stanzas which were checked via
which reported "No errors during parsing."

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary
        Relevant content can frequently be found in the abstract
        and/or introduction of the document. If not, this may be
        an indication that there are deficiencies in the abstract
        or introduction.

This document defines the HTTP Cookie and Set-Cookie HTTP header fields as they are presently utilized on the Internet. Although these headers were previously specified by RFC 2109, which is obsoleted by RFC2965, those specifications do not accurately reflect actual usage. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. This specification defines a well-behaved profile of in-the-wild Cookie and Set-Cookie header usage for servers, and describes the full cookie syntax and semantics for user agents. The intention is to realistically support backwards compatibility with current practice (and accurately specify such) while encouraging servers and web applications to normalize to more standardized behavior.

Because this specification provides the first complete and accurate
documentation of cookies as they are used on the Internet, it requests the
following actions of the RFC Editor:

  (1) obsolete RFC 2965;
  (2) change the status of RFC 2109 to Historic;
  (3) change the status of RFC 2965 to Historic.

    Working Group Summary
        Was there anything in WG process that is worth noting? For
        example, was there controversy about particular points or
        were there decisions where the consensus was particularly
        rough?

There is strong consensus in the working group to publish this document.

There were concerns raised with respect to the differing presentation
modalities (declarative versus algorithmic) between the specification of
server-side behavior and user agent behavior, although the WG worked through those issues.

    Document Quality
        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to
        implement the specification? Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues? If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?

The HTTP cookie sub-protocol as specified in the draft is widely implemented in today's major browsers. Some existing servers implement something close to or the same as the draft's "server reqirements" while others emit various variations which the "user agent requirements" are designed to handle. Various browser implementors participated in the working group, as well as some server-side implementors. HTTPbis editors also participated.

Without this specification, cookies as presently utilized on the Internet are effectively un-specified. With this specification, an implementor will be able to craft a new user agent or server that will interoperate with other presently deployed HTTP-speaking cookie-employing entities.

Upon approval of this document, IANA understands that two IANA Actions
need to be completed.

In both cases, references need to be updated in the existing registry
named Permanent Message Header Field Names located at:

http://www.iana.org/assignments/message-headers/perm-headers.html

First, the reference for the Header Field Name "cookie" needs to be
updated to [RFC-to-be].

Second, the reference for the Header Field Name "Set-Cookie" needs to be
updated to [RFC-to-be].

IANA understands that these two actions are all that need to be
completed upon approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (HTTP State Management Mechanism) to Proposed Standard


The IESG has received a request from the HTTP State Management Mechanism
WG (httpstate) to consider the following document:
- 'HTTP State Management Mechanism'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2010-12-02. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-httpstate-cookie/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-httpstate-cookie/