<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div>Place your reply here: [YES or NO]</div>
</div></blockquote><div><br></div><div>NO</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div></div><div><br></div>
<div>COMMENTS:</div></div></blockquote><div><br></div><div>The note below says that "the" alternative is to move the normative material out of Rationale into a second document". But look closely at the statement:</div>
<div><br></div></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;">"...even if this lengthens the WG's target dates for an unknown period of time. Note that there may be controversy about what material is normative and what is not; that is a separate consensus issue and may also take an unknown period of time to resolve ..."<br>
</blockquote><div class="gmail_quote"><div><br></div><div>These are *precisely* the reasons why this measure should fail. If there is controversy in *this* group about what is normative or not, it means that the document as a whole is badly written, and will be impossible for ordinary readers to understand what is normative or not. Moreover, the "even if this lengthens the target dates" is a misleading. I believe it will take much longer to iron out the many problems in Rationale if it has normative content than if it is purely informative -- in the latter case, the problems in the text are not as important.</div>
<div><br></div><div>If we were really concerned with (a) the timing, and (b) having a rigorous document, the better alternative would be to move the normative definitions into Protocol (or a separate document), and then put Rationale on its own track, not tied to the release schedule of the other parts.</div>
<div><br></div><div>Mark</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div></div><div><br></div><div><br></div>
<div>Procedure:</div><div><br></div><div><br></div><div>There are several decisions that the working group will need to make to confirm consensus. I will send a series of proposals over the next two weeks requesting YES or NO positions on each within a 4 day window. If NO is the response, a reason for that position needs to be stated. If there is a clear consensus based on responses or in the absence ofa consensus against each proposal, it will be assumed that the proposal is acceptable to the Working Group.</div>
<div><br></div><div><br></div><div>Parenthesized symbols (e.g., "(R.1)") after the items are references to the issues lists where additional explanations can be found, as sent by John Klensin as body parts "idnabis-protocol-issues-rev3" and "idnabis-rationale-issues-03" on a message titled 'Issues lists and the "preprocessing" topic' to the working group on 18 August (<a href="http://www.alvestrand.no/pipermail/idna-update/2008-August/002537.html" target="_blank">http://www.alvestrand.no/pipermail/idna-update/2008-August/002537.html</a>)</div>
<div><br></div><div>This group needs to get its documents out; it is behind its original schedule. It should be noted that the IDN ccTLD and gTLD selection initiatives at ICANN have already begun so that delay may weaken the IETF's ability to assist in a rational deployment of IDNA.</div>
<div><br></div><div><br></div><div>(1) Document organization </div><div><br></div><div><br></div><div>(1.a) The Rationale document should be retained to support implementors whose work requires that they understand the reasoning behind certain design choices. The philosophy of IDNA2008 relies strongly on the ability of registries (especially those of top-level domains) to properly constrain the choice of labels even if they are composed of characters that are protocol valid. (R.1)</div>
<div><br></div><div>(1.b) While there has been debate about whether or not the content of the Rationale document should contain normative material, it seems expedient to agree on the content of Rationale for Proposed Standard without attempting to separate it into multiple parts. Therefore, it appears that the WG consensus is that: The normative material (definitions) should be retained in Rationale.</div>
<div><br></div><div>A YES means you concur with the consensus statements above.</div><div><br></div><div>The alternative is:</div><div><br></div><div>- The normative material should be removed from Rationale and extracted to a separate document (for example Terms and Concepts) even if this lengthens the WG's target dates for an unknown period of time. Note that there may be controversy about what material is normative and what is not; that is a separate consensus issue and may also take an unknown period of time to resolve (R.2)</div>
<div><br></div><br><div> <span style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div>
<div>NOTE NEW BUSINESS ADDRESS AND PHONE</div><div>Vint Cerf</div><div>Google</div><div>1818 Library Street, Suite 400</div><div>Reston, VA 20190</div><div>202-370-5637</div><div><a href="mailto:vint@google.com" target="_blank">vint@google.com</a></div>
<div><br></div></div></span><br></span><br></span></span></span> </div><br></div><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>
<br></blockquote></div><br></div>