Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt

From: "Adam M. Costello" <[email-masked]>
Date: Sat, 1 Jun 2002 04:52:37 +0000

Dan Oscarsson <[email-masked]> 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

---

From: John C Klensin <[email-masked]>
Date: Mon, 03 Jun 2002 08:19:06 -0400

--On Thursday, 30 May, 2002 21:52 +0000 "Adam M. Costello"
<[email-masked]> wrote:

>> Since they are undefined, they are not alphabetic
> 
> That's the one point where I don't follow you.  If they are
> undefined, then their alphabeticness is undefined, and hence
> the proper way to compare them is undefined.  RFC 1035 says
> that comparisons of text strings must be case-insensitive
> "without exception".  Doing an exact match of 0x80-0xFF is
> guaranteed to violate that requirement for every charset I
> know of that uses the 8th bit.

Yes, exactly.  This is the problem that keeps leading me back to
the belief that we have RRs whose labels are alphabetic
(characters) and RRs whose labels are binary.  If the former,
and octet values of 0x80 and above are permitted, then I think
_defined_ case mapping rules are required.  Until and unless
they are defined, the robustness principle argues fairly
strongly that such values should not be sent or put into tables,
since there is no predicting what servers will do with them
(i.e., no specification of undefined behavior).

By contrast, if one really has an RR with a binary label, I
think it would violate the intent of the protocol to make
comparisons with any of the bits masked, even if the relevant
octets fall in the 0x00 through 0x7F range.

> If you send a query containing an 8-bit name, I think you do
> so at your own risk, because RFC 1035 doesn't say what the
> server will do.

And "do so at your own risk" and "different servers can do
different things and still conform to the spec" amount, given
the robustness principle and a commitment to interoperability,
to a requirement to not do it at all.

    john