Re: [http-state] parser rules of draft-ietf-httpstate-cookie-22

["Roy T. Fielding" <[e-mail]>]

On Feb 23, 2011, at 2:57 PM, Peter Saint-Andre wrote:
> On 2/23/11 3:07 PM, Roy T. Fielding wrote:
> 
> <snip/>
> 
>> Therefore, I would like you to change the ABNF so that it
>> reflects the reality of (Set-)Cookie usage on the Internet,
>> for the same reason that you have insisted the algorithm
>> for user agent parsing reflects reality.  Changing the ABNF
>> to include base64 does not do that -- it is just another
>> fantasy production that differs from all prior specs of
>> the cookie algorithm.  Changing it to
>> 
>> cookie-value      = %x21-2B / %x2D-3A / %x3C-7E / %x80-FF
>> 
>> or just the minimum
>> 
>> cookie-value      = %x21-2B / %x2D-3A / %x3C-7E
> 
> Hi Roy,
> 
> The latter seems fine, and in conversation with Adam he indicated to me
> that he would not object to such a change.

Okay by me.

> However, I see no reason to include characters from the Unicode range
> U+0080 to U+00FF in cookie-value. Among other reasons, characters above
> U-00A1 would introduce the need for internationalization considerations
> of the kind that have derailed many a standardization effort (e.g., in
> Unicode U+00BE undergoes compatibility decomposition). Let's avoid that
> can of worms if at all possible...

According to the cookie protocol, the value is not characters:
they are just opaque octets.  Generally speaking, i18n considerations
do not apply to opaque OCTETs, though I have no reason to object to such
an exclusion because it is consistent with httpbis recommendation to
avoid the use of %x80-FF in any HTTP header fields.  I do not know
of any use in practice.

....Roy