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

Reply via email to