[http-state] Comments on draft-ietf-httpstate-cookie-08.txt (4.1.2.2 - 5.2.6)

[Bjoern Hoehrmann <[e-mail]>]

Hi,

  Some additional comments on draft-ietf-httpstate-cookie-08.txt:

In section 4.1.2.2, "The user agent is not required to retain the cookie
until the specified date has passed." `Max-Age` does not specify a date,
it specifies a duration.

Later in the section: "WARNING: Not all user agents support the Max-Age
attribute. User agents that do not support the Max-Age attribute will
ignore the attribute." I see no reason why this needs to be a "WARNING"
rather than a note, and the text needs to clarify that support for the
attribute is not optional but rather required.

In section 4.1.2.3, 'For example, if the Domain attribute contains the
value "example.com", the user agent will include the cookie in the ...';
"Contains" is the wrong word here, the value would have to be equivalent
to it, not just contain it as substring. And "will" is also the wrong
word.

Later in the section, "(Note that a leading U+002E ("."), if present,
is ignored even though that character is not permitted by the subdomain
production in [RFC1034].)" This needs to be rephrased so it refers to
the legal syntax of the attribute, otherwise it is unclear whether it
is conforming to send it.

The subsequent "Warning" needs to explain how and why the described be-
haviour is erroneous.

Later, "The user agent will reject cookies (refuse to store them in the
cookie store) unless the Domain attribute specifies a scope for the
cookie that would include the origin server.  For example, the user
agent will accept a Domain attribute ..." This needs to be rephrased, it
starts out saying the whole cookie will be rejected, but then only re-
fers to the Domain attribute being rejected.

In section 4.1.2.4, "If the server omits the Path attribute, the user
agent will use the directory of the request-uri's path component as the
default value." It is not clear what the "directory" of a path component
is, RFC 3986 for example does not define it.

The second paragraph needs a forward reference to where the matching is
explained. The forward reference in the third paragraph should be more
precise, section 8 is rather long.

I note that section 4.1.2.6 does not mention that some user agents do
not support the attribute. I am not sure if it should.

In section 4.2.1, "The user agent returns stored cookies ..." this
should probably not use "return" but something like "pass" as the cookie
may come from a different source than the server. (This also applies to
section 4.2.2).

"If the server conforms to the requirements in Section 4.1, the
requirements in the Section 5 will cause the user agent to return a
Cookie header that conforms to the following grammar" This seems some-
what confused. If the user agent is free to send whatever it wants in
the header, perhaps because the `Set-Cookie` it processed was invalid,
then this should be clearly stated here, more so if it is required to.

In section 5.1.1, "If the found-day-of-month flag is not set ..." Up to
this point it has not been explained what this flag is. The same goes
probably for all "flags". Definitions need to be added.

The surprising requirements in this section need to be accompanied by
some rationale, for example, accepting 1601 as year but not 1600 is
surprising and so is the 68/69 boundary.

In section 5.1.2 it needs to be explained what is supposed to happen if
the normalization process fails, e.g. when ToASCII fails. There should
be a reminder that using non-ASCII characters directly is prohibited.

There needs to be a discussion, I am not sure this is the right place,
on the handling of permissable HTTP "hosts" (non-DNS names, IP-Literals
and IPv4 addresses, for instance); some questions are, is it intentional
that the Domain attribute disallows setting the attribute to a IPv4
address, would a leading '.' in the attribute still be stripped, if such
host specifications are disallowed, must all cookies coming from them be
rejected? With a Set-Cookie from 127.0.0.1 with no Domain attribute, is
it incorrect to imply Domain=127.0.0.1? (I don't care, the specification
however needs to discuss those questions).

In section 5.1.3, there is a reference to `abs_path` without explaining
where it comes from (RFC 3986 no longer specifies that symbol).

The draft needs to explain how to handle a Set-Cookie header in a reply
to an `OPTIONS *` request. Right now it seems `uri-path` would be unde-
fined in that case, but the draft does not say what the consequence is.
There should be an explicit mention of the case, not just adjusted algo-
rithms.

In section 5.2, if the draft takes the position that HTTP header values
are sequences of octets and not Unicode code points, then it needs to be
explained at the beginning of this section how those octets are turned
into characters (at least so long as it refers directly to the header
and not some pre-processed value based on it, and so long it refers to
characters instead of octets).

In section 5.2.1 and subsequent sections the term "case-insensitively
matches" is not defined; this should probably be defined in the termi-
nology section.

Also in 5.2.1, using "last" and "first" in the context of time strikes
me as poor form.

I doubt the draft should require implementations to use the "last" Date
header, there are plenty of HTTP implementations where that is not
possible as the headers are only accessible in folded form. Section
4.1.2.1 also should be updated to clearly express that even though the
expiry time is set in an absolute form, it'll be handled as relative
value, as that is rather surprising.

regards,
-- 
Björn Höhrmann · mailto:[e-mail] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: [phone] · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/