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

[Bjoern Hoehrmann <[e-mail]>]

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

>On Thu, May 27, 2010 at 7:33 AM, Bjoern Hoehrmann <[e-mail]> wrote:

Please do not lump replies to multiple messages into one message. This
is a discussion list and discussions become very difficult to follow if
you cannot track replies properly.

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

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

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