HTTP State Management Mechanism
draft-ietf-httpstate-cookie-23
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
23 | (System) | post-migration administrative database adjustment to the Yes position for Sean Turner |
2012-08-22
|
23 | (System) | post-migration administrative database adjustment to the No Objection position for Robert Sparks |
2012-08-22
|
23 | (System) | post-migration administrative database adjustment to the No Objection position for Tim Polk |
2012-08-22
|
23 | (System) | post-migration administrative database adjustment to the Yes position for Alexey Melnikov |
2012-08-22
|
23 | (System) | post-migration administrative database adjustment to the No Objection position for Adrian Farrel |
2011-03-03
|
23 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2011-03-03
|
23 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2011-03-03
|
23 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2011-03-03
|
23 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent. |
2011-03-03
|
23 | (System) | IANA Action state changed to In Progress |
2011-03-03
|
23 | Amy Vezza | IESG state changed to Approved-announcement sent |
2011-03-03
|
23 | Amy Vezza | IESG has approved the document |
2011-03-03
|
23 | Amy Vezza | Closed "Approve" ballot |
2011-03-03
|
23 | Amy Vezza | Approval announcement text regenerated |
2011-03-03
|
23 | Amy Vezza | State changed to Approved-announcement to be sent from IESG Evaluation - Defer::AD Followup. |
2011-03-03
|
23 | Peter Saint-Andre | Ballot writeup text changed |
2011-03-03
|
23 | Peter Saint-Andre | Ballot writeup text changed |
2011-03-01
|
23 | (System) | New version available: draft-ietf-httpstate-cookie-23.txt |
2011-02-28
|
23 | Peter Saint-Andre | Ballot writeup text changed |
2011-02-28
|
23 | Peter Saint-Andre | Ballot writeup text changed |
2011-02-28
|
23 | Peter Saint-Andre | Ballot writeup text changed |
2011-02-28
|
23 | Peter Saint-Andre | Ballot writeup text changed |
2011-02-24
|
23 | Peter Saint-Andre | Ballot writeup text changed |
2011-02-24
|
23 | Peter Saint-Andre | Ballot writeup text changed |
2011-02-21
|
23 | Tim Polk | [Ballot comment] [updated, moving to No Objection. Thanks for the changes.] One nit: In section 7.3 s/gratiously/gratuitously/ |
2011-02-21
|
23 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Discuss |
2011-02-19
|
23 | Alexey Melnikov | [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 … [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. |
2011-02-19
|
23 | Alexey Melnikov | [Ballot Position Update] Position for Alexey Melnikov has been changed to Yes from Discuss |
2011-02-18
|
23 | Robert Sparks | [Ballot Position Update] Position for Robert Sparks has been changed to No Objection from Discuss |
2011-02-18
|
23 | Peter Saint-Andre | Ballot writeup text changed |
2011-02-17
|
22 | (System) | New version available: draft-ietf-httpstate-cookie-22.txt |
2011-01-22
|
23 | Sean Turner | [Ballot Position Update] Position for Sean Turner has been changed to Yes from Discuss |
2011-01-22
|
23 | Sean Turner | [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 … [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 |
2011-01-20
|
23 | Alexey Melnikov | [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) … [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. |
2011-01-19
|
23 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2011-01-19
|
21 | (System) | New version available: draft-ietf-httpstate-cookie-21.txt |
2011-01-06
|
23 | Cindy Morgan | State changed to IESG Evaluation - Defer::Revised ID Needed from IESG Evaluation - Defer. |
2011-01-06
|
23 | Tim Polk | [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 … [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? |
2011-01-04
|
23 | Adrian Farrel | [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss |
2011-01-03
|
23 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko |
2011-01-03
|
23 | Jari Arkko | [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 … [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. |
2010-12-20
|
23 | Alexey Melnikov | [Ballot comment] 5.1.1. Dates year = 1*4DIGIT ( non-digit *OCTET ) Do people really use 1 digit and 3 … [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 ) |
2010-12-20
|
23 | Alexey Melnikov | [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) … [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. |
2010-12-20
|
23 | Alexey Melnikov | [Ballot comment] 5.1.1. Dates year = 1*4DIGIT ( non-digit *OCTET ) Do people really use 1 digit and 3 … [Ballot comment] 5.1.1. Dates year = 1*4DIGIT ( non-digit *OCTET ) Do people really use 1 digit and 3 digit years? |
2010-12-20
|
23 | Alexey Melnikov | [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 … [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. |
2010-12-19
|
20 | (System) | New version available: draft-ietf-httpstate-cookie-20.txt |
2010-12-17
|
23 | (System) | Removed from agenda for telechat - 2010-12-16 |
2010-12-16
|
23 | Sean Turner | [Ballot comment] #1) Section 4: It's odd that following is in Section 4, which is titled Server Requirements: User agents, however, MUST implement … [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. |
2010-12-16
|
23 | Sean Turner | [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 … [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)? |
2010-12-16
|
23 | Sean Turner | [Ballot Position Update] New position, Discuss, has been recorded |
2010-12-16
|
23 | Tim Polk | [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 … [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. |
2010-12-16
|
23 | Tim Polk | [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. … [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), |
2010-12-16
|
23 | Tim Polk | [Ballot Position Update] New position, Discuss, has been recorded |
2010-12-15
|
23 | Tim Polk | State changed to IESG Evaluation - Defer from IESG Evaluation. |
2010-12-15
|
23 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded |
2010-12-14
|
23 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded |
2010-12-14
|
23 | Robert Sparks | [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 … [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) |
2010-12-14
|
23 | Robert Sparks | [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? … [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. |
2010-12-14
|
23 | Robert Sparks | [Ballot Position Update] New position, Discuss, has been recorded |
2010-12-13
|
23 | Peter Saint-Andre | [Note]: 'Jeff Hodges (chair of the HTTPSTATE WG) is the document shepherd.' added |
2010-12-13
|
23 | David Harrington | [Ballot Position Update] New position, No Objection, has been recorded |
2010-12-13
|
23 | Ron Bonica | [Ballot Position Update] New position, Yes, has been recorded |
2010-12-13
|
23 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded |
2010-12-13
|
23 | Adrian Farrel | [Ballot comment] Section 1 Please don't be so timid. OLD This document attempts to specify the syntax and semantics of these headers … [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 |
2010-12-13
|
23 | Adrian Farrel | [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 … [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? |
2010-12-13
|
23 | Adrian Farrel | [Ballot Position Update] New position, Discuss, has been recorded |
2010-12-05
|
23 | Alexey Melnikov | [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 … [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. |
2010-12-04
|
23 | Alexey Melnikov | [Ballot comment] 2.2. Syntax Notation This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234]. The following core rules … [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? |
2010-12-04
|
23 | Alexey Melnikov | [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 … [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. |
2010-12-04
|
23 | Alexey Melnikov | [Ballot comment] 2.2. Syntax Notation This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234]. The following core rules … [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? |
2010-12-04
|
23 | Alexey Melnikov | [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 … [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. |
2010-12-04
|
23 | Alexey Melnikov | [Ballot Position Update] New position, Discuss, has been recorded |
2010-12-04
|
23 | Peter Saint-Andre | Note field has been cleared by Peter Saint-Andre |
2010-12-04
|
23 | Peter Saint-Andre | 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 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. |
2010-12-03
|
23 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Kurt Zeilenga. |
2010-12-02
|
23 | Peter Saint-Andre | [Ballot Position Update] New position, Yes, has been recorded for Peter Saint-Andre |
2010-12-02
|
23 | Peter Saint-Andre | Ballot has been issued |
2010-12-02
|
23 | Peter Saint-Andre | Created "Approve" ballot |
2010-12-02
|
23 | Peter Saint-Andre | State changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup. |
2010-12-02
|
23 | Peter Saint-Andre | Placed on agenda for telechat - 2010-12-16 |
2010-12-02
|
23 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2010-12-02
|
19 | (System) | New version available: draft-ietf-httpstate-cookie-19.txt |
2010-12-02
|
23 | Peter Saint-Andre | State changed to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead. |
2010-12-02
|
23 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
2010-11-29
|
23 | Amanda Baber | 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 … 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. |
2010-11-22
|
23 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Kurt Zeilenga |
2010-11-22
|
23 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Kurt Zeilenga |
2010-11-18
|
23 | Cindy Morgan | Last call sent |
2010-11-18
|
23 | Cindy Morgan | 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: … 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/ |
2010-11-18
|
23 | Cindy Morgan | Intended Status has been changed to Proposed Standard from None |
2010-11-18
|
23 | Peter Saint-Andre | Last Call was requested |
2010-11-18
|
23 | (System) | Ballot writeup text was added |
2010-11-18
|
23 | (System) | Last call text was added |
2010-11-18
|
23 | (System) | Ballot approval text was added |
2010-11-18
|
23 | Peter Saint-Andre | State changed to Last Call Requested from AD is watching. |
2010-11-08
|
18 | (System) | New version available: draft-ietf-httpstate-cookie-18.txt |
2010-10-25
|
17 | (System) | New version available: draft-ietf-httpstate-cookie-17.txt |
2010-10-24
|
16 | (System) | New version available: draft-ietf-httpstate-cookie-16.txt |
2010-10-10
|
15 | (System) | New version available: draft-ietf-httpstate-cookie-15.txt |
2010-09-30
|
14 | (System) | New version available: draft-ietf-httpstate-cookie-14.txt |
2010-09-24
|
13 | (System) | New version available: draft-ietf-httpstate-cookie-13.txt |
2010-09-16
|
12 | (System) | New version available: draft-ietf-httpstate-cookie-12.txt |
2010-09-05
|
11 | (System) | New version available: draft-ietf-httpstate-cookie-11.txt |
2010-07-26
|
10 | (System) | New version available: draft-ietf-httpstate-cookie-10.txt |
2010-06-05
|
09 | (System) | New version available: draft-ietf-httpstate-cookie-09.txt |
2010-05-10
|
23 | Peter Saint-Andre | Draft Added by Peter Saint-Andre in state AD is watching |
2010-04-23
|
08 | (System) | New version available: draft-ietf-httpstate-cookie-08.txt |
2010-04-18
|
07 | (System) | New version available: draft-ietf-httpstate-cookie-07.txt |
2010-04-17
|
06 | (System) | New version available: draft-ietf-httpstate-cookie-06.txt |
2010-03-07
|
05 | (System) | New version available: draft-ietf-httpstate-cookie-05.txt |
2010-02-23
|
04 | (System) | New version available: draft-ietf-httpstate-cookie-04.txt |
2010-02-13
|
03 | (System) | New version available: draft-ietf-httpstate-cookie-03.txt |
2010-01-21
|
02 | (System) | New version available: draft-ietf-httpstate-cookie-02.txt |
2010-01-06
|
01 | (System) | New version available: draft-ietf-httpstate-cookie-01.txt |
2010-01-06
|
00 | (System) | New version available: draft-ietf-httpstate-cookie-00.txt |