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
- [Lucid] Please clarify the i's in Appendix A Shawn Steele
- Re: [Lucid] Please clarify the i's in Appendix A Patrik Fältström
- Re: [Lucid] Please clarify the i's in Appendix A Shawn Steele
- Re: [Lucid] Please clarify the i's in Appendix A Patrik Fältström
- Re: [Lucid] Please clarify the i's in Appendix A Andrew Sullivan
- Re: [Lucid] Please clarify the i's in Appendix A Shawn Steele
- Re: [Lucid] Please clarify the i's in Appendix A Andrew Sullivan