Diversity, writing systems, identifiers, and protocols (was: Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard)
John C Klensin <john-ietf@jck.com> Sat, 04 February 2017 14:14 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68D4129AEE for <ietf@ietfa.amsl.com>; Sat, 4 Feb 2017 06:14:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 QJ8GzV5utGkj for <ietf@ietfa.amsl.com>; Sat, 4 Feb 2017 06:14:25 -0800 (PST)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8373A129AF2 for <ietf@ietf.org>; Sat, 4 Feb 2017 06:14:25 -0800 (PST)
Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1ca16e-000DHQ-8P for ietf@ietf.org; Sat, 04 Feb 2017 09:14:24 -0500
Date: Sat, 04 Feb 2017 09:14:17 -0500
From: John C Klensin <john-ietf@jck.com>
To: IETF general list <ietf@ietf.org>
Subject: Diversity, writing systems, identifiers, and protocols (was: Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard)
Message-ID: <F4675E5282458BCBABDBDBCE@PSB>
In-Reply-To: <78EFB6CA-BB21-4B6F-964C-9A0BBAA68023@dukhovni.org>
References: <B9F32633ED13374379C6E0D1@PSB> <20170124193109.68919.qmail@ary.lan> <20170201210155.GI28349@mournblade.imrryr.org> <D45CE6A5317D4B373CD90742@PSB> <CAAFsWK1kQUUZrq9Cs47+jYbEJXW+hQN8gzKb+2qjXYdfYhRFzw@mail.gmail.com> <E56ED618-6670-437D-87A9-BD59FC10DBC1@dukhovni.org> <CAAFsWK2QjdkovXTgJR-6Hpj=u=MD5Mjk0srYVpoqNnK_d7_Y9Q@mail.gmail.com> <78EFB6CA-BB21-4B6F-964C-9A0BBAA68023@dukhovni.org>
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-Connect-IP: 198.252.137.70
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/syKFSOC32H4e3NDfFdGJiQyE-Yw>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 04 Feb 2017 14:14:27 -0000
--On Friday, February 3, 2017 14:51 -0500 Viktor Dukhovni <ietf-dane@dukhovni.org> wrote: >... > Is that right? Thus the verifier would sometimes need to > convert from U-labels to A-labels (when the localpart is all > ASCII), and at other times from A-labels to U-labels (when the > localpart is not all ASCII)... Victor, I think there is another issue hidden behind this that is worth mentioning and that interacts with your concern above. While it may or may not be important for any given protocol in the abstract (it will be for some, but not others), using strings containing non-ASCII characters in ways that interface with users is always going to involve tricky issues that require understanding and understanding, not just plugging code points, possibly with an encoding specified, into slots. People who "just" want to be told what to do so they don't need to think about it, or who want to apply a package they don't understand, are going to sooner or later find themselves or their users in trouble, whether the issues are identified as security problems, matching/equivalence errors of various kinds, user confusion due to violation of the law of least astonishment, or something else. The underlying issues are the result of the wide and very rich diversity of human writing systems and languages -- systems that are diverse enough that almost any simple statement or rule one can come up with will have exceptions. In general, that diversity is something we should celebrate rather than trying to find quick fixes or tricks to get around, only partially because those fixes or tricks aren't going to work well for some group of people. Narrow views of the situation just lead to other traps. In particular, while useful lessons can be learned, one cannot extrapolate from knowledge or experience of Latin-based scripts (even if one knows more than one language that uses them differently) to all others, from very closely related scripts (e.g., Greek-Latin-Cyrillic, some subsets of Indic (or neo-Brahmi) scripts, or so-called CJK) to writing system outside those groups without missing important cases and causing problems elsewhere. Like the kinds of diversity we deal with in some other areas, the differences did not show up overnight. A large fraction of the human population has been cr4ating and practicing them for centuries and, in many cases, tens of centuries. If IDNA enters the mix, another layer of knowledge and understanding is required. It is actually easier to grasp (or grok) than the above, but may have even greater impact in protocol design. Unlike the above, IDNA is artificial and a recent invention to solve a very specific problem with incremental deployment, a decision most of us, including most of those in the IDN business and those who use non-Latin scripts on a daily basis, think was probably a good idea. People simply need to understand how it works and is intended to evolve, with the U-label <-> A-label symmetry and checking requirements as particularly important. In particular for this case, protocols which reach the user simply need to be ready to handle U-labels and A-labels interchangeably. Because of the combinatorial explosion problem, trying to do that by enumerating the possible FQDNs just won't work -- people may know what, e.g., they intend to push out in email or use in the text of an HTML "a" element, but there are going to be just too many things in the network toat will change things back and forth for their own (perfectly rational) reasons. At least IMO, that makes a very strong argument for protocols, where it is possible, defining and using a single canonical form and expecting user interfaces to do conversions as needed. You may reasonably disagree with that last conclusion because it is just a protocol design preference, but most of the rest almost certainly must to be treated as immutable facts, at least until and unless we all agree to use the same language and the same orthography and writing system for that language. best, john
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John C Klensin
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Alexey Melnikov
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Patrik Fältström
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John C Klensin
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Patrik Fältström
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John Levine
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John C Klensin
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Patrik Fältström
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John C Klensin
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John R Levine
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John C Klensin
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John Levine
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John C Klensin
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John Levine
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Wei Chuang
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Wei Chuang
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Diversity, writing systems, identifiers, and prot… John C Klensin
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Wei Chuang
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John C Klensin
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Wei Chuang
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Wei Chuang
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Russ Housley
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Russ Housley
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Russ Housley
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Russ Housley
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Russ Housley
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Russ Housley
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John R. Levine
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Wei Chuang
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Stephen Farrell
- RE: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Jim Schaad
- RE: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… John C Klensin
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Wei Chuang
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Russ Housley
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Stephen Farrell
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Wei Chuang
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Viktor Dukhovni
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Wei Chuang
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Viktor Dukhovni
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… tom p.
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Wei Chuang
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Wei Chuang