idnabis WG documents

[John C Klensin]

Paul,

Our interpretations of many of the things that have been said 
and happened differ.   In particular, as has happened in the 
past, when I say things like "[many] people believe", you think 
I'm hearing only myself; when you say "many people are wary", I 
wonder if voices close to your position sound louder or more 
numerous.    Let me express my perspective on some of the points 
you raise; the WG will clearly need to sort these issues out. 
And, again, I'm not attached to either specific presentation 
style, presence or absence of explanations, or how documents are 
organized and structured.


--On Friday, April 18, 2008 2:18 PM -0700 Paul Hoffman 
<phoffman at imc.org> wrote:

> At 7:07 PM -0400 4/17/08, John C Klensin wrote:
>> Paul, I clearly don't have any problems with the WG deciding
>> on document structure.
>
> That's good to hear. One thing that came out of the
> discussions in Philadelphia is that many people are wary of
> the current "issues" document. I am probably the most vocal
> about that, of course, but I heard from multiple people that
> they don't like a document with a such a negative tone about
> IDNA2003.

Again, no attachment to the "negative tone".  Either the tone 
can be changed or materials dropped, depending on what the WG 
wants.  Note, however, that some of what I assume you believe to 
be negative tone was an attempt to make the case that changes 
were needed forcefully enough that people would be inclined to 
actually make them.  We have already gotten signals from some 
quarters (especially registries) that indicate that they are 
happy with IDNA2003, don't need the new scripts, and have no 
intention of converting unless they are forced into it by market 
pressure.

> Separately, one of the lessons we learned with IDNA2003 is
> that the more "helpful" text you put in the protocol document,
> the more likely it is that implementers will get it wrong. The
> rationale and "issues" sections of the design team documents
> may have been helpful in getting us to where we are today, but
> have no value to an implementer who needs to know exactly what
> their implementation needs to do.

We agree about that implementer, especially if one also assumes 
good faith.  It hasn't come up much around the IETF, but I am, 
for example, a long-time opponent of tutorial descriptions of 
standards that people can confuse with the standards themselves. 
However, especially because of the client-side aspects and 
extensive social and political debates that surround IDNs 
(including an assortment of vendors who continue to offer 
deliberately incompatible solutions), there are audiences other 
than the implementer.  They may not --typically do not-- have 
sufficient expertise to fully understand a "just do this and it 
will be right" set of instructions but need to understand, 
conceptually, what is going on.  That difference in audiences 
gives us a messy tradeoff.  On the one hand, you suggest that 
additional ancillary text confuses implementers and leads to 
errors of implementation.  On the other, I suggest that not 
having that text leads to shortcuts elsewhere in the process, to 
people deciding that some steps can simply be left out, to 
others deciding that some other approach is good enough and 
compatible enough and has some advantages for their favorite 
script, and so on.

I think we are probably both right.  If we are, the question 
becomes how to best organize the material to meet this wide 
range of needs and I'm completely open to suggestions on that 
subject.

     john