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

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

--On Friday, 21 June, 2002 15:03 +0200 Erik Nordmark
<Erik.Nordmark@sun.com> wrote:

>> Because we have tried that approach, mostly inadvertently,
>> many times before, and it has always gotten us into trouble.
>> "You are not permitted to do this" leaves us in a position
>> where we can later make it permissible and give it an
>> interpretation at the same time.  "It is undefined" seems to
>> invariably create a community of people who are sure what
>> "undefined" means --i.e., who assign a meaning to it-- and
>> who then become a serious, installed-base, impediment to any
>> other interpretation.  And "this applies globally" will be
>> taken as the basis for a claim that we are making a seriously
>> incompatible change if we try to do something else in some
>> other name space.
> 
> John,
> 
> I'm not saying that leaving things undefined is the way
> forward. But you seem to be saying, in addition to wanting
> things to be well defined, that there needs to be an attempt
> to either predict the future or only apply IDNA in the
> smallest possible context.

Let me restate the second alternative.  I believe there are
several different ways to do it, but

	* At this time, IDNA should be applied only to
	well-understood cases
	
	* Both it, and any alternatives, should be prohibited
	elsewhere, leaving future cases for future specification.
	
	* We have a procedure for loosening the rules --
	applying IDNA or other conventions elsewhere -- in the
	future if needed.

is the essence of the suggestion.

> I think there is a 3rd alternative which is to, unless
> explicitly overridden elsewhere in the future, apply it
> everywhere. This can be perfectly well-defined as far as I can
> tell and it means that any changes can be done with the
> well-defined basis as a foundation.

Actually, I suggest we have never been able to do that and that
it is exactly the source of my concern.  We try very hard to
avoid getting into situations in which we standardize something,
let it get deployed, and then say "sorry, we are changing that,
you must do something else in this particular case".  IESG has
almost never approved such things, and IETF action has mostly
failed in the marketplace when we have tried to do so.
Installed base is important, installed base backed by our
standards is irreversible.

>> 	* RFC821 specified Internet email transport in terms of
>> 	ASCII.  It didn't explicitly (enough) prohibit sending
>> 	non-ASCII ("8bit") characters.  [...]
> 
>> 	* RFC 1034 and 1035 define labels in terms of ASCII
>> 	characters, but contains more or less vague language
>> 	about how labels containing octet values that cannot be
>> 	ASCII are to be interpreted.  [...]
> 
> The above two examples seems to me to be cases of loosly
> defined specifications. I agree that we want to avoid that in
> the IDN space to the extent possible.

I agree that they are loosely defined.  And that more precise
definition is better.  But it seems to me that precisely
defining something to cover things that are not invented yet is
not the way to go unless it is necessary and we have a clear
picture.  I.e., I am trying hard to avoid having to predict the
future or to constrain it.

>> 	As just one example of this, suppose we come along later
>> 	and want to put Unicode more directly into the DNS.  We
>> 	know that UTF-8 isn't a particularly efficient encoding
>> 	-- its design is strongly influenced by the need to be
>> 	compatible with octet-based systems.    We also know
>>...
 
> I think the place where this discussion belongs is the now
> expired draft-ietf-dnsext-unknown-rrs-02.txt. But I note that
> it is lacking as well in that it silently seems to assume that
> all the owner names are ASCII text by saying:
>    The owner name is
>    still set to lower case.

Yes, probably, although I haven't looked at that draft.  I'm
happy to have that discussion anywhere you direct.  My concern
is that the IDN WG, as a side-effect of a passing phrase in a
document that does not appear to have been carefully examined in
the DNS community and that isn't supposed to impact the DNS, is
imposing a major constraint on future DNS use and expansion.
That doesn't seem right to me.

> I agree it is highly desirable to be able to define new RR
> types and/or classes without the ASCII case insensitive
> comparison of the owner names. But the feasibility of this is
> a function of what existing DNS implementations do with
> unknown types and classes. If it turns out that this isn't
> possible one can still envision efficient encoding of Unicode
> owner names e.g. by applying the Bootstring algorithm (used by
> punycode) but have the output code set be e.g.
> 0-0x40,0x5b-0xff i.e. avoid using bytes which an ASCII case
> insensitive comparison would trip on.
> 
> The alternative seems to be to embark on discussions whether
> RR type X (for different values of X including e.g. SRV,
> NAPTR) benefits enough from IDNA to make that RR type be
> covered by the IDNA specification. I fail to see how this WG
> can have expertize in determining the usage of all defined RR
> types. Even if the WG had that expertise I still wouldn't be
> suprised there were radically opposing judgements about
> "benefit enough from  IDNA" for some types.

Ah, but you see... that is the point.   With the current
wording, at least as I read it, the WG is trying to do exactly
that, and to do it without looking at the RRs involved.  But I
can live with even that.   Let's assume the text said something
more like "IDNA can be applied to all currently-defined and
registered RRs in Class=IN, but is not to be applied to
subsequent RRs or other Classes unless their definitions
explicitly say so".  I wouldn't be wild about that, but, perhaps
unlike Eric Hall, I'm also not willing to lose sleep over it.

But, if we are ever going to be able to extend the DNS in ways
that impact the name space, we must avoid setting a standard
that applies to those spaces where we haven't ventured.  So, it
seems to me that the right thing to do is to deal with the RRs
we have (if necessary, sweepingly and all at once), and to
prohibit the application of IDNA --or any set of rules more
restrictive than "binary"-- until rules and methods of
interpretation are specified by those new definitions.   They
might well apply IDNA.  I would expect that, at least within
Class=IN, most would.  But let's leave ourselves in a position
to late-bind that decision.

     john