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

[Adam Barth <[e-mail]>]

On Wed, May 26, 2010 at 5:08 PM, Bjoern Hoehrmann <[e-mail]> wrote:
> * Adam Barth wrote:
>>On Wed, May 26, 2010 at 2:52 PM, Bjoern Hoehrmann <[e-mail]> wrote:
>>>>> 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.
>>>>
>>>>That's just a statement of fact.  I'm not sure what the intentions
>>>>were of their creators, but (however we got here) we find ourselves in
>>>>that situation.
>>>
>>> The text says "By contrast, this document attempts to specify the
>>> syntax and semantics of these headers as they are actually used on
>>> the Internet." That pretty much implies those specifications did
>>> not attempt to do that, which I do not think is a fact.
>>
>>I've removed the "by contrast."
>
> Let me put this another way. Would you be surprised if I could find some
> examples of current real-world settings where the information provided
> in those specifications is sufficient to "make them work"?

The document says:

[[
   However, none of these documents
   describe how the Cookie and Set-Cookie headers are actually used on
   the Internet.
]]

This statement is factually accurate:

1) The netscape cookie spec fails to describe reality because it talks
about a date format that is very rarely used and what it says about
the Domain attribute is complete hogwash.
2) RFC 2109 talks about a Version attribute, which is compete fantasy,
and make a number of claims about the "," character which break the
vast majority of servers.
3) RFC 2965 talks extensively about Set-Cookie2 and Cookie2, which
aren't used by the vast majority of servers.

> If not, then
> we cannot keep the text as it is as it suggests there are none. The
> point is that the current text is overly dismissive and inaccurate and
> fails to adequately explain what is so wrong with those speciciations.

I don't agree.  The purpose of the text in the spec is to explain why
the text in this document isn't consistent with those documents.
Those documents do not reflect reality.  This document is intended to
reflect reality.

> I think it would be entirely sufficient to say, for instance, that at
> time of publication, those specifications are inadequate to interoper-
> ably implement the prevalent Set-Cookie/Cookie mechanism; or for that
> matter say something like "The Cookie and Set-Cookie headers have been
> defined in Netscape and 2109 and this specification replaces them with
> improved whatever based on implementation experience; 2965 defines the
> Cookie2 and Set-Cookie2 headers, those are unaffected by this draft".

Those statements would significantly less accurate than what's in the
current draft.

>>> That depends on how the algorithms later in the draft use the terms; it
>>> seems though instead of "request-host" they use "cannonicalized request-
>>> host" without defining what that is (there is a definition for a "ca-
>>> nonicalized host-name" which depends on "host-name"; perhaps that is
>>> supposed to be the "request-host" but I would have to debug the code to
>>> tell).
>>
>>Host-name is a formal parameter which gets called with request-host as
>>the actual parameter.  You can canonicalize other sorts of hosts, if
>>you like, besides those used in requests (hence the abstract).
>
> Right now the first occurrence of "host-name" is in "A canonicalized
> host-name is the host-name converted to ..." which proceeds without
> saying what a "host-name" is in the first place.

Precisely.  For example "f(x) = x + 1" doesn't proceed to say what "x"
is in the first place.

> The first occurrence
> of "canonicalized request-host" is in "If the domain-attribute is
> identical to the canonicalized request-host:" which proceeds without
> saying how a "canonicalized request-host" is different from just a
> "request-host". The draft needs to say "A host-name is ..." and "A
> canonicalized request-host is ...".

That's like say f(5) doesn't explain how that's different than 5.

>>I'm not sure what that's buying us.  It can use whatever it likes.
>
> Again, the current text is "The origin server is free to ignore the
> Cookie header or use its contents for an application-defined purpose.
> The origin server MAY send the user agent a Set-Cookie response header
> with the same or different information". I believe this is difficult
> to read as you have to jump back from "same information" to "header
> or contents" and have to equate those.

I've changed this phrasing to:

[[
      The
      origin server is free to ignore the Cookie header or use its contents
      for an application-defined purpose. The origin server MAY send the user
      agent another Set-Cookie response header or it MAY send no Set-Cookie
      header at all.
]]

>>> I do not believe that is sufficient to avoid potential confusion es-
>>> pecially as grammar is importing rules from RFC 2616 (for which the
>>> implies LWS rule does not apply...) There should simply be a reminder
>>> that a different notation is used and that the implied lws rule applies
>>> neither to it nor the imported rules.
>>
>>We don't want to alter the semantics of the imported rules.  We wish
>>to import them as languages, not as syntactic representations of those
>>languages.  The semantics of those terms are defined in their
>>respective documents.
>
> The implied lws rule in RFC 2616 has been a source of considerable
> confusion as it implied optional white space where people do not ex-
> pect it and because some rules use it and some rules do not and that
> is not made clear through the grammar but rather through prose and
> thus easy to miss. The draft builds on RFC 2616 but unlike most other
> extension header specifications does not re-use the grammar notation
> defined in RFC 2616 but a very slightly different notation, and then
> the draft imports rules from RFC 2616 where one has to pay very close
> attention to those notational differences and the surrounding prose
> to read the grammar correctly. I do not care much how, but I do think
> the draft needs to draw attention to this to avoid confusion.

Feel free to send me a diff with a proposed clarification.

Adam