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

[Bjoern Hoehrmann <[e-mail]>]

Hi,

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

In section 1 the draft says "an HTTP server can store name/value pairs";
this should be rephrased to clearly indicate that the Set-Cookie is a
mere request and the client is free to ignore it. Similarily, in the
same paragraph "the user agent uses the metadata to determine whether to
return the name/value pairs in the Cookie header" should be clarified
that the metadata that is part of the cookie is but one thing among many
to base the decision on. A possible rewording would be:

   This document defines the HTTP Cookie and Set-Cookie headers.  Using
   the Set-Cookie header, an HTTP server can pass name/value pairs and
   associated metadata (called cookies) to a user agent.  When the user
   agent makes subsequent requests to the server, the user agent uses
   the metadata and other information to determine whether to return the
   name/value pairs in the Cookie header.

Later in the section, there should be a bibliographic reference for the
"Netscape cookie specification". In the same paragraph "However, none of
these documents describe how the Cookie and Set-Cookie headers are
actually used on the Internet" is rather unclear and does not appear to
do the relevant documents justice. As reader I am left wondering if the
intend is to say they did not attempt to do so, or were incomplete, or
what else is wrong with them.

In section 2.2 the imported rules should be phrased as grammar to make
them easer to scan and read, i.e., e.g.

  ALPHA = <as defined in ...> ; A-Z / a-z
  ...

Further down "Multiple OWS characters that occur within field-content
SHOULD be replaced with a single SP before interpreting the field value
or forwarding the message downstream"; the "field-content" is confusing
here, I read it as production, but then the document does not define the
production; this could be fixed by adding a reference to the HTTP speci-
fication which defines it, or by turning it into "HTTP message-header
field-content"; adding a reference is probably better.

It is unclear to me that intermediaries actually modify the headers like
that; has this been tested?

In section 2.3 we have "The terms request-host and request-uri refer to
the values the user agent would send to the server as, respectively, the
host (but not port) and the absoluteURI (http_URL) of the HTTP
Request-Line." I am not entirely sure how to read that; for example, the
"host" would be part of "absoluteURI" if it is sent in the Request-Line,
and sending an absoluteURI there is unusual (unless talking to a proxy).
Also, the reference to http_URL is probably incorrect if "https" URLs
are also permissable.

Section 3 starts with "We outline here ..."; words like "we" should be
avoided in technical specifications, one reason being that they may be
different to translate, another that it is unclear who "we" really is.

Later in the section, "The origin server MAY send the user agent a
Set-Cookie response header with the same or different information, or it
MAY send no Set-Cookie header at all." It is unclear what "same" refers
to here. It sounds like this might refer to servers setting the same
cookie over and over again even if the client is already sending it back
but that does not become clear from the paragraph.

At the end of section 3 it should be pointed out that the do-not-fold
rule is inconsistent with RFC 2616.

In section 3.1 it might be a good idea to use different amounts of white
space between protocol text and explanatory text depending on which text
belongs to which communication. (For example, with "Notice that the
server uses the Secure and HttpOnly attributes" I read back what the
example was because I had not noticed those attributes, and they are not
there because the text is discussing the following example).

With "If the server wishes the user agent to persist the cookie over
multiple sessions" it might make sense to clarify what is meant by a
session here, for example, "(for instance, web browsers usually end a
session when the browser application is closed)".

In section 4 I think "some of the most esoteric semantics" needs to be
rephrased (what is meant by "esoteric", and "most esoteric" is hard to
parse; "semantics" is probably also problematic here). In general, it
does not become clear how the specification might be modified in the
future, other than that there is some "cruft" that might be dropped.

I note that with the grammar in 4.1.1 there can be some confusion with
respect to the RFC 2616 BNF variant and the standard ABNF language; of
particular concern is the "implied *LWS" rule in RFC 2616; there should
be a note of the grammar differences, if any, here, or maybe earler in
the document.

The grammar makes reference to "abs_path", but does not define what it
is.

I am not sure what qualifies as "attribute" in "Servers SHOULD NOT
include two attributes with the same name." and there should be a
rationale for this somewhat surprising rule.

In "Servers SHOULD NOT include two Set-Cookie header fields" make that
"two or more" or possibly better "Servers SHOULD include at most one".

With '"Opaque" implies that the content is of interest and relevance
only to the origin server.' I do not think "implies" is the right word
here, "means" seems more appropriate. I also find the statement mis-
leading, if I have some script code running as part of a web page that
processes the cookie, that should be fine but contradicts the statement.

The point about the race condition and time_t appear to be out of place
in this section, that is more something for the security considerations
or a separate "Compatibility considerations" section. The point with the
race condition could also use an answer to "so what".

In section 4.1.2 "When the user agent receives a Set-Cookie header, the
user agent stores the cookie in its cookie store." This should probably
introduce the "cookie store" before it takes it for granted (like, a
user agent has a cookie store, and when it receives cookies, then it
stores them inside it). Alternatively, it would suffice to say that it
simply stores them (and passes them along later).

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/