That works for me. Item (iii) needs fleshing out a bit.<br><br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;(iii) A change to the basic approach taken in the design<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;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 &lt;<a href="mailto:klensin@jck.com">klensin@jck.com</a>&gt; 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>
&quot;things the WG cannot discuss or document without rechartering&quot;<br>
and &quot;things the WG can&#39;t agree to do without rechartering and<br>
getting more general IETF approval in the process&quot;. &nbsp; At least I<br>
have. &nbsp;In particular, I think the discussion about why we don&#39;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>
&quot;Rationale&quot; if we don&#39;t change structure). &nbsp;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&#39;s be explicit about<br>
this. &nbsp;Rather than scattering language and restrictions<br>
throughout the charter, let&#39;s make an explicit subsection that<br>
says something like<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp;The WG will stop, close, and recommend that a new<br>
 &nbsp; &nbsp; &nbsp; &nbsp;charter be generated if it concludes that any of the<br>
 &nbsp; &nbsp; &nbsp; &nbsp;following are necessary to meet its goals:<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;(i) A change to the &quot;punycode&quot; algorithm or the ACE<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;approach to encoding names in the DNS<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;(ii) A change to the ACE prefix from &quot;xn--&quot;<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;(iii) A change to the basic approach taken in the design<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;team documents.<br>
<br>
I think that is the entire list, but, if others have other<br>
items, let&#39;s get them on the list.<br>
<br>
(2) We will work together to improve the description of the<br>
prefix change issue in &quot;Rationale&quot;. &nbsp;I&#39;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. &nbsp; That material can go into Rationale<br>
or, if the WG prefers, we can pull it out into another (fifth?)<br>
document. &nbsp; I don&#39;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) &nbsp;While I don&#39;t see the &quot;alternatives&quot; 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. &nbsp; 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>
 &nbsp; &nbsp;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