> If the point
> of the working group is to allow people to use non-US-ASCII
> labels in host names,
That has been the idea all along, even if the term "domain name"
has been used.
> then there is a lot of work to be done, not least of which are:
>
> - figuring out what encoding to standardize on;
> - figuring out how to augment the DNS tree to support those encodings;
> - identifying and/or figuring out how to deal with those
> protocols that are affected by changes in host names;
>
> As an aside, my understanding of the "UTF-5"/CIDNUC proposals
> is they attempt
> to avoid the i18n implications by insuring that non-"host
> name" labels are
> encoded in the "host name" character set ("a-z", "A-Z",
> "0-9", and "-"). The
> UTF-8 proposal makes no attempt at avoidance. As such, it
> isn't clear to me
> from the wording of the draft requirement doc how one could
> actual meet the requirements using UTF-8.
Some kind of migration will need to be done. E.g. maintaining
an "ASCII" alias for an IDN, and have some suitable mechanism of
finding it for those systems that support IDNs, and use the
ASCII alias when communicating with systems that don't yet support
IDNs. One will also need a way of figuring out if IDNs are
supported "on the other side" or not. E.g. for ESMTP check if
an (as yet hypothetical) UTF8HEADERS extension is supported.
Let me note again that CIDNUC and such are unacceptable, since
they are reencodings into ASCII that turn (for some people)
understandable names into complete gibberish, and given the QP
(and BASE64 for text) experience I have no optimism of having
that gibberish properly decoded whenever presented to a user.
The encoding must be a generally accepted one for plain text,
and given a need for ASCII backwards compatibility resuirement,
which I think there is, and a requirement to support names in
any script, UTF-8 is the only option.
Kind regards
/kent k