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

["Eric A. Hall" <ehall@ehsco.com>]

John C Klensin wrote:
> 
> The disagreement between kre and myself about how to read  the
> spec is, indeed, I think the key to this issue.  It should be
> noted that we disagree about two things, which are separate:
> 
> (i) Whether the correct reading on the DNS specs is that "ASCII"
> versus "binary" is a function of RR type, or a function of the
> bits in the octets. I take the text to suggest that _only_
> ASCII (note, ASCII, not LDH) is permitted in RR types defined in
> or by 1034/1035, but that "future" RR types (and Classes) can be
> defined to have binary labels.  Robert takes it as permitted
> characters outside the ASCII range, with case handling undefined
> for those characters.

You are both correct, but Robert is more correct. Note that Robert didn't
disagree with you "future" use. Essentially this boils down to having
biblical scholars arguing over how MUCH they should love their neighbor.

There are three elements here:

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

  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.

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

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? You have to treat them as undefined. Since they are
undefined, they are not alphabetic, and the non-alphabetic comparison rule
kicks in.

Whether or not any of these RRs allow eight-bit codes to be defined is a
totally different question, but one which was answered in the affirmative
by RFC 2181.

So, unless a new RR or class (or EDNS tag, or whatever) defines some
specific interpretation, the eight-bit codes are to be treated as
undefined codes, and must match exactly.

> (ii) Whether the documents are clear or not, at least on this
> matter.  Robert believes that they are.  Perhaps we are in
> agreement -- I think they are fairly clear too, but in the other

You are both wrong on that one. This is something that I hope to help fix
at some point.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/