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

--On Monday, 10 June, 2002 10:54 -0700 Dave Crocker
<[email protected]> wrote:

> At 12:33 PM 6/10/2002 -0500, Eric A. Hall wrote:
>> Specifically, I am trying to get IDNA decoupled from
>> mandatory use of nameprep so that the applications will be
>> able to use domain names which are not lowercased and
>> normalized, if those applications have such a need. This will
>> not affect normal operations, as the majority of the resource
>> records will still need to use nameprep anyway. It's a pretty
>> simple request: make the profile selection separate from the
>> codec.
> 
> The interpretation of domain name strings is not subject to
> application-specific choice.
> 
> The DNS is a single, unified, global service and it defines
> its own strings.  Interpretation (comparison) of strings must
> work the same in all cases.
> 
> For everyone.  Everywhere.  At all times.
> 
> What you are seeking is in fundamental opposition to global
> interoperability of the DNS.

Dave,

I'm neither supporting nor opposing Eric's proposal (intent) at
this stage, largely because I have yet to get my mind completely
around enough of the detail of what he is really suggesting to
understand its implications.  But let me suggest something
slightly narrower, which I think is consistent with global
interoperability, in the hope of clarifying the conversation.

At least in principle, we have traditionally been able to have
three types of neatly hierarchical rules about the content and
interpretation of a DNS label:

	(i) Rules that apply DNS-wide, to all Classes and RR
	types, now and in the future.
	
	(ii) Rules that apply to all RRs within a particular
	Class.
	
	(iii) Rules that apply to a particular RR (by
	definition, within a particular Class).

One way of looking at the difference of opinion some of us have
had about octet interpretation and mapping is that some of the
documents have historically not been clear enough as to whether
they are expressing rules about a semi-enumerated set of RRs,
about all RRs in a Class, or about the DNS generally, but that
is a separate conversation that I don't want to restart here.

Nothing above provides for an application-dependent
interpretation, so you and I are in agreement about that and, if
that is what Eric really intends, we presumably jointly disagree
with him.

Now IDNA (and friends) add a new class of rule, which is to
permit giving different semantic interpretation to a label based
on the _content_ of that label, e.g., whether applications are
expected to map it to or from Unicode based on the presence of a
prefix.  Suppose Eric said, consistent with the typology above,
that we should specify that IDNA (and that
prefix-interpretation, nameprep, etc.) are to be applied only to
particular RR types within Class=IN, or to all of Class=IN but
not to Classes as yet undefined.   I'd be sympathetic to that: I
think tighter and more conservative definitions (that can be
expanded in the future if needed) tend to serve us well in the
long term.

And, to the degree to which this discussion is really about
getting us to a clear statement about where IDNA (and nameprep)
should and should not be applied, it seems to be to be a
legitimate, and necessary, part of the IETF discussion on IDNA,
nameprep, and the current set of documents.  

One could even argue that, to the extent to which the range of
applicability is not precisely defined today, or has not been
discussed sufficiently for a legitimate claim of WG consensus to
be made, it could be taken as evidence that the documents are
not ready for prime time.

     john