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

[Dan Oscarsson <Dan.Oscarsson@trab.se>]

>From: Patrik Fältström <paf@cisco.com>

>
>>>  - 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*.
>
>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