<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 23, 2016 at 2:29 PM, João Pinheiro <span dir="ltr">&lt;<a href="mailto:joao@joaopinheiro.org" target="_blank">joao@joaopinheiro.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">&gt; I think we&#39;re using terminology differently here. What you call &quot;character normalization&quot; is what I&#39;m calling canonicalization. NFC is described in UAX #15 as &quot;canonical decomposition followed by canonical composition&quot; and I&#39;m just using the word &quot;canonicalization&quot; because it&#39;s shorter. If Swift represents each identifier in an NFC-transformed form (what I call canonicalized), then I understand the identifier to be canonicalized. What is the distinction you&#39;re drawing here?<br>
<br>
</span>There is a small difference between normalisation and canonicalisation, but it&#39;s mostly splitting hairs. They both ensure something is represented properly, but canonicalisation implies establishing a single base representation for something. Web addresses are a good example. Both <a href="http://www.apple.com" rel="noreferrer" target="_blank">http://www.apple.com</a> and <a href="http://apple.com" rel="noreferrer" target="_blank">http://apple.com</a> are valid normalised addresses, but only the former is the canonical address for the Apple website.<br>
<span class=""><br>
&gt; Just re-read UAX #31. I see two different issues here too--do these match up with what you&#39;re saying above?<br>
&gt;<br>
&gt; * Disallowing certain glyphs in identifiers. To do so, we can implement the recommendation to disallow all glyphs in UAX #31 Table 4, except ZWJ and ZWNJ in the specific scenarios outlined in section 2.3.<br>
&gt;<br>
&gt; * Internally, when comparing two identifiers A and B, compare NFC(A) and NFC(B) without modifying or otherwise restricting the actual user-facing code to contain only NFC-normalized strings. This would be the approach recommended in section 1.3.<br>
<br>
</span>Yes, that&#39;s correct. The proposal would be to normalise the encoding via NFC and then canonicalise the identifiers by ignoring invisible characters except in the scenarios described in UAX #31</blockquote><div><br></div><div>That&#39;s cool, although my preferred solution would be more closely aligned with UAX #31: overtly disallow the glyphs in Table 4 (instead of ignoring them) except in the specific scenarios for ZWJ and ZWNJ identified in UAX #31, then afterwards internally represent the identifier as its NFC-normalized string.</div><div><br></div></div></div></div>