RE: [idn] Document Status?

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

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

> 
>> I think that would just about do it, modulo an issue about "on
>> the wire" (see below).  
> 
> Yes, I wasn't very comfortable with using that term in my text.
> 
>> At worst, it would make things clear
>> enough that the text could be fine-tuned in the next cycle if
>> that proved necessary.
> 
> For "next cycle" = "when documents move to draft standard" I
> assume?

Or, if you publish this as Experimental, when they move to
Proposed :-)

>> 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.
> 
> Looks good to me.

Erik, as a meta-comment, the problem here, and the "what can be
displayed" one, are, I fear, symptomatic.  While there are some
other specific issues, the documents are just not very well
written _as a standard_.   In areas where we produce a document
for which there are no active competing ideas and
implementations, and in which there is clear consensus, we can
get away with such things, relying on good faith and the
robustness principle to pull us through.  

But, in the IDN area, we know that there are already operators
out there, selling names or tools that are not compatible with
one or more details of IDNA.  It is nearly certain that some of
them will try to claim conformance and argue that anyone who
doesn't interwork with them is non-conforming.  And some will do
almost certainly do that even if what they are doing requires
special DNS clients or servers, DNS middleboxes rewriting
queries, zone-dependent name interpretation rules, etc.   We can
(and should) head off a lot of problems by being very clear
about what problem is being solved, very clear about what we are
promising, and very clear about what behavior conforms and what
behavior doesn't.   The current document set doesn't do any of
those three as well as the situation appears to require.

regards,
    john