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

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

--On Monday, 10 June, 2002 14:01 -0500 "Eric A. Hall"
<ehall@ehsco.com> wrote:

> on 6/10/2002 1:29 PM John C Klensin said the following:
> 
>> 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.
> 
> Actually what it does is require that all domain names be
> converted into a lowercase and normalized form, even if the
> domain name is only supplied as data in the resource record.

I think it does both of those things, and that they are
independent issues.  In a perfect world, they would be
independent of each other, but it isn't a perfect world.

>> 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.
> 
> What I want to do is define this on a per-name/per-RR basis:
> 
>   <nameprep> A <address>
> 
>   <nameprep> NS <nameprep>
> 
>   <nameprep> MX <pref> <nameprep>
> 
> Those rules result in exactly the same usage as the current
> IDNA model. I'm not asking to turn everything upside down.
> What I'm asking for is that if an application needs to use an
> uppercase or non-normalized domain name for some reason, that
> they be allowed to do so, but only after defining a strong
> profile. Eg:
> 
>    <fooprep> FOO <barprep>
> 
> This doesn't hurt anybody and puts the i18n namespace on equal
> footing with the STD13 namespace.

Well, if you want to define it on a "per-name/ per-RR" basis,
which is what both your statement and your examples seem to say,
I think we are 95% there.  We already have per-RR rules (e.g.,
different name-formation rules for SRV than for A RRs) and, at
least wrt what to do if one gets back a name that contains an
ACE prefix, per-name rules.

> Nobody has yet told me why this won't work.

It seems to be that "work" has little to do with it -- this can
be seen as a precision of definition problem.

In that regard, it seems to me to be useful to avoid talking
about "equal... to STD13 names", or "hostnames versus domain
names" here, as those references are more likely to cause more
confusion than to shed light.

Instead, what is needed is one very clear paragraph in the IDNA
document (I think).  That paragraph should say that IDNA is to
be used (with nameprep, etc.) for the representation of
non-ASCII domain names in labels associated with RRs of type
<list 1> in Class=IN, that it MUST NOT (?) be used with RRs of
type <list 2> in Class=IN, and that it SHOULD NOT be used with
RRs of type <list 3> in Class=IN until and unless a
standards-track specification is produced that specifies
otherwise.  It should say similar things about data fields (for
MX, NS, CNAME, etc (?)) using similar lists.  It should, I
think, go on to specify that any future RR definition (in
Class=IN or otherwise) needs to specify whether or not IDNA is
to be applied and, preferably, should specify what happens if
that statement is left out.

I am assuming that <list 1>, <list 2>, and <list 3> are
disjoint, that they together include all Class=IN RRs that have
been defined and not formally deprecated, and that it is
possible that <list 2> and/or <list 3> might be null.

Would that meet your needs?   Is that what we are really talking
about?

If so, this is just a "more specification and clarity, less
hand-waving and ambiguity" issue, and it is hard to be opposed
to that.  I think.

     john