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

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

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