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

[John C Klensin <[e-mail]>]

--On Tuesday, February 4, 2020 11:51 -0500 John R Levine
<[e-mail]> wrote:

> On Tue, 4 Feb 2020, John C Klensin wrote:
>>> NFC is specific to UTF-8.  MIME doesn't have that as far as I
>>> know so I don't think it makes sense here.
>> 
>> Huh?   NFC is certainly specific to Unicode, but there is
>> nothing specific to UTF-8 (or any other encoding form) about
>> it.
> 
> Sorry, I meant specific to Unicode.  If there is some old page
> in big5 or ISO-2022-x, there aren't any normalization rules
> I'm aware of.

IIR, Big5 would not need one because it is strictly Traditional
Chinese Character.  As soon as one has something that would
contain both Traditional one for which Simplified forms exist
and those Simplified forms, one _may_ need a mechanism for
comparing them equal, but that wouldn't be normalization in the
Unicode sense either [1].   If by "ISO-2022-x" you mean either
ISO 8859/x or code pages that can be accessed or switched by ISO
2022 methods, definitely no normalization for the first case and
probably not the latter because at least most of them were
designed to avoid the problems (like composing character
sequences) that normalization addresses.

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

Ack.

   best,
    john

[1] In retrospect, Unicode's using, and effectively preempting,
the terms "normalization" and, especially, "canonicalization"
for very specific purposes in the context of their standard
because it makes any use of, for example, "canonical form" in
describing a string or identifier ambiguous as to whether
Unicode canonicalization (as in NFKC) or some other set of rules
was intended.  Having, or converting to, some "normal form"
isn't much better.  Nothing can be done about that now, but it
means we should remind ourselves that we need to be very careful
to be clear when we use of those terms or similar ones.