[http-state] draft-ietf-httpstate-cookie-09 algorithm descriptions

[Julian Reschke <[e-mail]>]

Hi,

I realize that this may sound like nitpicking, but I really think that 
some parts of the spec are both too vague in some aspects, and overly 
precise in others.

See, for example, Section 5.4.:

> 5.4. The Cookie Header
>
>
>    When the user agent generates an HTTP request, the user agent SHOULD
>    attach exactly one HTTP header named Cookie if the cookie-string
>    (defined below) for the request-uri is non-empty.

It says "SHOULD attach exactly one", but doesn't really state the header 
field value. Oversight?

>    A user agent MAY omit the Cookie header in its entirety.  For
>    example, the user agent might wish to block sending cookies during
>    "third-party" requests.

So we have "SHOULD send" and "MAY omit". The "MAY" makes attaching the 
header truly optional (correctly), thus the "SHOULD" requirement is 
incorrect.

It would probably better to start the section by stating that sending 
the header is truly optional, and then describe the remainder of the 
algorithm.

>    The user agent MUST use an algorithm equivalent to the following
>    algorithm to compute the cookie-string from a cookie store and a
>    request-uri:
>
>    1.  Let cookie-list be the set of cookies from the cookie store that
>        meet all of the following requirements:
>
>        *  Either:
>
>              The cookie's host-only-flag is true and the canonicalized
>              request-host is identical to the cookie's domain.
>
>           Or:
>
>              The cookie's host-only-flag is false and the canonicalized
>              request-host domain-matches cookie's domain.
>
>        *  The request-uri's path path-matches cookie's path.
>
>        *  If the cookie's secure-only-flag is true, then the request-
>           uri's scheme must denote a "secure" protocol (as defined by
>           the user agent).
>
>              NOTE: The notion of a "secure" protocol is not defined by
>              this document.  Typically, user agents consider a protocol
>              secure if the protocol makes use of transport-layer
>              security, such as SSL or TLS.  For example, most user
>              agents consider "https" to be a scheme that denotes a
>              secure protocol.

Are we comfortable with not stating what is secure? At least for those 
protocols in use today we may have to.

>        *  If the cookie's http-only-flag is true, then exclude the
>           cookie unless the cookie-string is being generated for an
>           "HTTP" API (as defined by the user agent).

This is in the section "The Set-Cookie header". That's always an "HTTP" 
API, right?

Maybe the algorithm ("computing the cookie string") and the header 
definition need to be separated some more?

>    2.  The user agent SHOULD sort the cookie-list in the following
>        order:
>
>        *  Cookies with longer paths are listed before cookies with
>           shorter paths.
>
>        *  Among cookies that have equal length path fields, cookies with
>           earlier creation-times are listed before cookies with later
>           creation-times.
>
>        NOTE: Not all user agents sort the cookie-list in this order, but
>        this order reflects common practice when this document was
>        written, and, historically, there have been servers that
>        (erroneously) depended on this order.
>
>    3.  Update the last-access-time of each cookie in the cookie-list to
>        the current date and time.
>
>    4.  Serialize the cookie-list into a cookie-string by processing each
>        cookie in the cookie-list in order:
>
>        1.  Output the cookie's name, the U+003D ("=") character, and the
>            cookie's value.
>
>        2.  If there is an unprocessed cookie in the cookie-list, output
>            the characters U+003B and U+0020 ("; ").
>
>    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 SHOULD use the UTF-8
>    character encoding [RFC3629].

Here the spec is pedantic, which is a bit strange as just in the 
paragraph above it talks about characters :-).

Also, we may want to say "SHOULD use the UTF-8 ... to *decode* the octet 
sequence". Which in turn begs the question: what if the octet sequence 
isn't valid UTF-8? - Also, do we have any evidence that servers actually 
use UTF-8 here?

Best regards, Julian