<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 style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;min-height:14px">
<span class="Apple-style-span" style="font-family: Helvetica; font-size: 12px; ">Place your reply here:</span></div></div></blockquote><div><br></div><div>NO, they open up a significant security and interoperability hole.</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 style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;min-height:14px">
<span class="Apple-style-span" style="font-family: Helvetica; font-size: 12px; "></span><br></div><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;min-height:14px"><br></div><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px">
<font face="Helvetica" size="3" style="font:12.0px Helvetica">COMMENTS:</font></div></div></blockquote><div><br></div><div>1. Section 4.2 of Protocol could be interpreted as only requiring Unicode Strings to be in NFC *if* they resulted from conversion from a legacy character encoding, rather than requiring it also of Unicode strings that did not result from such an encoding. The text needs to be fixed so that it is very clear that the NFC requirement is also true of strings that did not require conversion, as is the intent. I don't think this part is controversial -- it just makes it clearer and more consistent with 5.5.</div>
<div><br></div><div>2. In terms of validation (the subject of this tranche), the second paragraph of 4.2 and the section 5.3 open up an unpleasant interoperability and security hole, since it places no limits on the mappings that can be applied to forbidden characters.</div>
<div><br></div><div>Take the following 3 strings:</div><div><ol><li><a href="HTTP://SCHAFFER.DE">HTTP://SCHAFFER.DE</a><br></li><li><a href="HTTP://xn--schffer-7wa.DE">HTTP://SCHÄFFER.DE</a><br></li><li><a href="HTTP://xn--schffer-oxa.DE">HTTP://SCHÆFFER.DE</a></li>
</ol><div>This section allows any implementation to map *any* of these to *any* of the following:</div><div><ol><li><a href="http://schaeffer.de">http://schaeffer.de</a><br></li><li><a href="http://xn--schffer-7wa.de">http://schäffer.de</a><br>
</li><li><a href="http://schaffer.de">http://schaffer.de</a><br></li></ol></div><div>That is, one implementation could map #2 to #3, while another implementation could map #2 to #1. Or, for that matter, many other variants. It allows Y<span class="Apple-style-span" style="font-family: -webkit-sans-serif; font-weight: bold; line-height: 19px; "><span class="Apple-style-span" style="font-family: arial; font-weight: normal; line-height: normal; ">ENİ<a href="http://KAPI.TR">KAPI.TR</a> to be mapped to any of yenikap<a href="http://xn--cfa.tr">ı.tr</a>, yenı<a href="http://kapi.tr">kapi.tr</a>, or other dotted vs dotless i variants. As a matter of fact, a conformant implementation could m<span class="Apple-style-span" style="border-collapse: collapse; font-family: -webkit-sans-serif; font-size: 11px; line-height: 17px; "><span class="Apple-style-span" style="border-collapse: separate; font-family: arial; font-size: 13px; line-height: normal; ">ap <a href="http://xn--h1acbxfam.RU">РУССКИЙ.RU</a> to <a href="http://sarapalin.ru">sarapalin.ru</a>, since no limits are placed on the kinds of mappings that can be done.</span></span></span></span></div>
</div><div><br></div><div>This was also brought up before.</div><div><br></div><div>Mark</div></div></div>