<div dir="ltr">I think you are mistreading Ken&#39;s statement, since he is aware that there is no (formal) mapping phase. Where he says &quot;The requirement<br>&gt;in the protocol to normalize to NFKC will result in<br>&gt;the correct Korean Hangul syllables in the range<br>
&gt;U+AC00..U+D7A3 being passed to the registry for lookup,&quot;<div><br></div><div>read that as:</div><div><br></div><div>The requirement in the protocol that the text <span class="Apple-style-span" style="font-weight: bold;">be in</span> NFKC <span class="Apple-style-span" style="font-weight: bold;">format</span> results in the correct Korean Hangul syllables ...</div>
<div><br></div><div>For example, a sequence of jamo &quot;n&quot; + &quot;a&quot; is disallowed by the protocol, while the canonical equivalent syllable &quot;na&quot; is allowed.<br></div><div><br clear="all">Mark<br>
<br><br><div class="gmail_quote">On Mon, Jul 28, 2008 at 11:14 PM, Martin Duerst <span dir="ltr">&lt;<a href="mailto:duerst@it.aoyama.ac.jp">duerst@it.aoyama.ac.jp</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">At 04:13 08/07/29, Kenneth Whistler wrote:<br>
<br>
&gt;In addition, making the conjoining jamos DISALLOWED in<br>
&gt;the table could lead to unexpected behavior for normalization<br>
&gt;of Korean data in the context of an IDN protocol implementation.<br>
&gt;<br>
&gt;What Korea is attempting here is to restrict the allowed<br>
&gt;repertoire of characters for registration to U+AC00..U+D7A3,<br>
&gt;which is fine. But such characters might also be<br>
&gt;represented on the wire or in other data sources in<br>
&gt;terms of sequences of conjoining jamos. The requirement<br>
&gt;in the protocol to normalize to NFKC will result in<br>
&gt;the correct Korean Hangul syllables in the range<br>
&gt;U+AC00..U+D7A3 being passed to the registry for lookup,<br>
&gt;but restricting the conjoining jamos in the IDNA protocol<br>
&gt;table itself is not a good idea.<br>
<br>
</div>I agree with Mark and Ken in general, but I think the above two<br>
paragraphs are wrong. In IDNA 2008, the only thing we ever<br>
talk about is the normalized stuff. Ideally, things would be<br>
normalized at source. If not, there is (different to IDNA 2003)<br>
no guarantee that or how things will be normalized. Non-normalized<br>
character sequences are totally outside the protocol in IDNA 2008<br>
(at least as currently proposed).<br>
<br>
Regards, &nbsp; &nbsp;Martin.<br>
<br>
<br>
<br>
<br>
#-#-# &nbsp;Martin J. Du&quot;rst, Assoc. Professor, Aoyama Gakuin University<br>
#-#-# &nbsp;<a href="http://www.sw.it.aoyama.ac.jp" target="_blank">http://www.sw.it.aoyama.ac.jp</a> &nbsp; &nbsp; &nbsp; mailto:<a href="mailto:duerst@it.aoyama.ac.jp">duerst@it.aoyama.ac.jp</a><br>
<div><div></div><div class="Wj3C7c"><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></div></div>