[idn] IDNA: is the specification proper, adequate, andcomplete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt)

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

The first of my four separated issues was: 

	Is IDNA properly and adequately specified for the uses to
	which it will be put and is it designed appropriately
	for that range of uses?

One thing that Dave and I (among many others) have generally
agreed on over the years is that the primary goal of IETF
specification work is to enable and promote interoperability.
Without interoperability, we have nothing.  So a different
version of the above question is "is the IDNA specification,
including all normatively referenced and referencing documents
in addition to draft-ietf-idna-09, sufficient to enable
interoperability, or are additional or different specifications
needed".

I think the answer is probably that more specification, tightly
bound to IDNA, is needed.  In terms of the sequencing of things,
I believe that the beginning of serious work on those
specifications will expose specification problems with the
current IDNA spec.  To the degree to which that is true (and I
give some examples below), I believe that IETF procedures and
precedents dictate that IDNA should either be published as
Experimental or held as an I-D until there is adequate proof of
concept that the specification meets the needs of at least a
sample of the standards that will utilize it.

Examples of issues with the specification (few, if any, of these
are issues with the protocol):

(i) The specification now appears to say that applications can
decide to use IDNA or not.  Presumably, they can decide to use
something else instead.  It is also not clear whether "an
application", as used in the spec, refers to a standard protocol
and expectations about how all conforming implementations will
behave or to particular implementations and implementation
choices.   That is not how to get interoperability, since a
reading/receiving application will have no idea how to interpret
a string it receives.   And "receives" is key: if an
implementation issues a query in a form that appears to be an
ACE, it presumably knows what it intends, although there may be
"cut and paste" scenarios to the contrary.   But, if an
application does a DNS lookup for an LDH name (with no prefix)
with, say, an MX Qtype, and some of the result data are returned
with IDNA-appearing prefixes, then the application needs
additional clues as to how to present error messages to the
user, how to continue processing in other areas, etc.  While it
is not necessary (or possible) for the IDNA specification to
detail how it is used by all applications, setting traps for
applications without advice as to how they can be avoided does
not seem to me to be acceptable -- or promoting of
interoperability.

(ii) The specification seems inconsistent about what it about
and who needs to understand it.  It implies in several places
that it is not about the DNS and has no impact on the DNS.  But
it then makes and imposes normative DNS operational statements.
E.g., "Non-ACE labels that begin with the ACE prefix will
confuse users and SHOULD NOT be allowed in DNS zones" is
certainly a requirement about DNS and DNS zone population.

(iii) Despite the "applications can choose to do this, or not do
it" language, section 6.4 effectively implies a requirement that
any application that uses the DNS be upgraded.  That is a fairly
sweeping requirement given that we lack documents that tell
applications about other implications of doing that and that the
introductory material of the document imply that no such
recommendations will appear.  This sort of thing creates a
full-employment situation for protocol lawyers, which is
something else we usually try to avoid.

(iv) Section 7 imposes several normative requirements on name
servers and zone populations.  Again, these requirements are
buried in a document that elsewhere appears to claim that it
doesn't impact the DNS.  The third paragraph of section 7 seems
to contradict or repeal the statements of RFC 2181 that
non-ASCII strings are permitted in labels and to do so broadly
enough that it would prohibit uses favored by those who believe
that the language in 2181 is a mistake.

(v) In particular, several of the statements in the draft go
beyond almost anything we have about the DNS in trying to
narrowly constrain the behavior of RR labels and data that are
not yet defined, even in Classes that are not yet defined.  This
seems overreaching and unwise as well as confrontational with
RFC 2181 (which it, interestingly, does not cite).

(vi) I suggest that it is a useful general principle to design
service ("micro layer" to use Dave's term) protocols to be as
general as feasible without making them overly complex.  Doing
so facilitates reuse and reduces opportunities for
non-interoperability by making it explicit where variations can
occur.  It was, I believe, more or less this principle that led
to the reformulation of the nameprep/stringprep boundary.  IDNA,
by specifying nameprep profiling as part of the procedure,
violates this principle by effectively requiring a one-off
protocol for situations in which nameprep is inappropriate but
other IDNA steps would be reasonable.


My conclusions from the above are:

The IDNA specification has rolled together a collection of an
intermediate layer protocol, advice to applications, and
normative requirements on DNS use and operations (and, if a
requirement that a name server MUST NOT serve particular forms
that are permitted by RFC 1034/1035 and 2181 is intended, a DNS
protocol change).    At the same time, it handwaves about
applications adoption and does not adequately distinguish
between "application" and "implementation of an application".

Parts of it are also much broader that is required for its
purposes and are clearly beyond the scope of IDN WG competence
as a primary reviewer/approver.  The most striking example of
this is the apparent restriction to ASCII in labels and
data/parameter strings for all name servers, all RRs, and all
Classes.

It should be revised and some of that material should be pulled
out and into separate documents.  As an alternative, that
material should be highlighted: the abstract and introductory
material should indicate that these normative DNS requirements
are present, that 2181 is explicitly updated, and so on.

Finally, the apparent reach of the protocol should be narrowed
and specified, either in this document or elsewhere.  And the
protocol should recognize the reason for, and implications of,
the nameprep/stringprep split and be remodularized to permit the
IDNA _sequence_ to be used with other profiles when appropriate.
That topic is discussed in more detail in another message.

    john