> 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
