Re: [I18ndir] Getting restarted and triage

John C Klensin <> Fri, 21 June 2019 22:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E73591201CA; Fri, 21 Jun 2019 15:20:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RJ0bZx567aKB; Fri, 21 Jun 2019 15:20:06 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 409061200F5; Fri, 21 Jun 2019 15:20:06 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1heRt5-000DCJ-W1; Fri, 21 Jun 2019 18:20:03 -0400
Date: Fri, 21 Jun 2019 18:19:57 -0400
From: John C Klensin <>
To: Pete Resnick <>
cc:, Peter Saint-Andre <>,
Message-ID: <F2A317B2420BA48FC2A23176@PSB>
In-Reply-To: <>
References: <> <843EAB4535391A494DA216CC@PSB> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
Subject: Re: [I18ndir] Getting restarted and triage
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Internationalization Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Jun 2019 22:20:09 -0000


I've read Barry's note, which seems entirely reasonable.  As you
(and I trust most other's here) have noticed, while waiting I
did post a note to the IDNAbis list asking for review and
feedback on the theory that, if anyone on that list but not on
this one had something to say / contribute, we should listen.
So far the silence has been deafening which I can interpret
either as (i) everyone who is on that list and likely to do work
is on this list and has been waiting for your note (and word
from Barry, Alexey, or Adam) or (ii) we are in even bigger
trouble than I assumed.

More inline below.

--On Friday, June 21, 2019 14:12 -0500 Pete Resnick
<> wrote:

> [Copying the ADs, as their input is also necessary.]
> Before getting to your direct question, a followup on the
> "restart and triage" bit: I only got 2 messages from folks who
> wanted to do triage, and then promptly went on vacation (with
> a longer-than-normal vacation interrupt latency on the
> backend), so I haven't gotten a chance to individually harass
> people who said some time ago that they would help out. That
> harassment will start today. So hopefully we'll get on track
> to do triage and regular reviews quickly.

I hope so, but with the understanding that there is an
interaction with the core documents in many (although certainly
not all) potential reviews of non-I18n documents with i18n
citations, dependencies, or other relationships.    If they
either reference IDNA or are dependent on IDNA's approach
(probably including almost everything that depends on PRECIS) or
contain any statements or logic that are sensitive to Unicode
versions, the issues that motivated the documents that are more
or less in the queue may affect them and be candidates for
"known technical omissions".  Unless the IESG is willing to
simply blow off that provision of 2026 --which I hope and assume
they would not if it were called to their attention for a
particular document-- either the document being reviewed goes
into a wait state until we clean up at least some of the i18n
core mess or someone is going to have to write an explanation of
the problem and why the document should progress without it. I'd
assume that, in most cases, that "someone" would need to be one
of us because there are not may other pockets of the relevant
expertise.   Perhaps that makes "triage" and "regular reviews" a
little more complicated than you are anticipating.

> But, as for your direct question:
> On 13 Jun 2019, at 20:38, John C Klensin wrote:
>> 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?
> So, first let's get together the full list of "core" documents
> needing review in this group. From your message, I glean:
> draft-klensin-idna-unicode-review
> draft-klensin-idna-architecture (to be published)
> draft-klensin-idna-rfc5891bis (expired)
> draft-freytag-troublesome-characters-02 (expired)

Any of these (and those below) that have expired are expired
because the ADs or directorate advised the the authors to let
them expire.   They are easily un-expired (and will be) when we
are ready to cope with them.  And I hope you mean "posted" and
not "published".  One step at a time.

draft-klensin-idna-unicode-7-0-0.  While I assumed when I wrote
my earlier note that draft-klensin-idna-architecture would
completely subsume its contents, it now appears to me that some
of the discussion of specific issues (such as the
non-decomposing character one) in
draft-klensin-idna-unicode-7-0-0 belongs in a separate document.
There may also be a document on the special properties of
complex scripts (if we want it and can persuade Asmus to write

> Did I miss anything?
> (I'm of course leaving aside draft-faltstrom-unicode12, which
> is on Alexey's plate.)

There are some potentially serious complications with it, most
brought on by the passage of time while we've been waiting and
others that might have slipped through it is had been handled
quickly but are now hard (and probably improper) to ignore.
That deserves a separate note (and probably thread)...

> Do you think all of these need to be reviewed in parallel, or
> can we subdivide the task? My inclination is to get a couple
> of sets of eyeballs on each document and then discuss the
> reviews on the list; I don't think we need to have a
> free-for-all on all of the documents.

Sure, if it is feasible.  But several of these documents are
dependent on others of them, either in the form of normative
references or on assumptions or context that depend on approval
of one or more of the others.  So, it is not obvious to me that
is feasible to separate and order them by document or, if it is,
that we would just be trading a quicker review process for a
confusing set of IETF Last Calls confusion to everyone paying
attention, which might be null set when the people on this
mailing are excluded) and documents parked with the RFC Editor
in reference hold.   I do think we could build a road map for
people threading their way through the documents, but that would
be a fair amount of work for someone and I don't think I'm going
to volunteer.

> (On that, and to reply to some of the other comments: Dealing
> with these documents is **not at all** like a WG: In a WG,
> documents are collectively developed and documented by the doc
> editor, and by the time a document is done, we have a nice
> history, whether it's on the mailing list, in github, or
> whatever, of how decisions were made and why we have
> consensus. This is very different: We have documents prepared
> by individual experts and are trying to retrospectively review
> them, looking for errors or editorial flubs to make sure the
> document is ready to go. We want to get additional eyeballs on
> the documents, but this is *not* a collective effort to create
> these documents. That's OK, but that's also why it's so hard
> to get focus. The purpose of the directorate IMO is to get
> that focus.)

Sorry, Pete, but that characterization of WG documents is, for
many of them, somewhere between a fairy tale and wishful
thinking.  Too often, especially in recent years but even before
that, a WG has started with a draft prepared entirely outside
the IETF and done nothing but tune it a bit, a possibility that
exists even with these i18n documents.  Sometimes, WGs have been
told that the protocol described by the documents that were
prepared and largely completed before the WG started was already
deployed and that any fundamental changes to that protocol were
out of scope.  Certainly we haven't had the latter here.

In addition, there was considerable discussion -- as a group --
of what the requirements for IDNA review for new versions of
Unicode were and should be while we were sorting through
draft-faltstrom-unicode11 and draft-faltstrom-unicode12.  I made
notes, I believe Patrik made notes, probably other people made
notes.   I think that several of us assumed that those notes
would be circulated, we'd discuss them, someone would volunteer
or be appointed as document editor and we'd get something
together and proceed -- not at all different from the way your
idealized WG would work.   

That didn't happen that way.  I can't speak for others, but I
wanted to get draft-faltstrom-unicode12 behind us and was
waiting for instructions from the co-chairs as to how they
wanted to move forward.   When neither happened --months after
draft-faltstrom-unicode12-00 was posted and more than a month
after your note-- I decided to put some words down, enlist
Patrik, and get a draft posted.   What do you think I/we should
have done differently?

> I'm inclined to hear what the ADs want out of this process as
> well. For documents like this, my presumption is that you want
> to hear a hum from the directorate that you're safe to AD
> sponsor the document. Is that right?