Re: [I18ndir] Getting restarted and triage

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

Dear esteemed and rapidly-moving secretaries,

Noting that tomorrow makes a month since you sent your "get back
to work" note, that there has been nothing more from you or
anyone else, and that things seem to be moving at the nearly
same rate they were after last summer's BOF, I thought I'd check
back in and tell people, more or less as a heads-up, what Patrik
and I have been up to.  Some news:

(1) Patrik and I have been working on a document that clarifies
and cleans up the new Unicode version review process that was,
in retrospect, not very well specified in RFC 5892.  The I-D
identifies the two types of reviews, explained expectations, and
clarifies the role of the IANA tables.  It probably needs one
more pass by each of us and then will be posted as
draft-klensin-idna-unicode-review.  

(2) One thing that document notes is that RFC 5892 very nearly
requires that, if Unicode changes code point properties in a way
that changes the IDNA2008 derived property, we adjust IDNA2008
to preserve IDNA stability and consistency rather than following
along with Unicode.  That is consistent with the promises we
made to the registrar community about preserving stability.  It
is also the exact opposite of what we have actually done with
the Unicode 6.x, 11.0, and 12.0 reviews.   For future versions
of Unicode, we propose to revert to the specified behavior in
which stability for IDNA is at least a strong preference. 

If that is what we do, it may add yet another irony to the
collection around things that are called IDNA.  IIR, the
original core reason for the creation of UTR#46 was that
IDNA2008 wasn't forward compatible enough with IDNA2003.  The
UTR#46 model was that if a label or potential label was valid at
one point, it needed to be valid forever.  When we track Unicode
changes --as we and UTR#46 have been doing-- we create
instability for IDNA label validity.  If we start favoring the
preservation of label validity (and invalidity) as 5982
specifies, then the gap between IDNA2008 and UTR#46 almost
certainly increases.

(3) If anyone hasn't noticed, Unicode 12.1 has been published.
Only one new code point since 12.0 and it decomposes properly
and there are no other changes, but we need to decide whether we
are reviewing, publishing summaries about,  abd publishing IANA
tables for, interim (i.e., NN.x, x not zero) versions of
Unicode.   The I-D mentioned above will have some text about
that, but we are open to different conclusions than it proposes.


(4) I'm working on a draft that explicitly addresses assumptions
that were made in the IDNA2008 design that have turned out to
not be true or not work as expected.  It is partially a
follow-on to draft-klensin-idna-unicode-7-0-0 but without a lot
of the details and alternatives about non-decomposing
characters.  Watch for something that will probably be called
draft-klensin-idna-architecture-00 in the fairly near future
(unless I shift to directorate time, in which case you should
expect it in early 2020).  

(5) draft-klensin-idna-architecture, discussed above,
necessarily contains a reference to
draft-klensin-idna-rfc5891bis, the registry restrictions
document, so that should be on someone's agenda too.

(6) I suspect draft-klensin-idna-unicode-7-0-0, or at least
those details, of the non-decomposing character issues, should
be published for the historical record, so it would be good for
people to start thinking about that and what should be in it.

That brings me to a key question.  Noting that the main reason
for proposing the BOF that led to this directorate was to try to
get work on core I18N, and especially IDNA, issues under
control, my preference would be that the directorate take a look
at the drafts mentioned above (and probably Asmus's work on
troublesome characters, etc.) and make a recommendation to the
ADs about how to handle them.   An alternative would be for us
to introduce the drafts on the IDNAbis WG mailing list and then
pass them directly to the ADs with a request for AD sponsorship
and, if needed, a short-term restart of that WG, which would get
them to the directorate that way.   There is a Plan C, but I'm
quite confident that almost no one would like it.

So, Glorious Leaders and other directorate participants, how
would you like to proceed?  

     john


--On Tuesday, May 14, 2019 13:01 -0500 Pete Resnick
<[e-mail]> wrote:

> Greetings,
> 
> Your faithful secretaries are getting off of their respective
> rear-ends to get this directorate doing its regular
> directorate duties. This means reviewing documents that are
> entering Last Call (or at the request of a chair or AD) to
> look for i18n issues. To do this, we're going to want to
> triage those documents, and then assign those with potential
> issues to a reviewer; we don't have enough reviewers to look
> at every document like GenART does. The two of us can do some
> of that triage, but we could use some help, and for
> educational purposes we think it would be good to get helpers.
> 
> A few of you have mentioned that you don't feel up to doing
> detailed i18n reviews of documents, but would be interested in
> doing (or learning to do) document triage. Please drop private
> email to either or both of us and let us know. Our plan is to
> have a small group "review meeting" with potential triagers
> and triage some documents together so you get the hang of it.
> We'll also be creating a wiki of triage hints and tricks based
> on the i18n bits of the old "Typical Apps Area Issues" wiki
> <https://trac.ietf.org/trac/app/wiki/TypicalAppsAreaIssues>
> that the Apps ADs made some time ago.
> 
> For the rest of you: Expect to see some documents appear in
> your queue in the next little bit.
> 
> 2 x Pete