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

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

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.

(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
direction-- but that is at least the basis for a claim of
ambiguity (or that I am an idiot, which is also a reasonable
possibility).

      john




--On Wednesday, May 29, 2002 11:59 PM +0000 "Adam M. Costello"
<idn.amc+0@nicemice.net.RemoveThisWord> wrote:

> Mark.Andrews@isc.org wrote:
> 
>> The alphabetic characters in this context are 0x41-0x5a and
>> 0x61-0x7a (zero parity ASCII A-Z, a-z).  All others are
>> compared exactly.
> 
> That may be what the popular DNS implementations do, but I
> don't see RFC 1035 saying how to compare 0x80-0xFF.
> 
> "Eric A. Hall" <ehall@ehsco.com> wrote:
> 
>> You are the only one that is unclear on it.  0x80-0xFF must
>> match exactly.
> 
> I'm not the only one.  Here's an excerpt from a message by
> John Klensin:
> 
> http://www.ietf.org/mail-archive/ietf/Current/msg15742.html
> 
> RFC1035> For all parts of the DNS that are part of the official
> RFC1035> protocol, all comparisons between character strings
> (e.g., RFC1035> labels, domain names, etc.) are done in a
> case-insensitive RFC1035> manner.  At present, this rule is in
> force throughout the RFC1035> domain system without exception.
> 
> John Klensin> To emphasize, that is "all parts" and "all
> comparisons", John Klensin> not "unless you happen to find the
> high bit turned on".
> 
> John Klensin> An existing and conforming implementation has no
> way to do John Klensin> those required case-insensitive
> comparisons outside the John Klensin> ASCII range.
> 
> Robert Elz> No, nor is it required to.
> 
> John Klensin> There we probably disagree -- I suggest that the
> text is John Klensin> at least ambiguous and might require it.
> 
> AMC
> 
> 
>