Re: [I18ndir] Version 2: Directorate review of unicode11-07

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

Sorry Martin, should have read this before sending my most
recent note.  Inline below...

--On Tuesday, March 12, 2019 23:45 +0000 "Martin J. Dürst"
<[e-mail]> wrote:

> Hello Patrik, others,
> 
> On 2019/03/12 22:15, Patrik Fältström wrote:
>> On 12 Mar 2019, at 19:30, Martin J. Dürst wrote:
>> 
>>> How will you or the IETF tell everybody else that it is okay
>>> with Unicode 12.0.0?
>> 
>> I do not have to. The algorithm is normative. I tell IESG if
>> I see potential issues with a version. Otherwise I am quiet.
>> 
>>     Patrik
> 
> It may be that that's what the RFC(s) say, and that's what was
> intended,  but at least to me, that would look like a protocol
> design error. I'd be  very disappointed if the IETF made such
> an error.

Agreed, especially given that something should trigger the
opportunity for a review of the new code points even if that
isn't assigned to anyone in particular and we decide to let
things go if no one speaks up after a reasonable period.   On
the other hand, even "let things go" would require an update to
5982 as I read it and that is why Harald's suggestion about a
new document that describes the review procedure and our
expectations of it seems important as well as useful.

> Now after checking RFC 5892, it seems that the story is
> slightly better.  To see whether Patrik checked the latest
> Unicode version and is okay  with it, one has to check 
> https://www.iana.org/assignments/idna-tables-6.3.0/idna-tables
> -6.3.0.xhtml#idna-tables-properties.  There one sees a
> reference which currently reads "[Unicode Character  Database
> 6.3.0]". If that reference gets updated, then that's the
> canary  that indicates that a newer version of Unicode has
> successfully passed  Patrik's checks.
> 
> Did I get that right? If yes, it would be good to make that
> clear in the  draft we are working on.

Not a very good canary because there is that requirement for a
review of the new code points.    While I don't remember when
(although I can guess) or in what context, I have a very clear
memory of Patrik saying that he was willing to automate and do
the comparison for changes in derived property values but not
the review of new code points.  The latter job was, IIR, never
assigned to anyone in particular.  I looked through 6.x before
RFC 6452 was published; I have a vague recollection that maybe
Paul Hoffman did so too.  And I looked through 7.0, which is how
the apparent combining Hamza irregularity was first spotted.
Then I stopped because, if the community could not deal with the
issues raised in draft-klensin-idna-5892upd-unicode70 [1], there
seemed little point.

So, while the current information for 6.3 is consistent with
both reviews having been done, if the I-D causes a table to be
posted with information for 11.0 (and/or 12.0), it would
indicate only one of the reviews was performed.

In addition, if we expect people to be able to pull tables from
IANA that correspond to whichever version of Unicode they are
running (which is the IDNA2008 requirement) those other tables
are either not on the IANA site or are beyond my limited ability
to find.

We really need to get our ducks in a row about those files as
well as the review process.  Assuming we can figure out what we
want to do (I agree with Harald that it should not be hard),
sorting all of the needed record-keeping out should be
straightforward.  

But, again following Harald's lead, let's think in terms of a
separate document rather than putting work in the critical path
to getting draft-faltstrom finished (in either a unicode11 or
unicode12 version).  That does require being clear enough about
what we are doing going forward that we don't end up with
confusion text in draft-faltstrom but, even if we can't reach
agreement in principle quickly, I can think of several ways to
do that.

best,
    john