IETF Logo Mail Archive

Re: [I18nrp] Mappings for IDNA2008 ?

Patrik Fältström <paf@frobbit.se> Tue, 05 February 2019 13:00 UTC

Return-Path: <paf@frobbit.se>
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 CC409130F4C for <i18nrp@ietfa.amsl.com>; Tue, 5 Feb 2019 05:00:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 (1024-bit key) header.d=frobbit.se
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 liu7_-rQRwTs for <i18nrp@ietfa.amsl.com>; Tue, 5 Feb 2019 05:00:17 -0800 (PST)
Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F765126DBF for <i18nrp@ietf.org>; Tue, 5 Feb 2019 05:00:17 -0800 (PST)
Received: from [172.18.242.180] (w193-11-200-250.eduroam.sunet.se [193.11.200.250]) by mail.frobbit.se (Postfix) with ESMTPSA id EF9E126EDB; Tue, 5 Feb 2019 14:00:14 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=frobbit.se; s=mail; t=1549371615; bh=QQgHbRShjRMo+Xm0mar7W0h3ULpWKSBzJy0nfq2RaeY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=jHMAMqmN4rYwfttI5i1XZ4iQgu5DW2Ku7/I8LdqVNzAhPN/tZBoleEtAbqweLxOPf Ac/TFh1QT7GCAFhCNrrvcsCmH/6HaZJXE/yLyysqADTmaV1YfBd46NHqEjzchxaaFz 6bOCP6rHCXds3MfgJO39BPmreAFLN8nEIzapV1nk=
Content-Type: multipart/alternative; boundary="Apple-Mail-408CE41A-6914-47A2-B703-C473B79CE578"
Mime-Version: 1.0 (1.0)
From: Patrik Fältström <paf@frobbit.se>
X-Mailer: iPad Mail (16E5181f)
In-Reply-To: <16ff0d27-9508-7fdd-bc89-9d6fd47396b1@ix.netcom.com>
Date: Tue, 05 Feb 2019 14:00:14 +0100
Cc: i18nrp@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <D5B49CC8-7AEF-4E81-8774-F3F1F05682E8@frobbit.se>
References: <20190204225047.02583200DC1666@ary.qy> <6660b7e2-1d5b-6a5d-3d1c-55a757e24843@ix.netcom.com> <ADDA4540-9169-4EE6-B33E-3A0D9EED0BD7@frobbit.se> <16ff0d27-9508-7fdd-bc89-9d6fd47396b1@ix.netcom.com>
To: "Asmus Freytag (c)" <asmusf@ix.netcom.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18nrp/lKCHz2sZ0CJpIr8vgIBXjyKkGnY>
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 13:00:24 -0000


> On 5 Feb 2019, at 09:29, Asmus Freytag (c) <asmusf@ix.netcom.com> wrote:
> 
>> On 2/4/2019 11:24 PM, Patrik Fältström wrote:
>>> On 5 Feb 2019, at 0:27, Asmus Freytag wrote:
>>> 
>>>> Are there any published IDNA2008 mappings?  As far as I can tell,
>>>> everyone uses one from UTS46 by default, and it's not very good.
>>>> 
>>> Examples of its badness, please.
>> Mapping of characters, including case folding, is LOCALE specific.
>> 
>>   
> That's not in contradiction to using a generic mapping for the 90% case and applying tailoring (on a per locale or other basis).
> 
> It may explain why it's bad to use a default WITHOUT adding tailoring, but does not explain why a particular generic mapping represents a "not very good" starting point for such tailoring.
> 

Let me try with a different explanation...

Depending on context (writing direction, locale, where the data in received etc) the application must for IDNA2008 FIRST make a conscious choice whether any mapping should happen (or just validation), and IF mapping is to happen, whether for example only NFC should happen, or case folding (locale dependent) etc.

One can not (IETF found when discussing IDNA2003) do everything “in one go”.

1. Mapping
2. Validation

   Patrik
> A./

v2.23.0 | Report a Bug | By Email