Re: [art] [I18ndir] Modern Network Unicode

Hi,

Carsten - thanks for working on this MNU draft.

John - thanks for you excellent background comments.

FWIW - IEEE-ISTO PWG 5100.3 IPP Everywhere (a very widely implemented
driverless printing profile of IETF STD92 Internet Printing Protocol 1.1
and a few
other PWG IPP extensions) makes RFC 5198 and NFC normalization mandatory
for IPP Server generated names, keywords, and text strings and mandatory
for
IPP Client submitted names and keywords.  But IPP's purpose is reliable
document
printing (the document content may, of course, be in some legacy charset,
but must
be tagged) and most string attributes are names (like job names) or keywords
(fonts, media, etc.), so pure NFC w/ restricted C0 characters makes sense.

IPP Everywhere does have this warning in Internationalization
Considerations:

"WARNING – Performing normalization on UTF-8 strings received from IPP
Clients and
subsequently storing the results (e.g., in IPP Job objects) could cause
false negatives in
IPP Client searches and failed access (e.g., to IPP Printers with
percent-encoded UTF-8
URIs now 'hidden')."

Which speaks to John's point about the disadvantages of automatic NFC
(or any other normalization).

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Co-Chair - TCG Metadata Access Protocol SG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: blueroofmusic@gmail.com
PO Box 221  Grand Marais, MI 49839  906-494-2434

On Thu, Jul 11, 2019 at 1:25 PM John C Klensin <john-ietf@jck.com> wrote:

>
>
> --On Thursday, July 11, 2019 18:44 +0200 Carsten Bormann
> <cabo@tzi.org> wrote:
>
> > On Jul 11, 2019, at 18:31, John C Klensin <john-ietf@jck.com>
> > wrote:
> >>
> >> (top post and adding the ART list back in)
> >>
> >> Carsten,
> >> I think Asmus and I are in complete agreement, but you might
> >> find an attempt to summarize the state of work for relevant
> >> characteristics and behaviors on the web, some of which
> >> interact with this discussion, illuminating.  It is a chart
> >> with explanation, not a long document.  See
> >> https://w3c.github.io/typography/gap-analysis/language-matrix
> >> .html
> >
> > Thank you for this interesting link.
> > This is very condensed information; what column should I look
> > for specifically on the issue of normalization and
> > applicability of NFC? E.g., in the linked page
> > https://w3c.github.io/iip/gap-analysis/beng-gap I find
> > something about grapheme clusters but nothing about
> > normalization — normalization of course is not an immediate
> > need for Web interoperability.
>
> I'll try to hunt for it when I have time unless someone else
> gets to it first, but there are W3C recommendations that
> specifically recommend against trying to insert a normalization
> step before transmission or immediately before storage but
> focusing on it as a comparison-time operation.   That is
> consistent with what Asmus and I have been trying to tell you.
>
> Let me try to summarize those comments in a different way:
>
> (1) For most language-script combinations, the form in which a
> network application gets a string is usually going to be the
> right form for that string.  If there is a strong preference
> that the string be normalized, it will probably come to the
> network application (and probably when it leaves something
> rather close to the keyboard) normalized.  If there is a strong
> preference that it not be normalized, it will probably come to
> you in _that_ form.  If there is no preference at all,
> normalizing the string (as long as you stay away from NFKC/NFDC)
> will probably not cause harm, but it won't buy much either.
>
> (2) Checking as to whether a string is normalized before sending
> it is unlikely to produce any safely actionable information
> unless you know a lot about the language, script, and
> circumstances.
>
> (3) If a string is unnormalized for what whomever created it
> thinks is a good reason, then normalizing on general principles
> is going to lose whatever information that decision was intended
> to convey.
>
> The above may be different for strings that are specifically
> intended as identifiers, but I don't think that is what you are
> talking about.    I used to believe that "normalize everywhere"
> and "store strings only in normalized form" was a good idea, but
> I've been gradually (and sometimes quite unpleasantly) educated
> by a long series of cases and counterexamples.   If I were
> updating 5198 today, that recommendation is the thing I would be
> most likely to either change or at least moderate and qualify
> considerably.
>
>     john
>
>
> _______________________________________________
> art mailing list
> art@ietf.org
> https://www.ietf.org/mailman/listinfo/art
>