Re: [I18nrp] Mappings for IDNA2008 ?

Asmus Freytag <asmusf@ix.netcom.com> Tue, 05 February 2019 17:09 UTC

Return-Path: <asmusf@ix.netcom.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 92F23124BAA for <i18nrp@ietfa.amsl.com>; Tue, 5 Feb 2019 09:09:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ix.netcom.com; domainkeys=pass (2048-bit key) header.from=asmusf@ix.netcom.com header.d=ix.netcom.com
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 iDtiORevLiW4 for <i18nrp@ietfa.amsl.com>; Tue, 5 Feb 2019 09:09:27 -0800 (PST)
Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) (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 1CC3A12008A for <i18nrp@ietf.org>; Tue, 5 Feb 2019 09:09:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ix.netcom.com; s=dk12062016; t=1549386566; bh=jdBz3V5paAZaUq0T74KHl0UFWBQrS6t4XMqH N/3/Mjs=; h=Received:Subject:To:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language: X-ELNK-Trace:X-Originating-IP; b=E/XhWT8wqCA1/WbGWCyzkujOgIH9Kp4x/ FcUYwnr6S7nVTVYDrjvWFAxiEq4NY6hFfG68L2j2d9GBCZ87cwFMtN5gl6hgQWaIBUg yzRoho9g1jJSOUMbFGTEL9+pyyLQd/KeB2BTkkEcnOtsWcwbbrGVxr2aN2/SLTyJIBS VDaaMGpTfAFyqm5j2QAPD+yVfSAaICUXFM1iqAB2SuN6ifzuJvW9xGCDoLyYMb+Bex3 3uhU8mxQTCfF0vA7FLkULs2P67ghX9QYapRVizmN0+dU/TaKR62QrRV1DdO/mdwziaw wDCovZPhUebfctMcSeQwPH0gESiLjccXSKqtDn8ZA==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=ix.netcom.com; b=jQpQDsEiHkbbLsuPr/KDRfjj2cATnQu0umeNxvMBiAxNK/3indKGBpOrkWOuDX9cYyc1h1KiFcV77IbZZwwcAZxWKIjeByn15pdNA3ajbYO3KLEJv+cO+bH9fPStAwv5fYV74lTdFQMFjRC8EGAJHqvztfu8p4NtsW3slpP9n26Nm4NoJJtX4BV+Fm2fNVCtvwE5s1OcZt23ifLCR4NnU5vvhR0yLEQZdSTBQibB1mWgP9lSksCAx4gRSUHEoVPFp7CX5/2VirRfqt+gPli7LzXzsZN4yk/rj+D1aBUqBpx1VINE58wPXHijayonslh83L/W527Z7H1JhIFoERWfqw==; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language:X-ELNK-Trace:X-Originating-IP;
Received: from [71.212.3.155] (helo=[192.168.1.114]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from <asmusf@ix.netcom.com>) id 1gr4Du-000D5J-0G for i18nrp@ietf.org; Tue, 05 Feb 2019 12:09:26 -0500
To: i18nrp@ietf.org
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> <D5B49CC8-7AEF-4E81-8774-F3F1F05682E8@frobbit.se>
From: Asmus Freytag <asmusf@ix.netcom.com>
Message-ID: <320f4bc3-17b1-595b-34c7-8f95f69c0f33@ix.netcom.com>
Date: Tue, 5 Feb 2019 09:09:28 -0800
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <D5B49CC8-7AEF-4E81-8774-F3F1F05682E8@frobbit.se>
Content-Type: multipart/alternative; boundary="------------51C4EE9F9FB6DE45197D7D93"
Content-Language: en-US
X-ELNK-Trace: 464f085de979d7246f36dc87813833b28d93432b0f0788b93f9e2ba4439df1081219b9f2a7adc0c0350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 71.212.3.155
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18nrp/bX7K5kaeZyqCFoYI-W0-Kd9hbhg>
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 17:09:29 -0000

On 2/5/2019 5:00 AM, Patrik Fältström wrote:
>
>
> On 5 Feb 2019, at 09:29, Asmus Freytag (c) <asmusf@ix.netcom.com 
> <mailto: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.

OK, if you make the choice that all of this should happen, then what?

You'll have to use some tables / algorithm to do the mapping. Even when 
locale dependent (notionally) you have 90%+ of all cases that are 
unchanged and some small subset would get adjusted (tailored).

That makes providing generic mapping tables useful.

>
> One can not (IETF found when discussing IDNA2003) do everything “in 
> one go”.
>
> 1. Mapping
> 2. Validation
>
You've lost me here. I would need a bit more background to understand 
this statement.

I assume that "mapping" is something you do when prepping a 
user-supplied string for lookup.

But not sure what "validation" refers to.

A./