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

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

--On Thursday, 30 May, 2002 11:01 -0500 "Eric A. Hall"
<ehall@ehsco.com> wrote:

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

Well, I'm not sure, partially because I am not convinced that
1034/1035 permit (or require) an octet-by-octet interpretation.
See below.  Also, in the robustness principle, we have a rule,
applicable to the DNS as to other Internet protocols, that
governs the model for loving one's neighbor especially in cases
of ambiguity.

> There are three elements here:
> 
>   1) The lower seven-bit range is definitely interpreted as
> ASCII.

For RRs whose labels are character strings, yes, certainly.

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

Yes.

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

Yes.  The question is whether this is appropriate (given both
STD13 and the robustness principle) for RRs with character
labels (i.e., the "existing" RRs in Class IN) for for an query.
Or, put differently, while it is clear that eight-bit codes can
be sent in a query (given the query structure and the ability to
specify "ANY" as a query type, any other conclusion would lead
to contradictions), it is not clear how a server should
interpret such a query when it would match an RR with a
character label.

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

As has been pointed out, "undefined" means "undefined" and,
given interoperability and the robustness principle, something
that should not be (attempted to be) used.  It doesn't mean
"non-alphabetic" -- that constitutes defining it.  I believe
that loving my neighbor, under the robustness principle, implies
that I don't send that neighbor stuff that is undefined.  And I
believe that, under robustness principle, that neighbor should
_accept_ anything I send it, but that its responses should avoid
returning as a match anything that might not actually be a
match, i.e., that something that is "undefined" doesn't match at
all, regardless of the bit patterns.

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

Yes.  But in language that, given the matching rules and the
above interpretation of "undefined" (which I would claim is our
historic one), becomes almost as unclear as that in 1034/1035.

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

Or, with equal or greater justification, "... to be treated as
undefined codes, and not matched at all".

      john