Re: [I18ndir] Working Group Last Call: Structured Headers for HTTP

["Patrik Fältström " <[e-mail]>]

On 4 Feb 2020, at 20:24, John C Klensin wrote:

>> I think we agree, normalization is a level up from what
>> they're describing here.
>
> Ack.

Ok, I have tried to really understand what they are doing here, and it feels like if Unicode was pasted in after they had designed the whole thing.

Look for example at B.1 when they compare with JSON. They say one advantage of their format is that JSON do allow Unicode data which gives interoperability issues, but they do allow it themselves as well.

Then this is 3.3.3:

> Unicode is not directly supported in strings, because it causes a
> number of interoperability issues, and - with few exceptions - header
> values do not require it.

How do they know header values do not need it -- with a few exceptions?

> When it is necessary for a field value to convey non-ASCII content, a
> byte sequence (Section 3.3.5) SHOULD be specified, along with a
> character encoding (preferably [UTF-8]).

I think that the default encoding MUST be UTF-8 OR specified explicitly.

I further think it should be noted comparison of parameter values is NOT specified in this base specification as normalization might create non-interoperability. If needed, the specification of the header must say how comparison is managed.

I also think 4.2.7 should mention the resulting sequence of the parsing of a binary structure might be a UTF-8 encoded string with a reference to 3.3.3.

I.e. I find it hard to read (and understand why I misunderstood this at first) that the only mentioning of Unicode and UTF-8 is in "string" but the only thing it does is to reference byte sequence, which in turn do never talk about it. Neither at serialization or deserialization. So where UTF-8 strings are described thet are not mentioned.

But ok...you are right.

   Patrik