That works for me. Item (iii) needs fleshing out a bit.<br><br>
(iii) A change to the basic approach taken in the design<br>
team documents.<br><br>It is clear when a change would violate (i) or (ii) would be, but not clear what kind of change would violate (iii).<br><br>Mark<br><br><div class="gmail_quote">On Tue, Mar 25, 2008 at 5:18 PM, John C Klensin <<a href="mailto:klensin@jck.com">klensin@jck.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi.<br>
<br>
In the hope of moving forward --i.e., of bringing the charter<br>
discussion to a conclusion and getting on to the actual work, a<br>
few comments and then what I hope will be a generally-acceptable<br>
proposal.<br>
<br>
I think we have gotten confused about the difference between<br>
"things the WG cannot discuss or document without rechartering"<br>
and "things the WG can't agree to do without rechartering and<br>
getting more general IETF approval in the process". At least I<br>
have. In particular, I think the discussion about why we don't<br>
want to change prefixes, what the consequences of such changes<br>
might be, and what incompatibilities we are willing to introduce<br>
and live with without making such a change is important and<br>
should be captured in one of the documents (presumably<br>
"Rationale" if we don't change structure). I think that should<br>
be done both for the information of people making the transition<br>
and to reduce the odds of some future discussion having to<br>
repeat this discussion.<br>
<br>
At the same time, it seems clear that the WG should not be<br>
making prefix changes without a much broader review, going in,<br>
of the implications of doing that.<br>
<br>
Suggestions:<br>
<br>
(1) As far as the charter is concerned, let's be explicit about<br>
this. Rather than scattering language and restrictions<br>
throughout the charter, let's make an explicit subsection that<br>
says something like<br>
<br>
The WG will stop, close, and recommend that a new<br>
charter be generated if it concludes that any of the<br>
following are necessary to meet its goals:<br>
<br>
(i) A change to the "punycode" algorithm or the ACE<br>
approach to encoding names in the DNS<br>
<br>
(ii) A change to the ACE prefix from "xn--"<br>
<br>
(iii) A change to the basic approach taken in the design<br>
team documents.<br>
<br>
I think that is the entire list, but, if others have other<br>
items, let's get them on the list.<br>
<br>
(2) We will work together to improve the description of the<br>
prefix change issue in "Rationale". I've now got a few ideas<br>
about how to improve that text, but will need more input on this.<br>
<br>
(3) I will work with Simon and others who are interested to be<br>
sure that every incompatible change is discussed carefully and<br>
that the discussion includes at least some recommendations as to<br>
what to do about each one. That material can go into Rationale<br>
or, if the WG prefers, we can pull it out into another (fifth?)<br>
document. I don't think we need to decide on that before<br>
chartering, but the charter text should probably indicate that<br>
we will be explicit about any incompatible changes.<br>
<br>
(4) While I don't see the "alternatives" draft as a WG project,<br>
I will try to work with Shawn and anyone else who is interested<br>
to be sure that document contains a good description of the pros<br>
and cons of just putting UTF-8 into the DNS rather than using an<br>
ACE-style encoding. Again, that is not a discussion we should<br>
need to have anew each time people start thinking about IDNs.<br>
<br>
Does that work for people?<br>
<br>
john<br>
<br>
_______________________________________________<br>
Idna-update mailing list<br>
<a href="mailto:Idna-update@alvestrand.no">Idna-update@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/idna-update" target="_blank">http://www.alvestrand.no/mailman/listinfo/idna-update</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Mark