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

[Adam Barth <[e-mail]>]

On Mon, May 31, 2010 at 6:54 AM, Bjoern Hoehrmann <[e-mail]> wrote:
> * Adam Barth wrote:
>>>>> 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.
>>
>>Ok.  I've left these as is.
>
> Assuming Julian's point is about the "A-Z" comment above, that is not my
> concern at all. The current text already has expansions, but they are
> misleading (for example, it calls `ALPHA` just "letters", but there are
> many letters that `ALPHA` does not include). I am fine with omitting the
> current expansions alltogether, but would prefer using ABNF syntax as
> above, regardless of the "; A-Z / a-z" comment, as that is more readable
> and a convention the document uses elsewhere.

This text comes verbatim from HTTPbis:

http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-09#section-1.2

Is there a better role model that I should follow?

>>> Drawing attention to the obvious should be avoided as readers would have
>>> to expend additional effort to confirm that what is being pointed out is
>>> indeed obvious -- and not some subtlety they've missed -- for no gain.
>>> If a specification replaces two older ones based on implementation ex-
>>> perience, then it is obvious that the older specifications do not re-
>>> flect current practise equally well.
>>
>>Hopefully the added citation to Kristol's missive should suffice.  The
>>old spec are actively harmful.  This text is meant to reassure the
>>reader that we're contrite for our previous sins and are trying to do
>>no harm in this document.
>
> I do not believe that is sufficient. I believe I've explained why I
> think the current formulation is inadequate and I've made suggestions
> how to rephrase it. If you have no suggestions how to rephrase it in a
> manner we can agree on, I am happy to raise this issue again during IETF
> review, perhaps others have some suggestions.

Ok.  I stand by the current text as factually accurate.

>>> In the context of "hosts" the term "canonicalized" is overloaded with
>>> definitions, RFC 1123 for example defines it quite differently than
>>> draft-ietf-httpstate-cookie-08.txt.
>>
>>I've changed the text to define a "canonicalized string", which should
>>emphasize that the name of the formal parameter is irrelevant.
>
> I will revisit this later.
>
>>> Further, the permissable range of values for `request-host` is larger
>>> than the apparent domain of the draft's `canonicalized` "function".
>>> For instance, the "host" can be an IP-Literal, but you cannot apply
>>> the ToASCII function to those -- they are outside its domain.
>>
>>Ok.  Well, I'm happy to write whatever you like in that part of the
>>spec.  The point is we need the puny code version of the host name.
>>When I wrote that before, someone complained that I couldn't use the
>>words "puny code" in that way, so I adopted the text they recommend.
>>Now I'm told that I can't use the text they gave me.
>>
>>This text is really trying to accomplish a very simply task, which is
>>to obtain the lower case, puny code version of a host name from a URL.
>> In code, this is as simple as writing "url->host()".  Let me know
>>what the magic phase is, and I'm happy to appease.
>
> I am happy to make a suggestion once there is a proper definition for
> `request-host`.

Here's the definition of request-host:

[[
        <t>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.</t>
]]

Is that definition improper?  What would a superior definition be?

> If you start from a resource identifier, this will most
> likely need a condition (if it is non-ascii and represents an IDN, then
> transform into the IDNA encoding) and an exception handler (if trans-
> formation fails, then...; I do not know what is to happen in that case
> though).

We need to start with an HTTP request.

>>>[ABNF vs RFC 2616 grammar differences]
>
>>Would you prefer that line said something else to clarify that we
>>really mean the ABNF notation of RFC5234 as opposed to something else?
>> Would you like that text copy/pasted to every location where we use
>>an ABNF grammar?  I'm happy to review a diff to the spec.
>
> Copying the rfc1123-date grammar from draft-ietf-httpbis-p1-messaging-09
> into an appendix would probably be the best solution as differences with
> case-sensitivity and white space would then no longer be a source of
> confusion. Otherwise there simply should be a reminder that the grammar
> notation is different from RFC 2616 and care must be taken to apply the
> right rules for imported symbols.

I've add the following text near the use of 1123-date:

[[
sane-cookie-date  = <rfc1123-date, as defined in RFC 2616>
                    ; Note that RFC 2616 uses a different grammatical notation
                    ; than this document (which uses ABNF from RFC5234).
]]

Hopefully that addresses your concerns.

Adam