RE: [idn] Document Status?

[Erik Nordmark <Erik.Nordmark@Sun.COM>]

> 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.  

I agree that the document could have been written differently.
But in my reading of the document(s) look clear enough to be implementable
from the specification. If there are specific points that are unclear
I don't have a problem with us collectively looking at text modifications
that try to clarify the document.
But I don't the benefits of a new document written in a different style
outweigh the delay.
Instead I think (except for specific clarifications) that the current
documents are good enough for proposed standard status and that
having them be implemented, as well as having folks work on applying IDNs
to application protocols in other WGs - such as URIs and email addresses, 
will give us feedback to produce a clearer draft standard down the road. 
A rewrite of the document would probably delay that part of the work
of internationalizing the IETF protocols.

> 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.

I think the documents must be clear enough so that they can be implemented
from the specification by an implementor who is trying to conform to
the specification and interoperate.
But for those that are more or less intentionally trying to misinterpret
the specification for their own purposes I fear that it will always be
possible for them to claim conformance and there is little the IETF as a 
standards producing organization can do; the IETF does not run a 
conformance testing and branding mechanism that prevents implementors 
from intentionally claiming conformance when they in fact do not conform.

So to the extent the point is to get an implementor to understand how IDNA
works I agree that the documents need to be clear.
But I don't think we can and should try to make the documents read like
protocol legal documents by trying to e.g. minimize the number of
intentional creative misinterpretations that can be made.
If it turns out that there are common intentional creative misinterpretations
it might make sense to have a separate document in the RFC series
documenting such bad ideas and why they are bad.

  Erik