Re: [idn] Re: idn-uri document

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

--On Thursday, 31 October, 2002 23:40 +0100 Erik Nordmark
<Erik.Nordmark@sun.com> wrote:

>> If IDNA says that their preparation of ascii-only labels is
>> the identity operation, then we recommend that you apply that
>> (i.e. do nothing), and not something else. If you see a way
>> to make this clearer, please tell me.
> 
> It is the identity operation for ASCII-only labels (plus some
> checks that will reject certain labels).
> 
> If you want to do that part, but not apply the Punycode step
> then I think you need to explicitly state that one should
> apply ToASCII without the punycode step (and other steps that
> don't make sense if there are any).

Erik,

I tried to raise this argument in some of my remarks about IDNA,
but, as with many other things, it was apparently ignored by the
IESG.  Let me repeat it, in a different way, in this context.
One of the things that many of us feel is key to the success of
the Internet protocol suite is a minimum of profiling and
options for variations within a protocol.  That is obviously a
principle, not a hard rule: the stringprep-nameprep separation
arose as the better choice relative to having different
protocols make up their own mapping variations.  But, even in
that case, we haven't permitted profile variations _within_
IDNA: a user, site, or registry cannot select a different
stringprep profile, and that is a Good, probably necessary,
thing.  

But much the same argument applies to the type of use Martin
contemplates.   IDNA, as written, is _one_ protocol.  It is not
a toolkit for building other protocols, nor is it a a set of
profiles that other protocols can adopt.  Those two may be much
the same thing in practice.  As soon as we say "you should use
that operation from IDNA, but without some particular step" we
head down a slippery slope.  That is especially true because
IDNA contains (or appears to contain) a good deal of normative
text outside the particular of, e.g., ToASCII.  It is not clear
whether "...explicitly state that one should apply ToASCII
without the punycode step (and other steps..." includes some,
all, or none of those textual specifications.  And, whatever
choice is made, "do just what is done over there, except..." is
a poor way to do protocol specification and introduces some of
the worst properties of profiling without any of the benefits of
being explicit about what can, and cannot, be profiled.

      john