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

["Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>]

Funny, I find myself almost entirely agreeing with Eric Hall on this
topic.  :)

"Eric A. Hall" <ehall@ehsco.com> wrote:

>   1) The lower seven-bit range is definitely interpreted as ASCII.

For all text strings, yes, which at least includes the names and values
of all resource records defined in 1035.

>   2) The upper eight-bit range is definitely undefined for those RRs
>      and classes which do not have an interpretation.  While some new
>      RR and/or class could define an interpretation for the eight-bit
>      range, the existing RRs in the IN class treat this range as
>      undefined values.

Agreed.

>   3) STD13 is quite clear that queries may contain eight-bit codes.

Agreed.

> So, taking all of the above into consideration, how do you treat
> the eight-bit codes for existing RRs in the IN class, where an
> interpretation has not been defined?

Good question!

> 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.

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.

> If you want to enforce an interpretation of the eight-bit range, you
> have to use new RRs, a new class, an EDNS identifier, or something, in
> order to distinguish between the legacy and modern systems.

Agreed.

AMC