Subject: Re: [idn] Needed changes to IDNA before last call

From: Dan Oscarsson <[email-masked]>
Date: Wed, 30 Jan 2002 09:40:07 +0100

>> The draft: idn-idna:
>> The ToASCII must be applied to ALL labels containing non-ASCII.
>
>Rule 1 already says:
>
>    Whenever a domain name is put into a generic domain name slot, every
>    label MUST contain only ASCII characters.
>
>"every label".

Yes, but not all labels in DNS are "generic domain name slot" from what
I can understand. For example the e-mail name label in the SOA record.

>
>> The steps need a slight change:
>>  - character restrictions will apply depending on label, it could be
>>    host name or e-mail name.
>
>Step 3 of ToASCII already says "If the label is part of a host name (or
>is subject to host name syntax rules) then perform these checks".
>
>When you say "e-mail name" do you mean the local part (before the @)?
>That's outside our jurisdiction.  Another working group will have to
>decide how to internationalize email local parts.  We can only tell how
>to deal with domain names.

That is right, but the ACE encoding is not what defines the way to
internationalise host names. ACE is a transport encoding.
To support the future standard of non-ASCII characters in e-mail, the
labels in DNS that are used for e-mail must handle non-ASCII characters.
You could have the e-mail group define a "E-nail ASCII Compatible
Encoding"
but that is really stupid to have in DNS. Thare should only be ONE way
to encode non-ASCII on top of ASCII in DNS. There are already to many
different ways to encode non-ASCII on top of ASCII and it is a very
difficult thing to handle in software.
Therefore we should have ONE standard for all labels in DNS.

>>  - Encoding into ACE must use Punycode WITH case marking so that
>>    case can be restored when using ToUnicode.
>> 
>> ToUnicode is fine, but decoding Punycode must restore case.
>
>I have already argued for mixed-case support as best I can.  I couldn't
>quite get it *mentioned* in the IDNA and Nameprep documents.  You don't
>have a prayer of getting it *required*.
>
>Of course, the working group that internationalizes email local parts
>would have the option of writing a spec that requires Punycode with
>mixed-case support.

Yes, that is one of the reasons why case should be preserved during
ACE conversion in DNS. To suppport the systems that require
case preservation.

   Dan

---

From: Dan Oscarsson <[email-masked]>
Date: Wed, 30 Jan 2002 09:49:47 +0100

>From: Patrik Fältström <[email-masked]>

>The problem is that the definition of "case" is very hard to make. And, if
>you preserve case, why not preserve other steps of nameprep?

Because Punycode have been selected and it only supports case
preservation.
If I remember correctely it is less than 1000 letters in UCS that has
case,
so the support is fairely simple to handle. It is also what RFC 1035
says:
case should be preserved if possible.
It is also good to have as long as some systems require e-mail addresses
to be case sensitive and we have to handle those in DNS.

>
>Remember, nameprep is done before punycode, so when the string is passed to
>the punycode (transport) encoding, the original string is lost.
>
That depends on implementation. In much software it would probably be
best
to combine "nameprep" with encoding to ACE. The order things are
described
in the document does not have to be followed as long as the result is
the
same. Changing order might make things much more efficient.
For example the definition on what characters are forbidden I would have
as an application matter while the rest could be done by a common
routine
for all software.

   Dan