Re: [I18ndir] The Unicode version review model and reviewing Unicode 12.1 (was: Re: draft-faltstrom-unicode11-07)

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

(Part of this note is a bit of a rant, for which I apologize,
but it is also an explanation of some comments I made when the
directorate was asked to start on this I-D that some others
claimed were unreasonable... and I think Harald's summary should
reflect those as issues are _are_ related to the current I-D.
Issues on which we clearly agree and don't need further
discussion are elided to keep the note from being even longer.)

--On Monday, March 11, 2019 14:26 +0900 Patrik Fältström
<[e-mail]> wrote:

> On 11 Mar 2019, at 9:01, John C Klensin wrote:
>...
>> (3) There is nothing in the IDNA2008 documents that
>> explicitly specifies this type of review, what it should
>> consist of, or even whether it should produced a report.
> 
> Not explicitly, but, my view is that IF a backward compatible
> rule is to be added to the algorithm, then that addition
> requires IETF consensus as RFC5892 is to be updated.

The requirement for IETF Review for either of those changes is
quite explicit in RFC 5892 Sections 5.1 and 5.2, so no question
or need for an opinion there.  The only questions are what
initiates the IETF Review process (presumably an I-D proposing
the change) and, more important, what initiates a review, what
is to be reviewed, and whether there is any requirement the
proposals for changes have to be initiated by the Designated
Expert.

Borrowing from a previous set of comments before coming back to
this one,

           ------ Rant alert ----

--On Monday, March 11, 2019 14:44 +0900 Patrik Fältström
<[e-mail]> wrote:

>...
> Section 5.1 in RFC5892 says:
> 
> 5.1.  IDNA-Derived Property Value Registry
> 
>    IANA has created a registry with the derived properties for
> the    versions of Unicode released after (and including)
> version 5.2.  The    derived property value is to be
> calculated in cooperation with a    designated expert
> [RFC5226] according to the specifications in    Sections 2 and
> 3 and not by copying the non-normative table found in
> Appendix B.
> 
>    If non-backward-compatible changes or other problems arise
> during the    creation or designated expert review of the
> table of derived property    values, they should be flagged
> for the IESG.  Changes to the rules    (as specified in
> Sections 2 and 3), including BackwardCompatible    (Section
> 2.7) (a set that is at release of this document is empty)
> require IETF Review, as described in RFC 5226 [RFC5226].
> 
> And this is what I have tried to implement.

And that is one of the sections I've read -- five or six times
in the last few days.  No matter how many times I read it, I
fail to find anything more than a hint about a requirement for
reviews with each new major or minor version of Unicode, formal
reports, exactly what is supposed to be reviewed, or whether the
Designated Reviewer has sole and exclusive responsibility or
authority for any of this.  What I do find, albeit also only as
a hint, is that any tables that are produced are to be submitted
to IANA but that they are more of a forcing function for reviews
rather than an event that creates something normative.  I think
we are in agreement about that, but earlier drafts of
draft-faltstrom-unicode11 may have been less clear about it than
they should have been and, more important, there has seemed to
be a good deal of confusion in the community about whatever IANA
has means vis-a-vis implementation requirements and/or
"supported" versions of Unicode.  I think we have an obligation
to try to clear that confusion up, either in
draft-faltstrom-unicode11 or in another document that we produce
and get through the system RSN (rather than dumping it at the
end of a never-moving queue).

I also find one other thing that seems to be more than a hint.
While I don't think "should be flagged for the IESG" is the
particular language we would use today given both changes in the
IETF and the deep expertise and involvement in i18n issues the
IESG has shown recently (and that I suggest may have been part
of both the reason for creating this directorate and the length
of time it took to get it together), it doesn't say "if a
non-backward-compatible change (presumably defined as a code
point whose derived property changes between Unicode versions or
other problem (presumably including the discovery that a code
point exposes an incorrect assumption in the definition of
IDNA2008), then the Designated Expert gets to decide whether the
change or problem is significant and report only if it is".
What is says, as I read it, is that all such issues are to be
"flagged for the IESG".  Given the way the IETF is supposed to
work, it is then the responsibility of the IESG to figure out,
on a timely basis, how to make a decision that is consistent
with IETF consensus.  In doing that, it is entirely reasonable
for them to consider any advice the Expert provides and any
other advice they get or solicit.  If they conclude that the
conclusion is obvious or the decision trivial, it is reasonable
for them to make the decision and announce it (so as to allow
for appeals if others seriously disagree).  Otherwise, I think
they need to ask the community through something equivalent to
an IETF Last Call, possibly with a WG along the way.

Now, "alerting the IESG" was exactly what we were trying to do
when we posted draft-klensin-idna-5892upd-unicode70-00 in the
middle of 2014.  We alerted the IAB too.  The IAB statement six
months later was, in this context, another alert to the IESG.
Arguably the requests for what became the LUCID and I18NRP BoFs
were more alert attempts even though they had other functions.
What we haven't gotten is a path to resolution of either the
issues identified 4 1/2 years ago or the changed-property code
point you have identified now.   For the latter, perhaps
approval of draft-faltstrom-unicode11 is such a resolution, but
there are problems with that approach:

(i) Nothing in IDNA2008 says that, after being alerted, the IESG
can choose to address one problem but ignore others.  I'm all
for pragmatism and not artificially blocking progress, but that
is worth keeping in mind.

(ii) While I think the explanation in -08b01 is a vast
improvement (and adequate, modulo (iii)), I don't think any of
us who find backward-incompatibilities or other problems get to
say "X is not a problem because of <rule>" and therefore no
action is required", especially when the rule is not supported
by the IDNA2008 specification.  The text in -07 and earlier was
fairly close to that.

(iii) While we've all done it and the many advantages of keeping
things in context suggest that we will continue to do so, there
is an inherent risk of burying (however unintentionally or with
good intentions for editorial clarity) a substantive action in
the middle or what is otherwise just a report -- and one that is
inevitably a little tedious at best.  If someone were to post a
report on comparative IETF traffic statistics with many sections
saying "same as last time" and then include nearly 70 pages of
appendices with, shall we say, very little plot or action, but
insert "The IETF has consensus that interplanetary networking is
all a hoax", I'd guess the odds of that document surviving IETF
Last Call, review team reports, etc., without anyone noticing
and complaining about that ridiculous statement are reasonably
high.  So I would urge that Last Call announcements for this
report and ones like it should explicitly call out the fact that
a decision is being made about whether to preserve backward
compatibility or compatibility with Unicode for a particular
code point whose derived property changed.  Unless we produce as
separate document to address just that one issue and process it
separately, I think a claim of IETF consensus about what to do
about that code point is bogus unless that is called out in the
IETF LC announcement.

And, fwiw, the above is exactly why I argued strongly that it
was unreasonable and inappropriate to move forward with Last
Call and approval of draft-faltstrom-unicode11, at least in its
-07 form, unless known issues and the documents that described
them were examined first.  In retrospect, I should have also
stressed that the IANA registry and associated tables were not
normative and therefore I didn't understand the apparent hurry
after sitting around and making no progress --and with the IESG
apparently not troubled by that -- for years.   I think -08 is
moving rapidly toward that point of incorporating workarounds
for those issues but -07 really was not ready and, whether
because the workarounds represent significant changes or because
we fold in information about Unicode 12.0, I assume we are going
to end up with a second IETF LC, probably on about the schedule
we would have had if we had looked at those other issues first.

       --- end rant alert -----

> The implementation of this have been for me to flag when the
> following happens:
> 
> 1. A new version of Unicode is released
> 2. Code points are added and some have changed data
> 3. Calculation of IDNA2008 derived property value is made
> 4. Validation that all derived values that have changed is
> from UNASSIGNED to something else, if a derived property value
> changes that originally was NOT UNASSIGNED, then I feel IETF
> discussion is needed

quite reasonable.

> It can also happen, which have happened at least once, that
> myself or anyone else, when doing manual inspection of the
> Unicode Tables do see something "which is weird". This was the
> case that resulted in IAB talking about "the Hamza above"
> issue.
> 
> If applying 1-4 above, there is a block when going to Unicode
> 11, there was when going to Unicode 6, but for example not to
> 10 or 12.

Right.  That leaves the question of whether one can progress
beyond Unicode 7 without resolving the block identified there.


>> (4) If there is a bias in the
>> documents between "follow Unicode" and "preserve backward
>> compatibility" is to toward the latter.
> 
> This implies we SHOULD add a rule.

Probably so, at least in the interest of clarity.  My assertion
that the specification creates a bias in favor of backward
compatibility, rather than following Unicode, is based on the
text in the middle of the Introduction that ends with "Moreover,
even if such changes were the result, the BackwardCompatible
list (Section 2.7) can be adjusted to ensure the stability of
the results" and the first sentence of 2.7, which says "includes
the code points" rather than the "can be adjusted" above and the
"can be updated" of the next sentence of 2.7.  Clearly the IETF
can decide that other considerations (track Unicode versions
included) are more important than stability but it is a choice
and "well, we will just follow Unicode" doesn't do it, at least
without some serous discussion and presumably an update to 5892
to discuss just when stability is more important.

>...

   best,
     john