Re: [I18ndir] Getting restarted and triage

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

--On Friday, June 21, 2019 19:34 -0700 Asmus Freytag
<[e-mail]> wrote:

> John,
> 
> some of us don't have the time to thrash to death things like
> Patrik's draft over minute issues, like whether to consider
> the single DISALLOWED character for Unicode 12.1 a technical
> omission.

Which absolutely no one, AFAICT, but especially not either
Patrik or myself, has suggested.  

In more abbreviated form which I thought would be clear to
everyone here, but let me spell it out a little more, all I have
said about 12.1 is that (i) there are no changed in property
values compared to 12.0, (ii) there is only one new code point,
and (iii) that code point behaves exactly the way IDNA2008
assumes/ believes it should, i.e., the grapheme (and, because it
is a CJK code point, its approximate interpretation) can be
constructed under 12.0 (and earlier) by a code point sequence
and the next code point therefore decomposes under NFC.
Conclusions (i) and (ii) are the algorithmic review; (iii) is
the new code point review.  So, nothing to be done about that
code point and, other than maybe adjusting some terminology,
nothing that isn't already in draft-faltstrom-unicode12-00.

What does need to be adjusted -- and needs to be adjusted
whether we include 12.1 or not -- is the discussion of the basis
for making decision when they need to be made.  That has nothing
to do with the new code point.  See Patrik's note.
> 
> If we can't find ways to remove this artificial friction, we
> won't see more vigorous involvement.
> 
> Notably, such hyperfocus on minutiae of little practical
> impact is absent from successful projects in the i18n arena.

If I understand what you are concerned about -- and, given that
I believe that your complaint above is about a strawman that was
not even in sight, I may not -- let me review why this (both my
note and Patrik's) is important given the design of IDNA2008.
As we know from IDNA2003 and the Unicode Standard itself, it is
possible to define how to handle code points in a variety of
contexts by simply making a list of all of the code point in
Unicode and assigning properties (and, implicitly,
appropriateness in various contexts, to each.  The IETF
concluded that choice was inappropriate for IDNs and IDN labels
and that the best alternative (or, if you prefer, the least-bad
one) was to construct a system based on a series of rules and an
algorithm, one that had provisions for differences in
short-string, language-independent, requirements of the DNS and
requirements that are more typical of the broad range of Unicode
applicability.  Maybe that was the wrong decision or just one
that was hopelessly naive and we should un-do it, but I've seen
no proposal to do that and how to do so.  If we are to stay with
it, the algorithms and surrounding rule sets much be orderly and
stay that way, and that --and, again, not any single code point
in 12.1 or otherwise-- is what this is about.

best,
   john