Proposed Charter for the IDNAbis Working Group

[Vint Cerf]

i am sure you are speaking from experience and no, I haven't had to  
deal with an IETF working group in quite a while.

my sense of the design team after many emails and an all day session  
at the end of January is that it is essentially aligned and now eager  
to have their work more fully reviewed and discussed.  I had thought  
that it would be the responsibility of the chair to detect whether  
the results of this review triggered a re-charter requirement. I  
would expect to discuss any such thing with the ADs and the WG. My  
sense is that such a thing should be contemplated only for really  
significant departures from the basic philosophy that has been  
outlined in the exchanges of the past several weeks on this list.

Without trying to be complete, the rough outline of the difference  
between the 200X and 2003 philosophy as I understand it is  as follows:

1. the protocol specification in the new drafts does not specify  
mapping. if mapping takes place it does so outside of the protocol  
specification. Implicitly the protocol spec says what is acceptable  
input either for registration or for look up (and these are treated  
somewhat differently with look up being a bit more flexible than  
registration).

2. A concerted effort is made to make the specifications agnostic  
with regard to version of Unicode documentation so that properties of  
the characters/symbols are the key to determining their  
appropriateness for use in IDNs. Because this classification does not  
appear always to match precisely what seems to be appropriate for DNS  
use, there is provision for some exceptions but it is intended to try  
to minimize these.

3. An effort has been made to deal further with bi-directional  
scripts and with special symbols such as zero length joiner/non- 
joiners. It appears that the latter may be contextually dependent,  
needed in some languages but not in others that might share  
overlapping use of a script. So there are contextual rules available  
in the specification toolkit for these contingencies

4. Registration time restrictions are contemplated in the IDN200X  
philosophy, perhaps to a greater extent than in IDN2003 (?).  Some of  
these restrictions may be aimed at curtailing ambiguity in domain  
name assignments (e.g. by barring certain subsequent registrations or  
by bundling registrations in the way the CJK community has developed,  
or possibly other tactics). Some of this philosophy is found in the  
first document in the proposed set which tries to set for the  
rationale for the design and underlying philosophy.

I am sure there are better ways to express these things than I have  
achieved and if there are errors they are more likely due to my  
misunderstandings than to a genuine disagreement with the design team.

I am going to try to compose a revised charter incorporating some of  
the suggestions received in the past few days, including some of  
yours, Paul.

I hope we can finalize the charter soon so we can get to the  
substance of discussion about the actual proposed IDN200X specifics.

vint




On Mar 27, 2008, at 2:30 PM, Paul Hoffman 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).
> 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.
>
>> 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.