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

Peter Saint-Andre <stpeter@stpeter.im> Fri, 23 June 2017 20:25 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: precis@ietfa.amsl.com
Delivered-To: precis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B44111293D9; Fri, 23 Jun 2017 13:25:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=XuMrT1Iu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nXsYfYp4
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 G-YA7y4yUOSt; Fri, 23 Jun 2017 13:25:32 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 988D112943C; Fri, 23 Jun 2017 13:25:32 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id D9F4C20D2C; Fri, 23 Jun 2017 16:25:31 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Fri, 23 Jun 2017 16:25:31 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=m89Z2sg84W5HEJcRce fmSyCTT/Yym/7rkqtq+2c79JE=; b=XuMrT1IuuJjVAmI3g/XVqcK1dJ6G5JnsdI WaCz1Ya6Hj2InSYP6kankNOznKD/pzojBtwYPRWlggbJYuOzY1e+AonBsixGyqYZ oLQ5hkJ0Xugh0HPCn2S67SnT2T8mcLc7IwoJC3QzsJMOBZ+19+KAs34psMmzHA8R 0fu21ClK5oSpVekNyzqJUlYcqoYmZM44bdsEYghvXkHgbv7UvziVLPssrXha8lyp wyugjYye4xQc8/MQFyLnieWjAYUZRAzjdHQ0K8bGeLI634/a0ywxrELA87B8DNDa dCuNC0aHhLXSdCwvZPhRKNUgz5iDw65AVvabkk2TTHYx7sKJBpmg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=m89Z2sg84W5HEJcRcefmSyCTT/Yym/7rkqtq+2c79JE=; b=nXsYfYp4 9YsJWx8jYfdeU4l4tTzjZv/QfeCOUzWZkqAy+YJmzg72UgdNq4cwmq++7tCmz2FX EDeMO3b/BmLsddiguFVBSKLaE7ZdPNzgyaPfYdjyQJRQgYqaiFcmYIfYhj0bJ2XJ O7W10j6lLUdQIEe2MbRCpgrYh5tipARf8EABDQelZzeTbasBCsYdp0KJUNXwXKIF CIoZRX2l4c5GDc5ssmV5hDsyC4U19Pin/UZRTBZsjIvTEPuuz6niCt5hUF4g36mh NICE3zK70qzNHyftF/nxkkCtQe7iJj25iZpY+GOtQIKJSVAbMR5cNta3NTu4EPtI nkWOh93YvjDQdA==
X-ME-Sender: <xms:O3lNWfKpGPczoVPg41SYxYP9YLuACrH3uQNlxPFdtYA65pZjnnbtLQ>
X-Sasl-enc: AvkEJi7ALSA9VHw+2BZ4ozCZ+qc/arQAlXavjCIJO6Ap 1498249531
Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 0C24E24009; Fri, 23 Jun 2017 16:25:30 -0400 (EDT)
To: John C Klensin <john-ietf@jck.com>, Matthew Miller <linuxwolf+ietf@outer-planes.net>, secdir@ietf.org
References: <149736681626.7439.2555177998557552719@ietfa.amsl.com> <8ea90b99-3005-0afb-da93-63cd1abfc905@stpeter.im> <FEF9D2847A170FC48DE8EC5E@PSB>
Cc: draft-ietf-precis-7564bis.all@ietf.org, ietf@ietf.org, precis@ietf.org
From: Peter Saint-Andre <stpeter@stpeter.im>
Message-ID: <74ad8473-6036-2965-6833-7d59b0f9b038@stpeter.im>
Date: Fri, 23 Jun 2017 14:25:29 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <FEF9D2847A170FC48DE8EC5E@PSB>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/precis/FhlyFLQwgYQaBMmF20BD1KfDo5Q>
Subject: Re: [precis] Secdir last call review of draft-ietf-precis-7564bis-07
X-BeenThere: precis@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Preparation and Comparison of Internationalized Strings <precis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/precis>, <mailto:precis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/precis/>
List-Post: <mailto:precis@ietf.org>
List-Help: <mailto:precis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/precis>, <mailto:precis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Jun 2017 20:25:35 -0000

Hi John,

Thanks for your note, and my apologies for the slow reply. Comments inline.

On 6/13/17 7:02 PM, John C Klensin wrote:
> 
> 
> --On Tuesday, June 13, 2017 17:02 -0600 Peter Saint-Andre
> <stpeter@stpeter.im>; 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
>> to mention CYRILLIC SMALL LETTER A U+0430 vs. LATIN SMALL
>> LETTER A U+0061 (which will be more familiar to readers than
>> the Cherokee characters already in the document).
> 
> Peter,
> 
> 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. 

Given that we're dealing with a seemingly tenuous hypothetical, the best
approach might be for that I-D (if eventually published as an RFC) to
update the relevant PRECIS and IDNA RFCs? We'll need to do that for the
IDNA RFCs anyway because they're not currently under revision, as the
PRECIS RFCs are.

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

I'm not sure that anything could make those issues 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. 

One question in my mind is whether an approach such as that of RFC 7940
is so much better that it's worth scrapping / rewriting the PRECIS bis
I-Ds along those lines. Right now it's not even clear what criteria we'd
use to judge "better" or "useful" here - presumably specification
clarity and precision, algorithmic completeness, and reduced error rates
in code implementations might factor into the decision. But I don't
sense that we have a good handle on making these decisions yet. Another
tradeoff here is making the relatively small fixes to the PRECIS RFCs in
a relatively short amount of time (measured in IETF years) vs. making a
larger overhaul in a longer amount of time (and whether there is
sufficient energy to do so). Given our track record in
internationalization, I'd prefer to get these PRECIS fixes done now and
then look at a larger effort.

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

Indeed.

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

Well, circles are common enough, so it's reasonable that they'd show up
in many different contexts as both letters and numbers (which is why we
have confusion between the letter "O" and the number zero even in the
basic Latin repertoire) and even as punctuation marks and symbols. But I
like the examples you've mentioned and will add them to 7564bis to
further illustrate the problem, all the while understanding full well
that a complete list of examples or an explanation of why such examples
are problematic is outside the scope of this specification (which is why
we point to UTR36 and UTS39).

Peter