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

[Julian Reschke <[e-mail]>]

On 26.05.2010 22:45, Adam Barth wrote:
> ...
> On Wed, May 26, 2010 at 10:22 AM, Bjoern Hoehrmann<[e-mail]>  wrote:
>>   Some comments on draft-ietf-httpstate-cookie-08.txt:
> ...
>> 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.
 > ...

I agree that this needs a citation, even if we can't provide the 
original URI. Proposal: create something on purl.org (I know the RFC 
Editor is likely to accept that), and let it redirect to the best copy 
we can find. If that breaks, we still can update the purl.

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

That statement is kind of confusing to people who do not already know 
the history.

Maybe it would make sense to cite

[Kri2001]	Kristol, D., “HTTP Cookies: Standards, Privacy, and Politics”, 
ACM Transactions on Internet Technology Vol. 1, #2, November 2001, 
<http://arxiv.org/abs/cs.SE/0105018>.

to give some more context.

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

Adam is right; not expanding the RFC 5234 base rules is quite common.

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

If you're willing to wait for httpbis, "Effective Request URI" might be 
the right thing 
(<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#effective.request.uri>).

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

I also have to point out that this use of MAY is irritating; just state 
that this is optional behavior.

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

HTTPbis currently says:

"Note: The "Set-Cookie" header as implemented in practice (as opposed to 
how it is specified in [RFC2109]) can occur multiple times, but does not 
use the list syntax, and thus cannot be combined into a single line. 
(See Appendix A.2.3 of [Kri2001] for details.) Also note that the 
Set-Cookie2 header specified in [RFC2965]  does not share this problem." 
-- 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#rfc.section.3.2.p.7>

So the Cookie spec has an additional requirement compared both to RFC 
2616 and HTTPbis, and that should be pointed out (and explained!).

> ...
>> The grammar makes reference to "abs_path", but does not define what it
>> is.
>
> I've just made this<any CHAR except CTLs or ";">.

Is this supposed to be the same as abs_path in RFC 2396? If it is, RFC 
3986 has replaced this with path-absolute. More consistency with these 
specs would be good.

> ...
> I've removed the concept of a cookie store from this section because
> it's not needed to explain what's going on.
> ...

It's good that you already improved the spec; can you please post this 
somewhere (not as new ID!), so people doing the LC review can check 
whether something has already been addressed?

Best regards, Julian