[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt
Dan Oscarsson <Dan.Oscarsson@trab.se> wrote:
> Why is it that IETF can change the definition on for example what
> characters are allowed in host names without an identifer of some
> kind,
That's not what we're doing. In data intended for machine consumption
(protocol messages, function arguments, machine-readable file formats,
etc) we are insisting that domain names continue to be ASCII-only;
non-ASCII domain names may appear only where they are explicitly invited
by new protocols/interfaces/formats (or new versions of old ones).
In data intended for human consumption (like email message bodies and
user interfaces) we (IDNA) are being more lax, and encouraging domain
names to use the same charset that is used for all text in that context.
The rationale is that compared to machines, humans are better able to
cope with change, and much less tolerant of unintelligible garbage.
(There is a case to be made against this laxity, and Eric has made it.)
> For example, the URI definition have changed making those applications
> following the original specification reject what later revisions see
> as valid URIs.
That's fine. If the only difference between the old standard and the
new standard is that old software rejects things that new software
accepts, that's the best you can hope for.
What's bad is if old software and new software both accept the same
things, but behave differently. That's the situation we're afraid of
with 8-bit domain names in DNS. Existing DNS servers already accept
8-bit names in queries. If we were to declare that such queries must
now be handled differently, we'd create interoperability problems.
AMC