Re: I-D ACTION:draft-ietf-idn-idna-10.txt

--On Wednesday, 03 July, 2002 10:28 +0200 Erik Nordmark
<[email protected]> wrote:

Erik,

Let me try to explain what I think Eric is trying to get at,
since I think we may be suffering from a rather basic
disconnect, not about what should be done, but about how
standards are defined.   I also think a couple of separate
issues are getting intertwined, adding to the confusion.

You wrote...

> When there are additional profiles for domain names, it might 
> makes sense to have a standards track RFC that either updates
> the IDNA RFC to say when the new profile can be used, or
> (depending on how different things would be for the new usage)
> it might make sense to have a standards track RFC which uses
> "newprep" plus punycode. But such a future doesn't mean that
> IDNA can bypass the requirement that nameprep applies today -
> removing that requirement might lead folks to believe they can
> do non-standard prep and still be compliant with IDNA. That
> would lead to non-interoperability as far as I can tell.

First, to repeat something I tried to say some time ago, and
which I think Dave Crocker and Eric have also tried to say,
although from other perspectives and in different language:

	* we have had fairly good success with standards whose
	extensibility model is "for Case X, do Y; any other
	cases are prohibited entirely without standards-track
	action"
	
	* we have had repeated bad experiences when the model is
	"always do Y" on the assumption that we can change that
	into "always do Y unless the following case arises, then
	do Z" with a later document.  Someone always comes along
	and claims it is an incompatible change that will wreck
	his environment, since he assumed that the language
	meant what it said, which is that the method applies to
	all cases, forever.

Please observe that, for Case X, these two definitions are
identical: the requirement is to "do Y", without alternatives,
defaults, options, etc.  In either case, the text has to be
reasonably clear to avoid unintentional "creative"
interpretations (and to make clear that someone who applies such
an interpretation is in the wrong).  But there is no difference
in the requirement that, for whatever names we apply IDNA today
(i.e., "Case X"), nameprep is required.  Properly written, the
question is only about whether we can use a different profile if
and when "Case Y" is adequately defined and justified.

I suggest that this difference in definitional model applies
equally to the "this applies to all RRs in all Classes" language
we discussed a week or so ago as it does to the "profiles with
IDNA" issue that prompted this thread.   The issue is the same,
and my recommendation is that, in both cases, we define the
cases which we require and understand and the actions for them,
that we prohibit any action at all in other cases, and that we
specify the mechanism (e.g., our usual handwaving about
"standards track documents") by which the prohibition may be
relaxed.

>> Is this the intended mechanism for allowing alternative
>> profiles to be encoded in IDNA? I see that section 1.1 says
>> that nameprep is mandatory:
>> 
>>  | IDNA requires that implementations process input strings
>>...
>> Collectively this means that nameprep is still the
>> gatekeeper, and that profiles other than nameprep cannot be
>> encoded with IDNA.

This is the other issue, and it is almost separate.  I think
what Eric is trying to suggest is that IDNA specifies a general
mechanism that could reasonably be used with other stringprep
profiles for other circumstances.  Perhaps he is right --e.g.,
it might be useful for some "directory layer" approaches-- or
perhaps not.  But it is almost certainly useful to avoid having
two nearly-identical documents at early maturity levels on the
standards track: if we discover something wrong, we would have
to make synchronous changes to both.   As a user and
sometime-implementor, I hate such things; as an AD who might end
up having to coordinate the changes, I would assume you might
hate it even more.

I can think of two ways to accomodate Eric's objective.  The
first is to put language into IDNA similar to what I've
suggested above (e.g., "use nameprep for this specific list of
cases, all other cases are prohibited unless this section is
updated by standards-track action").  The required language
might, in practice, be a little convoluted and, if you are
having a problem with the probable convolutions, perhaps the
other alternative would be more attractive (although I think it
involves more work, which I'm reluctant to call for at this
stage).

That other alternative says that we define, by copying most of
idn-idna-11, a new protocol document.  Let's call it ur-IDNA for
the time being, with a title like "A Framework for
Internationalizing Names in Applications".  For this purpose, it
makes no assertions at all about nameprep.  Instead, where
nameprep is invoked today, it would say something like "apply a
stringprep profile as specified by the relevant applicability
document".  And we slice out the DNS-specific text as well:
ur-IDNA becomes simply and purely a model for taking strings in
Unicode form and making them into a canonical ASCII-based
encoding (and vice versa) by applying a specific set of steps.

Then we create a new document, IDNAbis, from what is left over.
IDNAbis defines how to handle DNS hostnames -- labels for a
specific set of RRs in Class=IN.  In principle, it ought to be
pretty short, since its essence should be "execute ur-IDNA,
using the nameprep profile" along with a specification of its
applicability.  It would be somewhat longer and more complicated
than that in practice, since it would need to define FQDN
decomposition rules.  Or, to translate where I think Dan's
suggestions have been heading into this context, it might invoke
a decomposition profile by a separate reference.

Now, while I personally don't think it would be necessary (a
brief flash of optimism), if we were worried about "creativity",
ur-IDNA could contain an explicit statement that the thing is
application-specific and that its use for _anything_ is
prohibited without an application-specific, standards-track,
profile and applicability statement.  That would presumably
avoid any loose ends.

These two (or three) documents would provide a somewhat
different decomposition than the split Dave recommended.
Combining both splitting models, if desired, would presumably
create a lot of documents.  But I wonder whether the right
approach for now would be to slip the prohibition and "standards
track expansion" language into idn-idna-XX, and then sort this
out into a better form when the docs come up for Draft.   If, of
course, IESG decides to advance this work at all.

Is that helpful in at least clarifying the issue?

     john