Re: [Lucid] Please clarify the i's in Appendix A

Andrew Sullivan <ajs@anvilwalrusden.com> Sat, 21 March 2015 21:32 UTC

Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: lucid@ietfa.amsl.com
Delivered-To: lucid@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACAAB1A8FD7 for <lucid@ietfa.amsl.com>; Sat, 21 Mar 2015 14:32:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.141
X-Spam-Level:
X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=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 5tgkv8UiCSOM for <lucid@ietfa.amsl.com>; Sat, 21 Mar 2015 14:32:41 -0700 (PDT)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A017B1A8F50 for <lucid@ietf.org>; Sat, 21 Mar 2015 14:32:41 -0700 (PDT)
Received: from mx1.yitter.info (dhcp-905d.meeting.ietf.org [31.133.144.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 8DEEF8A031 for <lucid@ietf.org>; Sat, 21 Mar 2015 21:32:38 +0000 (UTC)
Date: Sat, 21 Mar 2015 16:32:42 -0500
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: lucid@ietf.org
Message-ID: <20150321213241.GG6841@mx1.yitter.info>
References: <BLUPR03MB1378FED1AEB1C756C5D058C2820E0@BLUPR03MB1378.namprd03.prod.outlook.com> <184B22C8-336A-4687-8FAD-E9A4942C6CD8@frobbit.se> <BLUPR03MB1378664A6F96AEBBC2E27EE4820E0@BLUPR03MB1378.namprd03.prod.outlook.com> <20150321174516.GC6841@mx1.yitter.info> <BLUPR03MB1378A7B9166A44E41437B91A820F0@BLUPR03MB1378.namprd03.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <BLUPR03MB1378A7B9166A44E41437B91A820F0@BLUPR03MB1378.namprd03.prod.outlook.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/lucid/7K61hWp1FK4wsvUxKeCPhdL-M8U>
Subject: Re: [Lucid] Please clarify the i's in Appendix A
X-BeenThere: lucid@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Locale-free UniCode Identifiers \(LUCID\)" <lucid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lucid>, <mailto:lucid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lucid/>
List-Post: <mailto:lucid@ietf.org>
List-Help: <mailto:lucid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lucid>, <mailto:lucid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Mar 2015 21:32:42 -0000

On Sat, Mar 21, 2015 at 07:40:23PM +0000, Shawn Steele wrote:

> In IDNA 2008 it was recognized that mappings existed in IDNA2003 and
> that implementations such as browser address bars would find them
> useful.  It was also recognized that mapping is a complex problem,
> so IDNA 2008 didn't tackle the mapping problem, suggesting that
> different folks could implement their own appropriate mappings.

> Clearly it doesn't help much to have everyone doing their own
> different mapping,

My memory is different about this case (no pun intended).  What I
recall about IDNA2008 was that we realized, though experience, that a
single set of mappings would not work reliably universally.  The
Turkic I-set you're raising with this example is actually quite a good
example of this, because whereas the case folding of I is mostly
straightforward, Turkic causes trouble.  Moreover, different
conventions for i-accent handling cause trouble, too.  What we
concluded in the WG was that, if localization were to be taken
seriously, then you could not come up with a universal handler for
this, and registration rules would have to suffice to avoid serious
problems where the community was Internet- (or even
significant-chunk-of-Internet-) scale.  (This is part of why Asmus's
and my draft discusses the network scope as a factor; we seem to have
forgotten this part of the original assumptions of i3.)

The Unicode single-mapping approach basically just does away with that
assumption of the IDNA2008 work (on which PRECIS is founded).
Presumably, Unicode thinks this is a stupid idea, but it was one of
the original founding notions in i3 and if the IETF is to abandon it
we ought to do so with our eyes open.

Anyway, it still seems to me that we have a problem with things that
are straightforwardly PVALID, and we ought to try to understand that
case before we work out what to do with strings that are DISALLOWED
but that have some other transformation on the path to i3.

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com