Re: [I18ndir] Getting restarted and triage

John C Klensin <john@jck.com> Fri, 14 June 2019 20:04 UTC

Return-Path: <john@jck.com>
X-Original-To: i18ndir@ietfa.amsl.com
Delivered-To: i18ndir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 579DC1201E7 for <i18ndir@ietfa.amsl.com>; Fri, 14 Jun 2019 13:04:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uV-acz0lhb9v for <i18ndir@ietfa.amsl.com>; Fri, 14 Jun 2019 13:04:02 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D68C12011B for <i18ndir@ietf.org>; Fri, 14 Jun 2019 13:04:02 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john@jck.com>) id 1hbsQZ-0004kr-Em; Fri, 14 Jun 2019 16:03:59 -0400
Date: Fri, 14 Jun 2019 16:03:53 -0400
From: John C Klensin <john@jck.com>
To: Asmus Freytag <asmusf@ix.netcom.com>, i18ndir@ietf.org
Message-ID: <E596E8F5E430FAFAC84B17CF@PSB>
In-Reply-To: <77e8acfd-811a-c5e9-6940-3b8ed2669a75@ix.netcom.com>
References: <F2B84580-7E5A-4B86-BF9C-0205D4E6121D@episteme.net> <843EAB4535391A494DA216CC@PSB> <13212579-9AEA-45F8-A205-18B4AD1B0BF1@viagenie.ca> <EC8189E3EA3488B8924DBBEB@PSB> <77e8acfd-811a-c5e9-6940-3b8ed2669a75@ix.netcom.com>
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-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18ndir/KpO1HxWUhZFio4Que7SgnmOtyHs>
Subject: Re: [I18ndir] Getting restarted and triage
X-BeenThere: i18ndir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Internationalization Directorate <i18ndir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i18ndir>, <mailto:i18ndir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i18ndir/>
List-Post: <mailto:i18ndir@ietf.org>
List-Help: <mailto:i18ndir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i18ndir>, <mailto:i18ndir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Jun 2019 20:04:05 -0000

Asmus,

I think we are in substantial agreement, but a few comments
below to be sure (and with everything else elided)...

--On Friday, June 14, 2019 09:29 -0700 Asmus Freytag
<asmusf@ix.netcom.com> wrote:

>...
> In prinicple, I'd agree. However:
>...
>> (2) The original IAB statement on what was described at the
>> time as a Hamza problem but which we are now calling a
>> non-decomposing character one

> Which description still falls short of the problem as long as
> you have several pairs of code points with identical (by
> design) appearance in IDNA 2008 -- and not counting the
> Latin/Cyrillic pairs.

First of all, that issue, as described in the original IAB
statement and in draft-klensin-idna-unicode-7-0-0 (even in
version -00) is about conflicts within a script and hence does
not interact with Latin/Cyrillic, Cyrillic/Greek, or Latin/Greek
overlaps.  While we could have a long and probably amusing
discussion about whether Greek, Latin, and Cyrillic should have
been separated while the Arabic language variation of Arabic
Script and the variations based on or derived from Persian were
not, that discussion is of theoretical interest only (except
possibly for those who feel some nostalgia for the original ISO
DIS 10646 and its greater identifier focus rather than
printing/display focus).

Second, no one I know ever claimed it was a complete description
of the problem or even that draft-klensin-idna-unicode-7-0-0 was
at the most recent (public) -05.   I was just trying to map the
landscape out in a very approximate way for this list.

>> Without interpreting the months it took to get it off the
>> ground, the lag time between the discussions of the Unicode
>> 11.0 and 12.0 tables and drafts and Pete's note and the month
>> between Pete's note and my note as indicating anything
>> (although it probably does), (1) - (6) above make an
>> extremely strong case that getting critical mass together to
>> initiate and sustain a WG, at least a conventional one that
>> does not bend various rules, is implausible.

> Seems like a reasonable reading of a the evidence to me.

Sadly, we agree.
 
>> FWIW, if we look over the i18n drafts posted in the last few
>> years (since the last PRECIS ones to go to RFC), I believe
>> that none of the authors other than Andrew are regular IETF
>> meeting attendees.  That doesn't bode well for a WG, at least
>> a conventional one either.

> That's an issue.

Given the above, just one more minor complication.  It either
means that we need to get agreement to do something mildly
unconventional or that we need to figure out how to do any work
mostly remotely _and_ in a way that keeps people engaged.  In
the latter regard, while I've pulled time out to try to write
some drafts and look again at others in the hope of either
getting things moving or proving that we cannot do so -- getting
this off my plate one way or the other, the other issue is that
I'm really busy and have zero support for this (even support I
can borrow from other things or justify on the basis of other
commitments), Patrik is really busy with other commitments,
Andrew now has a more than fill-time job, I assume I can make
inferences about the degree to which Pete and Peter are sitting
around contemplating what to do with their extensive free time
from the rate at which they have been pushing the directorate
forward, and I assume that no one has stepped forward to support
you for as much time as you feel like putting into this and in
the style to which you would like to become accustomed. That,
IIR, is entire the recent author list.

IMO that is a fairly serious problem and the reason I took
exception to "requires a WG" without a plan that addresses it.

> i18n is special in the way it intersects technologies. It
> isn't a standalone technology, despite the fact that some
> technologies are i18n-specific.

Yes.  I hope we all know and agree about that.  Certainly I do.

> In principle, the directorate model should cover the other
> aspects well, except that IETF has too few people who can (or
> want to) understand and review meaningfully those "generic"
> technologies that nevertheless have i18n exposure. The W3C
> make that model work, but only because their core participants
> are funded directly for that work.

Actually, there was a bit of a fuss when the directorate was
created about confining its role to that of traditional
directorates.  If those positions are accepted (some of which
came from comments by people who where then ADs), our sole role
is to advise that ART ADs on strategic issues.  Even reviewing
out-of-Area documents is a little marginal and some Areas have,
historically, had both directorates (for strategy and technical
advice to the Area) and what are now called Review Teams (for
out of Area document reviews) with different memberships.   

>From the perspective of someone who is part of W3C's core i18n
WG and who has been on most of the weekly calls for the last few
years --probably a higher percentage of calls over that time
than anyone other than the assigned staff member and the chair
(and who, by the way, is not funded either directly or
indirectly for that work), there are at least two other reasons
why that effort works.  One is that the core group, and the W3C
generally, have been at liberty to say "not a web problem" or
equivalent and walk away (and have done that, repeatedly).   I
cannot imagine them spending much time on, e.g., non-ASCII
identifiers in X.509 certificates or physical device
identifiers.   The second is that they are actually treated as a
group of experts that is required, or even expected, to justify
every internal decision to a pack of people with strong
opinions, loud voices, and no expertise (in our case, whether
within the IETF or to various ICANN and other industry groups).
Even the public review process is different in that respect.

So I agree with you, but the difference is much greater than
what you say above.

    john