Re: [precis] Secdir last call review of draft-ietf-precis-7564bis-07

John C Klensin <> Wed, 14 June 2017 01:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 49977129423; Tue, 13 Jun 2017 18:02:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RSYQUWUkPIAz; Tue, 13 Jun 2017 18:02:30 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 19B061252BA; Tue, 13 Jun 2017 18:02:30 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1dKwhX-000MWa-2U; Tue, 13 Jun 2017 21:02:27 -0400
Date: Tue, 13 Jun 2017 21:02:22 -0400
From: John C Klensin <>
To: Peter Saint-Andre <>, Matthew Miller <>,
Message-ID: <FEF9D2847A170FC48DE8EC5E@PSB>
In-Reply-To: <>
References: <> <>
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: [precis] Secdir last call review of draft-ietf-precis-7564bis-07
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Preparation and Comparison of Internationalized Strings <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 14 Jun 2017 01:02:32 -0000

--On Tuesday, June 13, 2017 17:02 -0600 Peter Saint-Andre
<> wrote:

> Hi Matt, thanks for the review - it's much appreciated.
> Just so you know: through discussion of Daniel Migualt's
> secdir review of 7700bis (we're progressing them all together
> this time!), I realized that it might be help to add another
> example of visually confusing characters to 7564bis, so I plan
> LETTER A U+0061 (which will be more familiar to readers than
> the Cherokee characters already in the document).


I don't want to throw the proverbial spanner in the works, but,
just as things changes just as the original PRECIS documents
were being published, I wonder if some other things that appear
to be in process now could do it to us again.  

For example, consider draft-freytag-troublesome-characters.
Despite having contributed to it and expecting to continue to do
so, I've got some misgivings about the document and proposed
registry as IETF work but, if it were to be adopted, it seems to
me that it would be useful for the PRECIS documents to
normatively reference it, especially for Identifier Class.   To
some extent, that draft is a remedy for some of the issues
raised in the long-stalled draft-klensin-idna-5892upd-unicode70,
but it doesn't make those issues, and the lack of
comprehensiveness of normalization, go away.

Probably less important, but it might be advantageous to
incorporate some of the "whatever decisions you make, people
will probably hold you accountable if there are problems" tone
of draft-klensin-idna-rfc5891bis into the PRECIS documents.  It
might even be that RFC 7940, possibly supplemented by
draft-freytag-lager-variant-rules, would be a better, or at
least useful alternative, way to present some or all of the
PEECIS rule sets than the current approach. 

On a somewhat different topic, the Greek, Latin,  and Cyrillic
scripts are so closely related that finding examples of pairs of
similar-looking characters is in the low-lying fruit category
because the similarities are not coincidences but the result of
derivation and extensive borrowing (something of the same thing
can be said for the Latin-Cherokee relationship, at least in
printed, rather than cureive, forms).   The examples that may be
more scary, just because there is no evolutionary theory to
predict were to look, would be things like the resemblances
among the Latin U+006F, the Lao U+0ED0, the Ethiopic U+12D0, the
New Tai Lue U+19D0, and of course the ASCII/European digit
U+0030 and probably many more, with the group perhaps best
described as "open circle graphemes" or something like that.