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

From: Dan Oscarsson <[email-masked]>
Date: Thu, 30 May 2002 13:01:14 +0200

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:

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

RFC 2181 and 2929 both clearly says that the label in DNS
can include any octet value including zero.
RFC 2929 also talks about text and binary labels, the binary
label is defined in RFC 2673 so the normal label in DNS is
a text label. RFC 2929 also says that for the text label,
ASCII upper and lower case must be treated as equal.

So while RFC 1034/1035 is vague in non-ASCII octet values,
the above RFCs clearly defines that a text label can be
composed of any octet value and that for the octet
values equivalent to ASCII code values the matching
must be case insensitive (but original case should be
preserved in answers as stated by RFC 1035).

   Dan

---

From: John C Klensin <[email-masked]>
Date: Thu, 30 May 2002 10:52:56 -0400

> ASCII upper and lower case must be treated as equal.

This is absolutely correct, and I didn't mean to suggest
otherwise.  But we generally don't let BCPs or Proposed
Standards  replace text in full Standards, at least without
being very explicit that they are doing so.  And 2181 was, if I
recall, approved on the assumption that it did not make changes
to 1034/1035/1123 in this area.

So, if one wants to restate the question in terms of 2181, it
would be whether the interpretation of 2181 (which is, not
surprisingly, consistent with kre's interpretation) is correct
given the language of 1034/1035.  Or, if we conclude that
1034/1035 is ambiguous in this area (2181, if I recall, claims
that it is not), what the informed consensus of the community is
on the correct fix given today's knowledge of the various issues
and risks.

I note in passing that the "compare ASCII in a case-insensitive
way, but treat any octet above 0x7F as binary with no
case-mapping" interpretation would be very hard on those who
advocate direct use of UTF-8 but who believe that users of
Greek, Cyrillic, French, Swedish, Norwegian, etc., are as
entitled to case-independent interpretation as users of English.

This is, after all, why we have maturity levels for standards.

    john