Subject: Re: [idn] lowercased hostnames (was: naming syntax rules)

From: Dan Oscarsson <[email-masked]>
Date: Fri, 14 Dec 2001 16:07:05 +0100

Eric wrote:

>> ACE is suitable for backward compatibility, if used in the IDNA way.
>> But is bad to restrict current or future needs just because of limits
>> in a backwards compatible solution is bad. If ACE gives limits, one
>> more reason to also have a solution that can handle more.
>
>There are multiple secondary ramifications from this approach. For
>example, this requires that normalization occur before lowercasing. This
>also requires that case conversion be removed from nameprep and moved to
>the ACE encoding reference specifically.

Everything depends on what nameprep is. The reason I have wanted
us to separate out things in different drafts is because they
need not be together.

ACE is only how to encode non-ASCII into ASCII. It does not
require things to be lower case.

And what is nameprep? Of what I have seen nameprep is how to
convert names into a format that is needed to make IDNA
work for ACE encoded names.

I have always worked for a wide base plattform to build on.
IDNA by forcing us to use a binary comparabel label is
removing some of the basics of DNS today.
IDNA/ACE as a pure backward compatibility would be fine, those seeing
ACE would never use anything else.
IDNA/ACE as the base for non-ASCII in DNS does put restrictions where
there isn't any in DNS now (like case-insensitivity).

I do not want to remove nice features of DNS just because some people
do not want to upgrade their DNS servers (and those people will
never get DNSSEC or other new features).

It is fine for those who want, to start with IDNA/ACE, but
I do not want that to make it impossible for us who want to
go for the DNS server solution to get the full benefits
of that solution. Everybody have to accept to spend some CPU
power when moving past ASCII.

   Dan

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 14 Dec 2001 11:31:24 -0600

> require things to be lower case.

In the context of this discussion it does. For systems that decode ACE
into the canonical UCS characters, the unencoded characters can be either
case. For systems that DO NOT decode ACE, the unencoded characters must be
case-preserved.

For example, consider a PTR which returns RR data that contains an ACE
encoded mixed-case IDN. If that RR data is received and processed by a
legacy system which does not decode the ACE data, then any subsequent
forward lookups must match the encoded representation exactly. This will
require that the forward-lookup A RR have the exact same owner name as the
PTR RR data. Furthermore, this must be used for ALL forward lookups,
unless every encoded version of every possible case combination is
delegated simultaneously.

> work for ACE encoded names.

Nameprep defines the characters which are legal, their normalized forms
(preventing un-normalized and normalized equivalents from being delegated
to two separate bodies), and will also need to have much of the rules
we've been discussing lately (such as no diacritical marks in the first
character position).

> never get DNSSEC or other new features).

The opposite is also true: we should not make the entire system incredibly
complex just so we can have pretty domain names with pretty casing. These
are identifiers, not hairstyles. We should be favoring efficiency.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/