[idn] Using a new class for IDN

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

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