Re: [I18nrp] Last Call: <draft-faltstrom-unicode11-05.txt> (IDNA2008 and Unicode 11.0.0) to Informational RFC

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

--On Tuesday, December 4, 2018 08:16 +0100 Patrik Fältström
<paf=[e-mail]> wrote:

>...
> The process I have used for each version of Unicode is the
> following:
> 
> 1. Unicode releases beta versions of Unicode
> 
> 2. I calculate the derived property values and do a diff
> 
> 3. I report the result to IAB and whatever I feel is the most
> recent IDNA-related mailing list in the IETF
> 
> 3.1. If there are no incompatible changes, I say so and simply
> suggest I will report to IANA "to move on" -- and if I do not
> hear anything within say two weeks, I simply do so
> 
> 3.2. If there are incompatible changes, I say so to and
> suggest an I-D that include my and others review of the
> situation

Patrik,

I think these are the right steps.  As far as they go, they are
certainly consistent with what the specs require.   There are,
IMO, two weaknesses which might interact with Paul's concerns
(or not):

(a) You are talking about a relatively mechanical process.  The
review anticipated by IDNA2008 is supposed to also identify new
code points that, because it is possible that the needs of IDNA
may differ from the criteria used by UTC in assigning new code
points and corresponding properties, may need to be identified
as exceptions or assigned to one of the CONTEXTx categories.  No
calculation check such as the ones you describe is going to
detect those cases; detecting them requires manual checking of
the newly-assigned code points and whatever rationale Unicode
provides for them.  It may be worth noting that, whatever the
merits of the observations that caused the original IAB
statement and the non-deoomposing character discussion, that
case was detected by precisely such a manual check, not the
procedure outlined above.  We need both.

Incidentally, if Asmus's comments about the insufficiency of the
CONTEXTo model for a range of problems is correct, we should be
looking at whether IDNA2008 is in need of changes/ updating.
Those changes might turn out to be substantive or as minor as
making it much more clear that what IDNA2008 permits is a
superset of what should be allowed in a particular zone and who
has responsibility (and accountability) for selecting a
zone-specific subset (aided by whatever hints we can provide).
It seems clear to me that we should not process this document
until we have answers to, or at least much more clarity about,
that issue.  YMMD.

(b) With this list supposedly dedicated to procedural
discussions (at least until the ADs or Directorate change that)
and the IDANbis on focused on the protocols and almost
completely dormant, the only place in the above procedure in
which the manual checks can be expected to be performed (or at
least assured) are as part of  "report... to the IAB".  However,
if the IAB has higher priorities and has opted out, lacks the
time and energy, lacks the expertise and does not have a Program
with the expertise, the odds of that review getting done (and
producing a report that the community can review) are probably
slight to none.   My hope going into the BOF was that a model
would emerge that would be able to support, manage, or actually
perform those reviews.  Because the Directorate has not been
established and we don't know either its formal charter or its
membership, much less its priorities, it is impossible to know
whether it will be able to fulfill that role.  However,
advancing this document before either  there is evidence that
the manual reviews have been carefully and competently performed
would seems to me to violate the intent of the standard.

best,
    john