<div>
<p><font size="2">Latest feedback.</font></p>
<p><font size="2"><br></font>
</p>
<p><font size="2">Many notable improvements in the docs. I haven't checked them
completely against my list, but in general, very nice work. Some
remaining issues.<br></font>
</p>
<p><font size="2"><br></font></p><p><font size="2">Defs.</font></p><pre class="newpage"><font size="2">====<br> To help prevent confusion between characters that are visually<br> similar, it is suggested that implementations provide visual<br>
indications where a domain name contains multiple scripts (or what<br> are considered multiple scripts in a local environment in which some<br> mixed-script use is normal). <br><br></font></pre><p><font size="2">The
scripts are still recognized as separate scripts, so the parenthesized
clause doesn't make apply. It should instead be something that makes it
very clear what the issue is, and provides an example. Suggested:</font></p><p><font size="2"><br></font></p><p><font size="2">"...
where a domain name contains multiple scripts with characters that are
visually confusable, such as an omicron in Greek mixed in with Latin
text."</font></p>
<p><font size="2"><br></font>
</p>
<p><font size="2"><br>
> allowing UNASSIGNED in lookup is <i>"(something that is now recognized as a considerable source of risk)"</i>. (Defs)</font></p>
<p><font size="2"><br></font>
</p>
<p><font size="2">This needs some justification, at least in Rationale if not here. What is a scenario that illustrates that it is a risk? <br></font>
</p>
<ol><li><font size="2">If a lookup is against a registry is conformant to IDNA2008, it is no risk at all: the UNASSIGNED character will be valid or invalid according to the registry's version of Unicode.</font></li><li>
<font size="2">If the registry is not conformant, then we already permit lookup
to proceed without full validation of U-Labels or any validation of
A-Labels. So allowing lookup of UNASSIGNED is the least of our
problems!!<br></font>
</li></ol>
<p><font size="2"><br></font></p><font size="2"><br>====<br></font><pre class="newpage"><font size="2"> subject to the constraints about permitted characters that are<br> specified in the Protocol and Tables documents as well as the<br>
symmetry constraint described.<br><br></font></pre><font size="2">Need
to specify the section in Protocol that specifies U-Label. There are
many constraints in those documents; you need to point to the place
that sums up what makes a U-Label. (For example, satisfying just the
lookup constaints does not a U-Label make.)<br><br>... the symmetry constraint described
[add "below"].<br><br>====<br>Rationale<br><br></font><pre class="newpage"><font size="2"> some because they are<br> actively dangerous in URI, IRI, or similar contexts and others<br> because there is no evidence that they are important enough to<br>
=><br> some because they are<br> visually confusable in URI, IRI, or similar contexts and others<br> because there is no evidence that they are important enough to<br></font></pre>
<p><font size="2">[*dangerous* is too vague. If the issue is visually confusable, say so. If it is some other problem, say what that is.]</font></p>
</div>
<pre class="newpage"><font size="2">====<br></font></pre><font size="2">
>"characters are permanently excluded".
</font><ol><ol><li><font size="2">
As per John Klensin: <i>"People
have complained about statements that appear to predict what the IETF
will do in the future or to commit it to future actions and those
statements have been removed or corrected as they have been identified."</i></font></li></ol></ol>
<font size="2"><br>
So this needs to at least be qualified to say that the *intent* is for them to be permanently excluded.<br><br></font>
<p><font size="2">====</font></p>
<p><font size="2"><br></font></p>
<p><font size="2">Security Considerations (Defs/BIDI) still needs to:<br></font></p>
<p><font size="2"><br></font></p>
<ol><li><font size="2">
document how the compatibility problems between 2003 and 2008 can cause security problems (See <a href="http://docs.google.com/Doc?id=dfqr8rd5_361dwv9cff8" id="k80l" title="http://docs.google.com/Doc?id=dfqr8rd5_361dwv9cff8">http://docs.google.com/Doc?id=dfqr8rd5_361dwv9cff8</a>
). Some of this is in Rationale, but needs to be added or referenced,
while other parts are missing. I can supply some suggested text if
desired.<br></font>
</li><li><font size="2">
document the security issues that can arise in BIDI where Label
Uniqueness and Character Grouping are not maintained. (These goals
cannot be guaranteed because of intra-label issues and variance among
bidi implementations). </font></li></ol>
<font size="2"><br><br><br clear="all">Mark<br></font>