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

[Bjoern Hoehrmann <[e-mail]>]

* 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"? 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 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".

>> 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. 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 ...".

>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 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.
-- 
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/