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