Subject: Re: [DNSOP] DNSOP Digest, Vol 125, Issue 31

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 13 Apr 2017 14:41:20 -0400

> On Apr 13, 2017, at 7:30 AM, [email-masked] wrote:
> 
> Well, IIRC they sensibly converged on a case-folded normal form
> that ensures that https://Духовный.org maps to the same underlying
> wire-form domain as https://духовный.org, i.e. both result in
> queries for xn--b1adqpd3ao5c.org.  AFAIK, those would generally be
> different domains under IDNA2008.

What I should have said is that the variant with the upper case
first letter is invalid (as opposed to being "different") in
IDNA2008.  This is IMHO a poor user interface, so running code
will generally go with UTS#46 (increasingly non-transitional)
mappings.

-- 
	Viktor.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 13 Apr 2017 15:01:24 -0400

> will generally go with UTS#46 (increasingly non-transitional)

Yes, everyone _knew_ it was troublesome.  But you can do that case
folding operation without embracing all of UTS#46 and getting some of
the problems, too.

The basic problem with UTS#46 is that it contains a number of quite
good ideas and some things that are harmful.  Worse, the embrace of
something like it by WHATWG has caused even more trouble, because the
answer that one gets from WHATWG any time one raises any of the issues
with their stance is that "nobody uses" the problematic cases, and so
they don't count.  At least UTS#46 doesn't take that stance about
(say) ZWJ and ZWNJ, but I'm entirely sympathetic with Florian's
original complaint upthread that the whole situation is a mess because
of too many options.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Thu, 13 Apr 2017 12:16:27 -0700

i think we can't use something in a standard that doesn't have a
canonical format. if there is a F(name) that produces a minimal I18N
result which is the same as any other F(name) that would look the same
or mean the same if written, then we should outlaw on-the-wire strings
that are not in that canonical format. if there is no such F(name) then
we should not use I18N in DNS, punycode or no.

masataka ohta pointed this out 15 years ago and he was entirely correct.

vixie

---

From: "Patrik Fältström" <[email-masked]>
Date: Thu, 13 Apr 2017 21:59:00 +0200

> we should not use I18N in DNS, punycode or no.

There are several issues here and I am sorry to say that trying to make I18N as simple as one f(x) will fool all of us.

IETF tried via IDNA2003 to create this f(x) for any unicode string x.

This was problematic for various reasons, and I am not going to go through all arguments again.

IETF then developed IDNA2008 which is a function that take any unicode string and say whether the string x is valid or not to be used as a domain name, given it is in its ACE encoded form, as an A-Label, compared to the U-Label which is the string in a standard Unicode encoding form.

We because of this do not have F(x) but instead three functions:

1. Mapping from what the end user types, copy and pastes etc...to a string that is to be used "as a domain name". This mapping is very locale dependent, and include things like case folding and what not. It is recommended that Unicode normalisation and what not is to be included here.

2. The function that says whether a Unicode string is possible to use as a domain name or not, and this is the core of IDNA2008. This function just must be, as you say, something we all agree on, or predictability on the ability to use a string will be uncertain. It is independent of locale, independent of Unicode Version. And similar things.

3. The function that convert from a U-label (the string in a standard unicode encoding, normally UTF-8) to an A-label (the ace encoding of the string, starting with 'xn--') and its inverse.

It is very important (we saw with IDNA2003) that (2) is global and (3) is separate, and that there is a 1:1 mapping between A-label and U-label so that it is possible to convert between the two forms.

Regarding (1), yes, it would be good if we could use one function, but given for example case mapping is locale dependent, it is very very hard to come up with one mapping function. We have heard many different examples of why this is a hard problem.

So I claim your F(x) exists for [2] and [3], but not [1]. And that is where I18N is hard. Very hard.

   Patrik