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
