<div dir="ltr">I think you are mistreading Ken's statement, since he is aware that there is no (formal) mapping phase. Where he says "The requirement<br>>in the protocol to normalize to NFKC will result in<br>>the correct Korean Hangul syllables in the range<br>
>U+AC00..U+D7A3 being passed to the registry for lookup,"<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 "n" + "a" is disallowed by the protocol, while the canonical equivalent syllable "na" 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"><<a href="mailto:duerst@it.aoyama.ac.jp">duerst@it.aoyama.ac.jp</a>></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>
>In addition, making the conjoining jamos DISALLOWED in<br>
>the table could lead to unexpected behavior for normalization<br>
>of Korean data in the context of an IDN protocol implementation.<br>
><br>
>What Korea is attempting here is to restrict the allowed<br>
>repertoire of characters for registration to U+AC00..U+D7A3,<br>
>which is fine. But such characters might also be<br>
>represented on the wire or in other data sources in<br>
>terms of sequences of conjoining jamos. The requirement<br>
>in the protocol to normalize to NFKC will result in<br>
>the correct Korean Hangul syllables in the range<br>
>U+AC00..U+D7A3 being passed to the registry for lookup,<br>
>but restricting the conjoining jamos in the IDNA protocol<br>
>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, Martin.<br>
<br>
<br>
<br>
<br>
#-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University<br>
#-#-# <a href="http://www.sw.it.aoyama.ac.jp" target="_blank">http://www.sw.it.aoyama.ac.jp</a> 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>