Re: [I18ndir] Getting restarted and triage

"Marc Blanchet" <> Fri, 14 June 2019 12:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 80BF112001E for <>; Fri, 14 Jun 2019 05:18:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HLgoojsfYHil for <>; Fri, 14 Jun 2019 05:18:18 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4B57E12001B for <>; Fri, 14 Jun 2019 05:18:18 -0700 (PDT)
Received: by with SMTP id y57so2163081qtk.4 for <>; Fri, 14 Jun 2019 05:18:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version; bh=15I6Vuf/F/E4X/TnQxOD6Ym468zVfTLskzekyKmbaa8=; b=tFIQzei5VVxPSYsQZzeHGtS+xeHZmVfcYn1qU7THlNdDzkqpuHaHoMZdfszwe/KH2a 1vpGRgnxXDpOTKL3YZihLd0CJY01Mo2o53DL5NYLcoMD4YO0VOZnByT9dGkPjjdTQ2JH m1PhcNZIsh+h1mX4iJPhM6B2TLiI8gI6KyKNuTn8YIwJDExdRyvISeuJRe7jKxvniLnN 7x6vDj6t3LBnbyUKnTRx/Ti71sget+a3k5KfoGKHH/pzT2qDLPccaMUv3trt5V6WJqfU hJTMLLNvvEYffMCSoW9WIW9EnCaq36O/6SgU+jWVhN70+kS5F+wgpaEPnP+Z3bV93lE2 fLpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=15I6Vuf/F/E4X/TnQxOD6Ym468zVfTLskzekyKmbaa8=; b=bQG9A3LZfT8ie8KmCBhNAHaG+D6swrP+e2tJsqKA95pbL0H2LfRh7RZdeag8qlt7vx ynbLZYby4efELiYdKAFjjYSJi9CrOhPmUUymZnhjR2W6EnLBvlDMaLJR82X5jPfsZPz3 XRrqAxvcfJCIaiSrFIDX9+YQMY2P4kydmA9Y1erGKKx8JDPZ2FULu//k62UYPrxqL10q LdHhOP/DT4Jco2Wfr39165h8ZvknJ7F/48YuQPrhbFVaTorb5F9M7a6YKjS3Homsoz/f DcE4+1DN3fOXP3rl7rtUEKupkCCYEizKkdGpuKJmq9sUnkzpTpqixzDGfyxlBcimqxE4 1Xmw==
X-Gm-Message-State: APjAAAUUMfV8eR5X1kgk/o6ZU4Lt1lgZKOGpo/toKo+EllqSUhfU6KWN cgdSDmvzc2WPBHwG2iLuPuzL9w==
X-Google-Smtp-Source: APXvYqyl7LLUknJ0p/TE24qT3tRScADbT4ilr/7kVOkRKzPRQ4rdUTBbsS9mfUHGUyLKR6T2ZMuUsg==
X-Received: by 2002:a0c:8181:: with SMTP id 1mr7668827qvd.59.1560514697253; Fri, 14 Jun 2019 05:18:17 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id t80sm1239843qka.87.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Jun 2019 05:18:16 -0700 (PDT)
From: "Marc Blanchet" <>
To: "John C Klensin" <>
Cc: "Pete Resnick" <>,, "Peter Saint-Andre" <>
Date: Fri, 14 Jun 2019 08:18:12 -0400
X-Mailer: MailMate (1.12.5r5635)
Message-ID: <>
In-Reply-To: <843EAB4535391A494DA216CC@PSB>
References: <> <843EAB4535391A494DA216CC@PSB>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
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, 14 Jun 2019 12:18:22 -0000

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,


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