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
