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

[John C Klensin <klensin@jck.com>]

--On Thursday, 30 May, 2002 21:52 +0000 "Adam M. Costello"
<idn.amc+0@nicemice.net.RemoveThisWord> 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