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

[Bjoern Hoehrmann <[e-mail]>]

* Adam Barth wrote:
>> Later in the section, there should be a bibliographic reference for the
>> "Netscape cookie specification".
>
>I'd be happy to add this if you let me know what citation you think we
>should use here.  The problem is that I don't know of a canonical URL
>to cite now that the original Netscape site is defunct.

It does not have to include an address, something like 'Netscape
Communications Corp., "Persistent Client State - HTTP Cookies"' would
do. http://wp.netscape.com/newsref/std/cookie_spec.html should be the
address, the Internet Archive has archived copies of it, and it should
be fine to cite the Internet Archive address (at least I did do that
in RFC 4329 for the JavaScript reference manual).

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

>> 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
>>  ...
>
>I looked a bunch of RFCs and this didn't appear to be that common.
>I'd be happy to do this if you can show me three relatively recent
>RFCs that use this pattern.

RFC 5536, RFC 5537, RFC 5538. The draft itself does this for other
rules, like for `token`.

>> 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.
>
>I find it completely ridiculous that the specs make it so hard to say
>what URL and host we're sending a request to, which would seem to be
>the two most important things about an HTTP request.  Hopefully
>someone will chime in with the magic incantation we're supposed to use
>here.

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

>> 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.
>
>It just means the server can send whatever it likes, including things
>that are the same or different from what it sent before or not sending
>things at all.

Well at the least add after "The origin server MAY send the user agent a
Set-Cookie response header with the same or different information" some-
thing like "as in the Cookie header it received in the request when re-
sponding to it". Or better perhaps something like "The server may use
the information in a cookie it receives to send a new Set-Cookie header
or it may send no Set-Cookie header at all".

>> At the end of section 3 it should be pointed out that the do-not-fold
>> rule is inconsistent with RFC 2616.
>
>This is pointed out in HTTPbis.  At worst, this inconsistency will
>exist for only a short time.

So long as RFC 2616 is a normative reference of this draft, it needs to
call out contradictory requirements.

>> 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.
>
>We already say that:
>
>        <t>This specification uses the Augmented Backus-Naur Form (ABNF)
>        notation of <xref target="RFC5234"/>.</t>

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.

>> 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.
>
>I've removed this paragraph (which I think originated in 2109) and
>replaced it with the following:
>
>          <t>The semantics of the cookie-value are not defined by this
>          document.</t>

That is better.

>> 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".
>
>This seems like an editorial issue.

Yes, I agree it is an editorial issue.
-- 
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/