Proposed Charter for the IDNAbis Working Group

[John C Klensin]

--On Thursday, 27 March, 2008 11:30 -0700 Paul Hoffman
<phoffman at imc.org> wrote:

> At 1:53 PM -0400 3/27/08, Vint Cerf wrote:
>> it seems to me that what is more important than whether there
>> are  disagreements among the design team is what the
>> specifications they  have produced actually say.
> 
> If the disagreements among the design team are not important,
> than the following part of the proposed charter (when a
> re-charter would be needed) does not make sense:
>     (iii) A change to the basic approach taken in the design
>     team documents (Namely: a protocol that is independent of
> Unicode
>     versions, that removes any character mapping in the
>     protocol, and that has improvements to the bidi algorithm).

Paul, keeping in mind that the parenthetical note is, if I
recall, your text...   What that text talks about is "basic
approach".  I believe that the design team is in complete
agreement about the basic approach.  If we weren't, we probably
would have killed each other long ago -- as you presumably know,
there is no one on the design team with a reputation for being
afraid to speak up.   I believe (again, I haven't gone out and
polled people) that the design team is in complete agreement in
the result being "a protocol that is independent of Unicode
versions, that removes any character mapping in the protocol,
and that has improvements to the bidi algorithm".   What we seem
to be discussing is whether display functions or cross-label
requirements are essential to having "improvements to the bidi
algorithm".   I believe that no member of the design team would
claim that they are essential; any disagreement are about
tradeoffs and methods.

There are many other things like this.  For example, there is
agreement about something that did not make it into the list
above -- that there are at least some scripts for which it is
necessary to support joiners and that doing so safely requires
verification of the context of use for whatever joiners are
permitted.  Those elements are part of the "basic approach".
Whether ZWJ and/or ZWNJ are a requirement for Arabic script and
in what contexts is a detail that the WG can sensibly address
(and on which I hope we will have more input from meetings being
held within the next week): the answer to that question doesn't
affect the basic approach.  And I think that would be a matter
of common sense, not charter details.

> Assume that the WG says "let's change this part of the
> original documents". One team member says "that's a change to
> the basic approach; recharter" and a different team member
> says "that's not a basic change; continue". This section of
> the charter falls over.
 
> Either there is agreement among the design team about
> everything that is "the basic approach", or the above
> paragraph is a recipe for procedural morass.

I believe that there is such agreement.  I don't believe that I,
or anyone else involved in the design, has ever said otherwise.
I believe that you are trying, intentionally or not, to bind a
series of details to the basic approach.   They aren't, whether
the detail is the reach of the bidi algorithm, the context for
ZWJ, or whether or not Eszett is mapped to another character,
disallowed, or treated as Protocol-Valid.  Those are all details.


>> The basic action in the WG at the outset is to obtain broader
>> review  of the text of these documents to determine whether
>> it is agreed  that these specifications represent an
>> improvement in framework and  formulation for IDNs than the
>> earlier effort. what I would have  thought is of more
>> interest is the text of the documents and less  the text of
>> the now much-massaged charter?
 
> It sounds like you haven't been active in many IETF WGs for
> the past few years. The IESG, and many process wonks, consider
> the charter to be worthy of spending huge amounts of time
> agonizing over. Having a charter that has a "recharter if"
> clause that is fragile is a good way to delay finishing the
> work we want to do.

I don't think there is anything fragile about that statement as
written.  It is consistent with the "basic approach" and there
is nothing about the handling of individual characters, or about
whether we look across labels or not, in it.

You know as well as I do that the question of how much time to
spend on the finely-tuned text of charters remains highly
controversial within the IETF and that spending "huge amounts of
time" on these things is often cited as a reason why the IETF
can't get anything done efficiently these days.   I even believe
that there is some consensus that, beyond a certain point,
fine-tuning a charter can become, whether intentionally or not,
a denial of service attack on actually getting work done.  I,
probably obviously, believe that we are close to that point if
not already past it.  The observation that I've spent most of my
time since coming online today trying to respond to charter
issues, which I think is the first priority until the charter is
resolved, rather than reading and responding to the thread about
the protocol document, reinforces that view for me.  Your
opinion, obviously differs and that is well within your rights.
But please don't try to suggest that endless tinkering with
charter text has somehow become a general IETF requirement.

     john