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
- [I18ndir] Getting restarted and triage Pete Resnick
- Re: [I18ndir] Getting restarted and triage John C Klensin
- Re: [I18ndir] Getting restarted and triage Marc Blanchet
- Re: [I18ndir] Getting restarted and triage John C Klensin
- Re: [I18ndir] Getting restarted and triage Asmus Freytag
- Re: [I18ndir] Getting restarted and triage John C Klensin
- Re: [I18ndir] Getting restarted and triage Asmus Freytag (c)
- Re: [I18ndir] Getting restarted and triage Patrik Fältström
- Re: [I18ndir] Getting restarted and triage Marc Blanchet
- Re: [I18ndir] Getting restarted and triage Pete Resnick
- Re: [I18ndir] Getting restarted and triage Barry Leiba
- Re: [I18ndir] Getting restarted and triage John C Klensin
- Re: [I18ndir] Getting restarted and triage John Levine
- [I18ndir] draft-faltstrom-unicode12 (was: Re: Get… John C Klensin
- Re: [I18ndir] Getting restarted and triage John C Klensin
- Re: [I18ndir] draft-faltstrom-unicode12 (was: Re:… Patrik Fältström
- Re: [I18ndir] Getting restarted and triage Asmus Freytag
- Re: [I18ndir] draft-faltstrom-unicode12 (was: Re:… John C Klensin
- Re: [I18ndir] Getting restarted and triage John C Klensin
- Re: [I18ndir] draft-faltstrom-unicode12 Asmus Freytag
- Re: [I18ndir] Getting restarted and triage John R Levine
- [I18ndir] Civility (Was: Getting restarted and tr… Pete Resnick
- Re: [I18ndir] Getting restarted and triage John C Klensin
- Re: [I18ndir] Getting restarted and triage Asmus Freytag (c)