IETF Logo Mail Archive

Re: [I18nrp] Mappings for IDNA2008 ?

"John R Levine" <johnl@taugh.com> Tue, 05 February 2019 00:43 UTC

Return-Path: <johnl@taugh.com>
X-Original-To: i18nrp@ietfa.amsl.com
Delivered-To: i18nrp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C36130ECA for <i18nrp@ietfa.amsl.com>; Mon, 4 Feb 2019 16:43:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=D4pAhZC3; dkim=pass (1536-bit key) header.d=taugh.com header.b=OTxJm4D1
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 aHFbkCDvADUC for <i18nrp@ietfa.amsl.com>; Mon, 4 Feb 2019 16:43:48 -0800 (PST)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9016130DF1 for <i18nrp@ietf.org>; Mon, 4 Feb 2019 16:43:47 -0800 (PST)
Received: (qmail 79100 invoked from network); 5 Feb 2019 00:43:46 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=134f9.5c58dc42.k1902; bh=+19uT2OvS6aZKVg3rIM4s4fd4C/HosGgOmwMnBy1840=; b=D4pAhZC3yOv3dZ2MWSKEvV2OVbxhC+e0L4oLXUBs41/ch5petYvxEHPfy6C2raG9a4c5HZo/sZlinL1l4/TM+fC4A9pOotTvlEWkSpylC4jujOWQju8Mfs7ok9x2sfhHEjE6znsnYFlEKx0GyY43B4ONKUDXTTBaQBHX9H6wg3an7knDInInAbbpVb+FPi3PHFZmhZbS2J5CX44q+BrET49PJM0QXrFQhxhW+RaNL6q09um+XdR5pcZ43P3ddpHD
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=134f9.5c58dc42.k1902; bh=+19uT2OvS6aZKVg3rIM4s4fd4C/HosGgOmwMnBy1840=; b=OTxJm4D1fd0nMx2NLs0OpGn43iHm96qSspYDq+SBKjcrnbLwbVQB1uiW6BsvJnY4QWDrjL0GFjHCzU+G2XX6PuazqF+uMlewuYGSeVXtnc8Gu8+LZv2dCOOMxmOr4y8UhOr8LOdqChoOKV3/FHGIdJud/iUIW2J5ixd9/zi3U1qOmo9CnA57jSZQDBnjZDc4aXrXhN3x1u2aF21bqzVsK/mdepzdD/7HDR684Qs+GHs71DlWTrrYdV91oxKM7mkq
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 05 Feb 2019 00:43:46 -0000
Date: Mon, 04 Feb 2019 19:43:46 -0500
Message-ID: <alpine.OSX.2.21.1902041941300.32964@ary.qy>
From: John R Levine <johnl@taugh.com>
To: Andrew Sullivan <ajs@anvilwalrusden.com>
Cc: i18nrp@ietf.org
In-Reply-To: <168bb19ae68.278b.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com>
References: <20190205002555.1AFBA200DC1DB1@ary.qy> <168bb19ae68.278b.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com>
User-Agent: Alpine 2.21 (OSX 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18nrp/B4NHC1FeWGbHJt0TuXLfB-NTR34>
Subject: Re: [I18nrp] Mappings for IDNA2008 ?
X-BeenThere: i18nrp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Internationalization Review Procedures <i18nrp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i18nrp>, <mailto:i18nrp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i18nrp/>
List-Post: <mailto:i18nrp@ietf.org>
List-Help: <mailto:i18nrp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i18nrp>, <mailto:i18nrp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Feb 2019 00:43:50 -0000

> And some of this, of course, is the result of attempts to be backward 
> compatible with IDNA2003, when the WG consensus was to have a transition that 
> fixed the problems in 2003.  The decision of UTS46 is really to have that 
> transition last essentially forever. This is, I suspect, a difference in 
> taste between the ietf and UTC communities about how to make those 
> trade-offs, but it has created part of the problem.

This started with discussions with the people maintaining the python IDNA 
libraries.  They clearly had no idea that any mapping other than the 
ones in UTS46 is even possible.

I don't think it's so much a matter of taste as that most people doing 
this stuff have a very thin understanding of what's going on.  When I 
point out that UTS46 has Western European language assumptions baked into 
it, oh, huh, how about that.

R's,
John

v2.23.0 | Report a Bug | By Email