RE: [idn] Document Status?

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

--On Wednesday, 11 September, 2002 10:31 +0200 Erik Nordmark
<Erik.Nordmark@sun.com> wrote:

> 
>> IMO, if this is the intention, then the document needs to be
>> made crystal clear -- this is a really bad area in which to
>> say something circumspect that people can interpret as they
>> will. And, in particular, it needs to be clear that:
>> 
>> (i) No one can expect a client-side error message on the basis
>> of any of these excluded characters, labels, or sequences.
>>...
> 
> John,
> 
> Do you have a feel for how lengthy text is needed? I'd like to
> find the actual text that can be put in the document to make
> this more clear.
> 
> For instance, would it be sufficient to add after 
>      This document does not attempt to define an
> "internationalized host      name".  It is expected that some
> name-handling bodies, such as large      zone administrators
> and groups of affiliated zone administrators,      will want
> to limit the characters allowed in IDNs further than      what
> is specified in this document, such as to prohibit additional
>      characters that they feel are unneeded or harmful in
> registered      domain names.
> this text:
>      Such prohbitations are outside of the scope of the IDNA
> (and DNS) protocol 
>      specifications. They can only be applied at domain name
> registration time. 
>      In particular, they MUST NOT have any impact on the
> behavior of the      on-the-wire protocol.

I think that would just about do it, modulo an issue about "on
the wire" (see below).  At worst, it would make things clear
enough that the text could be fine-tuned in the next cycle if
that proved necessary.

It could probably even be clarified and streamlined further,
e.g., after "does not attempt to define an 'internationalized
host name'"

	Just as has been the case with LDH names, some zone
	administrators may impose restrictions, beyond those
	imposed by the protocol, on the characters or strings
	that may be registered as labels in their zones.  Such
	restrictions do not impact the protocols themselves; a
	query for a name that does not exist will yield the same
	response regardless of the reason why it is not in the
	relevant zone.   Restrictions imposed on a per-zone
	basis MUST NOT have any impact on the behavior of the
	on-the-wire protocol, and MUST NOT assume that clients
	issuing queries or interpreting responses will have any
	knowledge of zone-specific restrictions or conventions.
	
That avoids opening up problems that we should not care about --
definitions of "name-handling bodies", relationships among zone
admins, reasons why someone might want to impose naming
restrictions -- and even avoids binding this issue to the "host
name"/ "domain name" mess.  It points out that these sorts of
restrictions are nothing new, which I think is helpful. It also
nails down the one piece of the issue that your text might be
construed as not covering: ultimately, nameprep, etc., aren't
on-the-wire protocols, but rather specifications about what
clients are supposed to do.  And that makes it important, I
think, to clearly prohibit anything resembling "clients are
expected to know that, in looking up names in _my_ domain, they
are to do the following variant steps".

   john