Re: Using a new class for IDN

Hi Dan,
As an advocate for a clean approach to IDN I would like to offer my support.
Though I think EDNS is a better solution because IDN is really just another
domain name and should exist in both classes, I dont mind seeing a new class
being created for IDNs because I believe that the world wants a good forward
looking architecture for IDN and will move towards the new class as it
becomes available.
Edmon



----- Original Message -----
From: "Dan Oscarsson" <[email protected]>
To: <[email protected]>; <[email protected]>
Sent: Sunday, June 02, 2002 4:58 AM
Subject: [idn] Using a new class for IDN


> John C Klensin published the idea to use a new class in DNS
> for IDN. As I now feel that there is no way to stop IDNA, I have
> looked on how to introduce native handling of non-ASCII in DNS
> in a easy way. While it can be done by EDNS and a new label type,
> I think a cleaner, and probably easier to implement, way is
> to use a new class. Using a new class you get:
> - a simple flag telling the DNS server that all text data (both
>   labels and other) are in a well defined encoding of UCS.
> - clients get a error response if server do not support new class.
>   Telling the client to retry using old IN class.
> - Basic support in DNS can be added by just defining all records
>   in IN and new class. When in IN, use ACE encoded labels.
>   When in new class, use UCS. A more efficient implementation can
>   be added later.
> - A clean break from the old DNS world.
> - Compared to IDNA you get the same native encoding of
>   characters everywhere (all labels get internationalised, and
>   text fields like those in HINFO and TXT gets well defined) and
>   case can be preserved in responses.
>
> I could write a draft for this, if some of you would support it.
>
> IDNA as it is today, does complicate the above way in at least two
> ways:
> - The count of characters that can fit into 63 octets differ
>   when using ACE-names and native UCS-names.
>   The above solution is very simple if we can require all
>   names to fit in 63 octets. Then no new label types are needed
>   and the DNS server use exactly the same records in both
>   classes, only encoding in labels differ.
> - IDNA does not define that the same ACE/string preparation should
>   be used in all labels.
>
> To make things easier for the future, IDNA should require that
> the IDN in the ToUnicode form must not be longer than 63 octets.
> That is, both the ACE-form and the UCS form must fit in
> 63 octets.
>
>
> Do we plan for a future with a fully internationalised DNS now?
> Or maybe we do not need one?
>
> Regards,
>
>    Dan
>
>