Subject: [idn] IDNA applicability: per RR/Class or DNS-wide (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt)

From: John C Klensin <[email-masked]>
Date: Tue, 11 Jun 2002 10:38:15 -0400

My third issue was:

	Should the applicability of IDNA in the DNS context, and
	the xxx-prep procedures to be used with it, be specified
	on a per-RR (and per-Class) basis?

This is the core of the substantive part of the discussion Eric
and I have been having (at least to me: Eric has, I think, a
slightly different focus).

It has two parts:

(i) The DNS now has different rules for valid label forms and
parameters for different RR types (e.g., "A", "MX", etc., are
recommended to contain only LDH names, while "SRV" uses names
that are in ASCII but violation LDN norms) and the core DNS
specification clearly anticipates an even broader range of
names/ labels.  IDNA should recognize this and anticipate the
use of different "foo-prep" profiles of stringprep with
different RR types and/or classes, rather than forcing
everything into a "nameprep" model.

(ii) It is unreasonable and undesirable for IDNA to specify
behavior for Classes and RRs not yet invented.  Constraints like
that are nothing but an invitation to trouble.

Suggested remedies:

(1) The IDNA document should be somewhat restructured.  See the
"is the specification proper..."  note.

(2) The specification should be changed to prohibit the use of
IDNA in conjunction with the DNS in the absence of a document
that specifies its applicability to a specific RR type and
Class.  As an intermediate position between an earlier
suggestion of mine and one of Eric's, those documents should be
required to be standards-track for any standards-track RR; it is
possible to be more flexible about others.

(3) The protocol should be modified to either require that the
preparation function be invoked before other IDNA steps and
separate from them (Eric's preference, as I understand it), or
that the preparation function be specified as a parameter to
IDNA (my preference).  The documents described in (2) will
therefore be required to specify, for each RR type and Class to
be processed with IDNA, and for labels and any relevant data
(parameters) separately, the preparation function to be used.
And, of course, if those documents are standards-track, then the
relevant preparation function would constitute a normative
reference and hence would also be required to be standards-track.

Of course, such documents need not be a big deal.  The type of
table I anticipated in an earlier note could easily sweep in a
large number of RRs and I would hope that all existing
standards-track RRs could be covered by a single document.

This model is just much cleaner.  It makes IDNA more flexible
for other uses and protocols.  And it doesn't prevent the use of
non-ACE systems (and binary labels generally) for RRs and
Classes that are yet to be specified.

This work is long overdue.  It is a major and important change
for the Internet and it is risky for the DNS-as-used and as
perceived by users.  It is, IMO, worth a bit of extra effort to
get it right if we are going to do it at all.

         john

---

From: "Adam M. Costello" <[email-masked]>
Date: Tue, 11 Jun 2002 22:00:32 +0000

John C Klensin <[email-masked]> wrote:

> recommended to contain only LDH names, while "SRV" uses names that
> are in ASCII but violation LDN norms) and the core DNS specification
> clearly anticipates an even broader range of names/ labels.  IDNA
> should recognize this and anticipate the use of different "foo-prep"
> profiles of stringprep with different RR types and/or classes, rather
> than forcing everything into a "nameprep" model.

Different validity rules is not at all the same thing as different
profiles.  The profile is mainly about how labels are compared.  In
DNS now, the same comparison rules apply to all labels.  If we allow
multiple profiles, that's the same as allowing different comparison
rules for different labels.

I have no problem with different RR types imposing additional
restrictions on what is valid.  IDNA already anticipates restrictions in
addition to (not instead of) Nameprep:

    It is expected that some name-handling bodies, such as large zone
    administrators and groups of affiliated zone administrators, will
    want to limit the characters allowed in IDNs further than what
    is specified in this document, such as to prohibit additional
    characters that they feel are unneeded or harmful in registered
    domain names.

AMC

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 11 Jun 2002 17:21:16 -0500

> rules for different labels.

I have to disagree with this again. The comparison rules will be identical
for all profiles -- each of them comparing exact sequences of octets --
with the only difference being the capitalization and normalization rules
that get used to generate the question. That's it. The question formation
differs, comparison is identical.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: "Adam M. Costello" <[email-masked]>
Date: Tue, 11 Jun 2002 23:41:39 +0000

"Eric A. Hall" <[email-masked]> wrote:

> > If we allow multiple profiles, that's the same as allowing different
> > comparison rules for different labels.
>
> The question formation differs, comparison is identical.

We're just using different terminology.  When I say "comparison",
I'm refering to everything involved in the comparison, including the
preparation, even if it's done at a different time.

Consider this scenario:  One user types a domain label containing an
uppercase letter O-umlaut, another user types a domain label containing
a lowercase letter o followed by a combining umlaut.  Do these two
labels match?  Yes, no, or "well maybe, it depends"?  For ASCII domain
names, the answer has never been (and never will be) "maybe", there
is always a yes or no answer that is apparent to anyone, without any
additional information.  That simple model underlies everything that
has been built on top of domain names.  I think trying to work out the
implications of throwing "maybe" into the mix is more trouble than it's
worth.

AMC

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 11 Jun 2002 19:19:57 -0500

> We're just using different terminology.

You're arguments have made it quite clear that you think this change
affects server behavior in some way, when it does not.

> labels match?

How they are stored is all that matters. If they are stored as typed then
they will be represented by different octet sequences and will therefore
match as different sequences. If they are normalized to the same sequence
as part of a stringprep profile before they are stored then they can only
be represented by the resulting octet sequence.

> I think trying to work out the implications of throwing "maybe" into
> the mix is more trouble than it's worth.

There is no "maybe" here either.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 15 Jun 2002 14:37:59 -0700

>everything into a "nameprep" model.

Or IDNA should focus only on solving the URL/mail naming issue and defer 
the rest.  The deferral will not be -- cannot be and has not been -- 
entirely ignoring the future effort for other aspects of RR domain label 
specification.  But it need not be required to solve the whole problem for 
everyone for ever.

>that are nothing but an invitation to trouble.

damn.

i think i agree with your suggestions, though #3 is a bit discomfiting.

>for other uses and protocols.  ...
>This work is long overdue.

grrrr.  mumble.  i agree.  grrrr.

d/

>----------

Dave Crocker <mailto:[email-masked]>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850