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

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

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

> On Tue, 4 Feb 2020, Patrik Fältström wrote:
>>> And omission of a clear model for specifying what is really
>>> what we call a "charset" elsewhere (not just an encoding) is
>>> the one clear defect in that particular discussion in the
>>> document.
>> 
>> Don't forget normalization or otherwise how comparison is to
>> be done of the UTF-8 encoded characters in the string.
>> Nothing about that either.
> 
> 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.
My highly abstracted (but I hope not far off the mark) view of
Patrik's comments is that, if one is going to compare or sort
strings --or do much else with them other than maybe displaying
them -- is that one needs a plan other than the equivalent of
"just use UTF-8".   Fairly recent W3C discussions, a few around
ICANN, and comments in TUS about script-specific or
language-specific rendering, strongly suggest that a more
specific plan is needed even to display strings reasonably in
some scripts and circumstances.

Note that this is another example of a situation in which the
problem exists even with basic Latin characters and moving
beyond them just makes the situation more important or worse or
the examples more dramatic.  The obvious case involves sorting
strings into alphabetic order: one has to decide what to do
about case mapping or ordering, what to do about spaces or other
punctuation, and so on.

Where Patrik and I disagree (if we disagree at all - I may have
misread his intent) is whether this particular document needs to
say anything on the subject or anything beyond "definitions for
individual header fields need to include an analysis and
guidance for those issues".

I also think that, in our capacity of giving advice to the ART
ADs, there is an important lesson here and that is that _any_
document that even hints at non-ASCII characters, even if the
hint is nothing more than "don't do that unless you have to"
MUST get serious review by experts in i18n issues, not just the
WG that happens to be writing the spec.  That, in turn, almost
certainly implies the need for an organized and functioning
directorate, not just one to which one of those on the list can
post a note (as Martin did) and hope for responses from the
usual suspects.  Or, if they can't make such a directorate work,
either some other plan to accomplish the same thing or explicit
acknowledgment that IETF work on these is not getting
sufficient, and sufficiently skilled, review to be trusted.

Watch for what may be a more complicated example soon.

   john