<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><font class="Apple-style-span" face="'times new roman', serif"><br></font>
However, I don't understand your argument about comparisons.<br>
You need to compare and need to compare frequently.  Both NFD<br>
and NDC are canonical forms.  Comparing a pair of NFC-strings is<br>
no more expensive or complex than comparing a pair of<br>
NFD-strings (actually, because of the length issue, the NFC<br>
comparisons might be a tad cheaper, but the difference is<br>
presumably similar). </blockquote><div><br></div><div>That is correct. The only difference would be taking externally supplied strings and either testing them for being in a particular normalization form, or converting them into a particular normalization form.</div>
<div><br></div><div>In general, I agree that NFC is a better format in terms of compatibility.</div><div><br></div><div>NFD is a better internal format for some forms of processing, because it has a smaller data-table footprint for the implementation, and is a bit faster. Here is a simple example for an ASCII string (on my laptop, in Java, so caveats apply). Where you are converting an NFD string to NFC, or vice versa, then the times for that conversion go up.</div>
<div><br></div><div><meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta http-equiv="Content-Style-Type" content="text/css">
<title></title>
<meta name="Generator" content="Cocoa HTML Writer">
<meta name="CocoaVersion" content="1038.32">
<style type="text/css">
p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Monaco}
span.Apple-tab-span {white-space:pre}
</style>


<p class="p1"><span class="Apple-tab-span">     </span>isNFC:<span class="Apple-tab-span">        </span>50ns</p>
<p class="p1"><span class="Apple-tab-span">     </span>toNFC:<span class="Apple-tab-span">        </span>84ns</p>
<p class="p1"><span class="Apple-tab-span">     </span>isNFD:<span class="Apple-tab-span">        </span>21ns<span class="Apple-tab-span">  </span>(-57.8%)</p>
<p class="p1"><span class="Apple-tab-span">     </span>toNFD:<span class="Apple-tab-span">        </span>84ns<span class="Apple-tab-span">  </span>(+0%)</p></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
If you have a stored string in NFD, an<br>
input string needs to be converted to NFD to be compared with<br>
it. If you have a stored string in NFC, an input string needs to<br>
be converted to NFC to be compared with it.  No significant<br>
difference there.  I do remember Mark Davis telling the IDNABIS<br>
WG that testing for NFC conformance was appreciably less costly<br>
than converting to NFC.  I don't know if the same relationship<br>
would hold for NFD but, again, if the string to be compared to a<br>
stored one comes from a keyboard, it is more likely to be in NFC<br>
form than in NFD form (if an operating system decides to<br>
normalize keyboard input before delivering it to an application,<br>
all bets are off).<br>
<br>
So, while at least some of the particular concerns that drove<br>
the NFC decision for IDNA don't apply to XMPP, it still seems to<br>
me that you haven't made any real case for NFD rather than NFC.<br>
If the choice really is arbitrary, then being different is not<br>
an advantage.<br>
<font color="#888888"><br>
   john<br>
</font><div><div></div><div class="h5"><br>
<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>
</div></div></blockquote></div><br>