<div dir="ltr"><div class="gmail_quote">On Mon, Oct 6, 2008 at 11:00 PM, Vint Cerf <span dir="ltr"><<a href="mailto:vint@google.com">vint@google.com</a>></span> wrote:<br><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>DUE DATE: OCTOBER 10, 2008 (ET)</div><div></div></div></blockquote><div><br></div><div>NO </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><br></div><div><br></div><div>COMMENTS:</div></div></blockquote><div><br></div><div>In general, while good progress has been made the documents are nowhere near ready to release, even putting aside the problem with mixtures of normative and informative material in Rationale.</div>
<div><br></div><div>Note: it is unclear to me what the "R.xx" references are. In general, the following points are quite hard to interpret, because it is very unclear what sections of text are being referred to. In many cases, I have no idea what the actual text is, even after spending a good deal of time looking at it, because there are many disconnected sections that it could be referring too.</div>
<div><br></div><div><span class="Apple-style-span" style="font-weight: bold;">For that reason, I suspect that many of the votes (*both* YES and NO) are probably flawed in that it is unclear what people are voting for!</span></div>
<div><br></div><div>But I tried to piece together what the following meant, and give some responses.</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>(4) Textual issues believed settled</div><div><br></div><div>(4.a) The explanation of mappings in Rationale-02 and later is</div><div>satisfactory. (R.24)</div>
</div></blockquote><div><br></div>No. The paragraph "Highly Localized Preprocessing." is dangerous and should be modified drastically. Condition (i) ["(i) only U-labels and A-labels are used in interchange with systems outside the local environment"] is wishful thinking, not borne out by reality; we've seen time and time again that people copy what works in a browser into an href or email.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">And conditions like "Preprocessing MUST NOT map a character that is valid in a label (i.e., one that is PROTOCOL-VALID or permitted in any context) into another character." are insufficient. They permit, for example, uppercase A-ring to be mapped to "aa" on one system and "a" on another.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">Having this section be so weak represents a major interoperability problem.</div><div class="gmail_quote"><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>(4.b) The explanation of the symbol prohibition in Rationale-02</div><div>and later is satisfactory. (R.25)</div></div></blockquote><div><br></div><div>No. The explanation is specious, and should be removed.</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>(4.c) The explanation of requirements on registries, the role</div>
<div>of registration policy, and their scope in Rationale-02 and</div><div>Protocol-05 is satisfactory (R.9, R.27, P.6).</div></div></blockquote><div><br></div><div>No. The requirements should be in one place </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>(4.d) The description of the Bidi changes between IDNA2003 and</div><div>IDNA2008 in Rationale-02 is satisfactory. (R.15)</div></div></blockquote><div><br>
</div><div>Yes</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>(4.e) The description of detecting domain names in text and how</div>
<div>it interacts with the idea of alternate label separator</div><div>("dotoid") characters is adequate in Rationale-02 (R.23)</div></div></blockquote><div><br></div><div>No. Example: the following is still incorrect. Take the code or regular expression used to find domain names, and change [.] to include the other alternatives. Not rocket science.</div>
<div><br></div>"When using Unicode, this gets even more difficult if treatment<br>of certain special characters (like the dot that separates labels in<br>a domain name) depends on context (e.g., prior knowledge of whether<br>
the string represents a domain name or not). That knowledge is not<br>available if the primary heuristic for identifying the presence of<br>domain names in strings depends on the presence of dots separating <br>groups of characters with no intervening spaces."</div>
<div class="gmail_quote"><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>(4.f) The description of the implications of mapping changes</div>
<div>between IDNA2003 and IDNA2008 is satisfactory in Rationale-02</div><div>(R.28)</div><div><br></div><div>(4.g) The discussion of user agent security issues should be</div><div>retained in Section 6.3 of Rationale. (R.6, R.19)</div>
</div></blockquote><div><br></div><div>No. There should be one unified section with security issues. </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>(4.h) The description of why we are using Unicode is</div><div>satisfactory in Rationale-02. (R.13)</div></div></blockquote><div><br></div><div>Don't know where this is.</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>(4.i) With the new note warning that, while the lookup and</div>
<div>registration steps in Protocol are similar, they are not</div><div>identical, the structure of the description of those steps is</div><div>satisfactory. (P.10, P.15)</div></div></blockquote><div><br></div><div>No. The text should state precisely what the differences are.</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><br></div><div>(4.j) The text about A-label dislay that now appears in Rationale-02</div>
<div>is satisfactory. (R.20)</div></div></blockquote><div><br></div><div>No. It discourages input of A-Labels and display of A-Labels, without mentioning the widespread use of A-label display to indicate suspicious sites. While I agree that there are better mechanisms, this is a place that requires discussion, not ignoring the practice.</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><br></div><div>(5) IANA Considerations and table changes.</div>
<div><br></div><div>(5.a) The IANA considerations section setting up the Contextual</div><div>Rule registry (in Tables, taken from Protocol at -03) is</div><div>satisfactory. (R.8)</div></div></blockquote><div><br></div>
<div>Very unclear. The contextual rules were supposed to be moved to tables, but aren't there yet. The various sections on IANA considerations just bounce around between one another now</div><div><br></div><div><a href="http://tools.ietf.org/html/draft-ietf-idnabis-tables-02#section-5">http://tools.ietf.org/html/draft-ietf-idnabis-tables-02#section-5</a></div>
<div><a href="http://tools.ietf.org/html/draft-ietf-idnabis-rationale-03#section-13">http://tools.ietf.org/html/draft-ietf-idnabis-rationale-03#section-13</a><br></div><div><a href="http://tools.ietf.org/html/draft-ietf-idnabis-protocol-05#section-8">http://tools.ietf.org/html/draft-ietf-idnabis-protocol-05#section-8</a><br>
</div><div><br></div><div>There is completely insufficient information as to what the considerations are, and precisely the process that IANA is to use to manage any changes, and exactly what the formats are.</div><div><br>
</div><br><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>(5.b) We are agreed that changes to the table-defining rules,</div>
<div>and especially to lists of contextual rules and exception</div><div>characters, require IETF consensus and publication of a new</div><div>RFC. (R.12)</div></div></blockquote><div><br></div><div>Yes. However, statements like "Characters that are placed in the "PROTOCOL-VALID" category are never removed from it unless the code points themselves are removed from Unicode" are completely specious, and need to be removed or changed to add "unless this document is obsoleted". IETF can at any time change the rules; <span class="Apple-style-span" style="font-style: italic;">after all, we are doing that with this very document, removing thousands of characters from being valid in IDNs.</span></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>(5.c) The IANA registry for contextual rules should be</div>
<div>maintained with a "last updated" date. (P.16)</div></div></blockquote><div><br></div><div>Another case where I can't find the text. The reference doesn't give a document and "last updated" is not found in either protocol or rationale.</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>(5.d) The contextual rules themselves should be specified and</div>
<div>maintained as procedural steps, as discussed in Dublin. (P.2,</div><div>P.3)</div></div></blockquote><div><br></div><div>Yes</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><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>