Re: [I18ndir] Getting restarted and triage

["Marc Blanchet" <[e-mail]>]

On 13 Jun 2019, at 21:38, John C Klensin wrote:

> 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.

your description of the drafts seems to show that these are enough 
substantive that it requires a WG.

my 2 cents,

Marc.


> 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
>
>
>
>
> -- 
> I18ndir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i18ndir