[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[idn] Needed changes to IDNA before last call



As I have the feeling that the IDNA way be the internationalisation
of the DNS in the near future, at least, and we now also have
last call on the drafts for it, I have looked at what I think is needed
before they can replace a complete native UCS solutions.

A quick look at the latest drafts make me happy, they are much closer
to what is needed now than they were before. Previously they have been
too focused on "host names".

To be complete, all DNS labels containing non-ASCII must be ACE
encoded. All using the same encoding and stringprep profile.
This will allow us to use non-ASCII everywhere in DNS excpet in things
like for example TXT and HINFO records.

I suggest the following is done:

The draft: idn-nameprep
Title change: Stringprep profile for Internationalised DNS labels.
It is for more than host names. Unless my quick look is wrong
it should work for all types of labels.

The draft: idn-idna:
The ToASCII must be applied to ALL labels containing non-ASCII.
The steps need a slight change:
 - character restrictions will apply depending on label, it could be
   host name or e-mail name.
 - 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.

-
With the above changes the IDNA way is much more acceptible.
It is now a general solution for non-ASCII in labels, not just
some special cases. And it preserves the case semantics of
current DNS while at the same time allows the simple ASCII
matching algorith to be used.

If you do this you get all important things I have wanted my
native UCS solution to do (except using native UCS) and I
can support it.

Keep up the good work, you are nearly there.

   Dan