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 22:05 +0000 "Adam M. Costello"
<idn.amc+0@nicemice.net.RemoveThisWord> wrote:

> John C Klensin <klensin@jck.com> wrote:
> 
>> 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.
> 
> Any future spec that defines a new RR type or a new class (or
> any new region) can stipulate that IDNA does not apply there.
> 
> Yes, people are reluctant to make breaks like that, and they
> should be. They should do it only if there is a compelling
> reason.
> 
> If we set the default the other way, so that future RR types
> and classes need to explicitly adopt IDNA, we might encourage
> unnecessary disharmony.

Adam,

I think I've just understood the philosophical difference here.
Assuming I've gotten it right now, I apologize for not
understanding and identifying it sooner.

To me, IDNA is a kludge.   If we were designing the DNS (and
Internet applications) for the first time today, and it was
clear to us that "full internationalization" (whatever that
means) was desirable, IDNA is almost certainly not how we would
do it.  It is a really clever kludge, one that responds well to
the constraints we have because we are not starting fresh, but
it is a kludge.  And making a kludge the default for future
cases is just not a good idea.

Please note that I am not proposing the LDH be the default, or
the unrestricted binary be the default, or that "make up your
own prefix and do strange things to yourself" be the default.  I
am suggesting that we should create a "no default" situation, in
which new RRs (and, more important, new Classes) are required to
specify how the octets in their labels are to be interpreted,
and what syntax restrictions might be applied to them.

With regard to "encourag[ing] unnecessary disharmony", this is
an area where I have a lot of confidence in the IESG --not just
this IESG, but predictions I think can safely be made about
future IESGs.  If someone comes along and says, well, I'm Bob,
and I want to introduce a new coding scheme into the DNS called
IDNB (for "Bob"), he isn't going to survive the laugh test.  I
imagine that "this doesn't require internationalization" or "I
need to invent a new scheme" will get really intense scrutiny,
as they should.  But no sweeping defaults.  Especially no
sweeping defaults that apply not only to future classes but to
existing ones where there has been absolutely no review and
discussion by this WG on whether or not there is an adverse
impact.  That isn't  just incorrect from a design standpoint, it
is procedurally incorrect.

       john