Re: [I18nrp] Mappings for IDNA2008 ?

Patrik Fältström <paf@frobbit.se> Wed, 13 February 2019 11:03 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 40A3B12894E for <i18nrp@ietfa.amsl.com>; Wed, 13 Feb 2019 03:03:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 NkRLaiQZ1pKs for <i18nrp@ietfa.amsl.com>; Wed, 13 Feb 2019 03:03:02 -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 EDF981274D0 for <i18nrp@ietf.org>; Wed, 13 Feb 2019 03:03:01 -0800 (PST)
Received: from [176.71.128.142] (m176-71-128-142.cust.tele2.se [176.71.128.142]) by mail.frobbit.se (Postfix) with ESMTPSA id 71D8626CE5; Wed, 13 Feb 2019 12:02:58 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=frobbit.se; s=mail; t=1550055778; bh=7kck6pYRpT/BpK7rWZYZ+ZzYNiUNWMk2cJet2ambzx0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=ckgxiWDWVdvKxvw0IRnFzl8e0ueX5tNVcRR0zTSeR35Myzu5NDE4tOx4l6VzvN4D8 cf9QWsMQ4js81zi9YS52TJbXR/uH7uaqSQjiD4iqVy4iuMHpxHX3oa3r5H8b4dK5W1 L+6rBD6K7LjsIjHujxfqohwSUtitA+fcYFSP24WQ=
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Patrik Fältström <paf@frobbit.se>
X-Mailer: iPhone Mail (16D39)
In-Reply-To: <47f746f8-b314-1263-0925-e049de90856f@it.aoyama.ac.jp>
Date: Wed, 13 Feb 2019 12:02:58 +0100
Cc: "i18nrp@ietf.org" <i18nrp@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <710086C6-C77F-4D5B-A223-C76110F33DD3@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> <D5B49CC8-7AEF-4E81-8774-F3F1F05682E8@frobbit.se> <320f4bc3-17b1-595b-34c7-8f95f69c0f33@ix.netcom.com> <B87C6774-4FF7-4A18-A81D-D0834401C293@frobbit.se> <bc7b727d-f75c-bbba-4f63-ebd1dcd87085@it.aoyama.ac.jp> <A5549B92-9414-4210-A94D-8E53339D3961@frobbit.se> <96242bed-ec65-5955-5a4d-5699b9e3cfb9@it.aoyama.ac.jp> <2207F716-8033-46B7-A750-FB226B870D86@frobbit.se> <ccfd52e0-25b9-b04d-0bcf-701606077296@ix.netcom.com> <EDE1FBF9-CDBA-476A-BB8A-15CFF60EAA06@frobbit.se> <47f746f8-b314-1263-0925-e049de90856f@it.aoyama.ac.jp>
To: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18nrp/v67T1LRZ-gcEdnEPY61KDicTfH4>
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: Wed, 13 Feb 2019 11:03:04 -0000


> On 13 Feb 2019, at 11:31, Martin J. Dürst <duerst@it.aoyama.ac.jp> wrote:
> 
> Hello Patrik, others,
> 
>> On 2019/02/13 17:25, Patrik Fältström wrote:
>> 
>> 
>>>> On 13 Feb 2019, at 09:19, Asmus Freytag (c) <asmusf@ix.netcom.com> wrote:
>>>> 
>>>>> On 2/12/2019 11:46 PM, Patrik Fältström wrote:
>>>>> 
>>>>> On 13 Feb 2019, at 08:18, Martin J. Dürst <duerst@it.aoyama.ac.jp> wrote:
>>>>> 
>>>>> If f(x) is the generic mapping, and f'(x) is the mapping of the
>>>>> exceptions, then f(f'(x)), which applies f' *before* f, should do the job.
>>>> This works in some cases and not in other cases.
>>> Examples?
>> 
>> This is math. :-)
>> 
>> If f(x)=x’ and in the locale used f(x) should be x and not x’, you have dependencies between f(x) and f’(x) if you want f(f’(x)) to be x’ and f(f”(x)) to be x.
> 
> Well, I have to admit that I didn't explicitly talk about that case in 
> my 'proof'. For functions in general (e.g. a function such as f(x) = 
> (x+7) mod 15), you are right.
> 
> But f(x) (the general mapping function) is idempotent (i.e. f(x) = 
> f(f(x)), which means that you can map as many times as you want, you 
> always get the same result). This is also true for any locale-dependent 
> mapping function.

I can not say it is. It might be a requirement that you set on the function. I don’t know enough about various languages in the world, bidirectionality and punctuation. See latest discussions about punctuation in Armenian language and script and it’s impact on registration.

> If it were not the case, human users would be very 
> surprised: a maps to A, but then A maps to a: That wouldn't make any sense.

No, we talk about f(a)=b and f(b)=c as one thing and f(a)=b and f(b)=a as a different one.

> Also, and even more important, for the general mapping function, if x is 
> allowed in IDNs, then f(x) = x.

That’s another requirement. Maybe in one locale you DO map from one to another?

> This may not be true for a 
> locale-dependent mapping function (i.e. it would be possible for a 
> German mapping function to map (Hungarian) ȁ to ä, although that's not 
> needed because German keyboards won't produce ȁ in the first place).

It might produce it via copy and paste.

> So if f(x)=x', that would mean that x is not allowed in IDNs. That would 
> mean that it is impossible that in a specific locale, the desired result 
> of f(f'(x)) is x. It may be different from x', i.e. y, but we can easily 
> get this by defining that f'(x) = y.
> 
> So applying the (in most if not all cases very small) locale-specific 
> mapping before the general mapping always will work.

I don’t understand what your goal is.

What I am saying is that what mapping is done when a string enters the system the first time, mapping is to happen and it is context dependent where context can for example be locale.

What is wrong with that statement?

   Patrik

> 
> Regards,   Martin.