<div dir="ltr">> <span class="Apple-style-span" style="border-collapse: collapse; ">For Korean, there is no<br>equivalent because NFC doesn't produce the relevant precomposed<br>forms.</span><div><span class="Apple-style-span" style="border-collapse: collapse; ">> And, because it doesn't, our problem is not one of<br>
confusing similarity (a registry problem) but one of having<br>comparisons work correctly (a much deeper issue which we have<br>generally dealt with in the protocol, in the analogous case by<br>the requirement for NFC.</span><div>
<span class="Apple-style-span" style="border-collapse: collapse;"><br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse;">John, your first premise, and thus your whole argument is incorrect. The combining Jamo *do* form composed characters under NFC. Here is an example:</span></div>
<div><br></div><div><span class="Apple-style-span" style="font-family: Times; font-size: 16px; "><code><a target="c" href="http://unicode.org/cldr/utility/character.jsp?a=1100">U+1100</a></code> ( ᄀ ) HANGUL CHOSEONG KIYEOK<br>
<code><a target="c" href="http://unicode.org/cldr/utility/character.jsp?a=1161">U+1161</a></code> ( ᅡ ) HANGUL JUNGSEONG A<br><code><a target="c" href="http://unicode.org/cldr/utility/character.jsp?a=11A8">U+11A8</a></code> ( ᆨ ) HANGUL JONGSEONG KIYEOK</span><br>
</div><div><span class="Apple-style-span" style="border-collapse: collapse;">=></span></div><div><span class="Apple-style-span" style="border-collapse: collapse;"><span class="Apple-style-span" style="border-collapse: separate; font-family: Times; font-size: 16px; "><code><a target="c" href="http://unicode.org/cldr/utility/character.jsp?a=AC01">U+AC01</a></code> ( 각 ) HANGUL SYLLABLE GAG</span><br>
</span></div><br>That is, each of the Hangul precomposed syllables decomposes into one or two combining jamo under NFD, and under NFC that sequence of combining jamo composes back into that syllable. The comparisons *do* work correctly, since IDNA labels have to be in NFC.</div>
<div><br>For non-modern use characters, the NFC form may not combine all of the characters, simply because there may not be a corresponding precomposed form to combine them into. That is not a problem. It is similar to cases with accents; the NFC form composes as much as it can, but where it can't compose it leaves the code points separate.</div>
<div><br></div><div>The key point is that the result is still unique and does not cause a problem for comparison.</div><div><br><div>Mark<br>
<br><br><div class="gmail_quote">On Tue, Oct 14, 2008 at 10:17 PM, John C Klensin <span dir="ltr"><<a href="mailto:klensin@jck.com">klensin@jck.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<br>
--On Tuesday, 14 October, 2008 13:22 -0400 Andrew Sullivan<br>
<div class="Ih2E3d"><<a href="mailto:ajs@commandprompt.com">ajs@commandprompt.com</a>> wrote:<br>
<br>
> On Sun, Oct 12, 2008 at 05:25:27AM -0400, Vint Cerf wrote:<br>
>> Consensus Call Tranche 8 (character adjustments)<br>
>><br>
>> Place your reply here: [NO]<br>
>><br>
>> COMMENTS:<br>
><br>
>> (8.a) Make Eszett Protocol-Valid per list discussion.<br>
>><br>
>> (8.b) Make Greek final sigma Protocol-Valid per list<br>
>> discussion.<br>
><br>
> Since the call is all-or-nothing, I have to respond "no". On<br>
> these two, I have no opinion; I don't feel sufficiently<br>
> qualified to say whether these individual characters should be<br>
> altered. My understanding is that, because they are<br>
> consistent with the tables approach that we are taking, the<br>
> only reason to exclude them would be historical.<br>
<br>
</div>For whatever my opinion is worth, exactly.<br>
<div class="Ih2E3d"><br>
> Since the<br>
> unhappiness with some of those historical decisions is part of<br>
> the justification for the current work, it seems to me that<br>
> these ought to be allowed (although I wonder whether 8.b ought<br>
> to have a context rule).<br>
<br>
</div>Could you explain why you would require a context rule for Final<br>
Sigma without requiring one for Eszett? Certainly it would be<br>
easier to specify a rule for the former ("Script=Greek") while<br>
the latter would presumably either require either "Script=Latin"<br>
(which wouldn't do much good) or an enumerated list of<br>
characters. One can't require that the character actually<br>
appear in the last position in a label without preventing people<br>
from constructing labels by cramming words together... any<br>
prohibition along _those_ lines should certainly be a registry<br>
decision, IMO.<br>
<br>
For the record (and context when that discussion re-emerges on<br>
the list), at least some of the Greek IDN community would prefer<br>
that we preserve the IDNA2003 mapping / case-folding behavior<br>
for final sigma even if that is the only required mapping in<br>
IDNA2008.<br>
<div class="Ih2E3d"><br>
>> (8.c) Disallow conjoining Hangul jamo per recommendation from<br>
>> KRNIC and others, permitting only precomposed syllables.<br>
><br>
> This appears to open the character-by-character decision<br>
> making that we already ruled out. As Mark Davis argues, if we<br>
> accept this restriction then we probably need to re-open the<br>
> discussions about obsolete scripts, &c. It sounds to me very<br>
> like a registry policy.<br>
<br>
</div>Let me try to explain the other point of view, to the extent to<br>
which I understand the issues as they have been explained to me<br>
by the group associated with the Korean registry (if I have it<br>
wrong, I hope they will step in directly). I am going to try to<br>
write this so as to not be inflammatory. If I fail, I want to<br>
stress that being inflammatory is not my intent and ask<br>
forgiveness in advance.<br>
<br>
Unicode classifies characters in various ways using a collection<br>
of categories and properties. Those categories and properties<br>
(or at least the vast majority of them) were designed long<br>
before the IETF started thinking about IDNs; they were certainly<br>
not optimized for IDNA requirements. Given that, we should be<br>
grateful and pleasantly surprised that the properties work as<br>
well as they do for our purposes. On the other hand, we should<br>
not be surprised when, for some group of characters, they do<br>
not... and that has nothing to do with character by character<br>
decisions, at least as I understand that term.<br>
<br>
Before addressing the Hangul question, let me invent an example<br>
that is counterfactual, i.e., barring something unforeseen, we<br>
are unlikely to ever have to deal with it directly. There is a<br>
proposal pending for ISO/IEC JTC1/SC2/WG2 to add a number of<br>
annotation marks for Arabic. These marks are, according to the<br>
proposal (with confirmation from independent experts) used<br>
strictly for pedagogical purposes. Obviously, if one were<br>
going to transmit the instructional texts electronically in<br>
other than page image form, they have to have code points. They<br>
are identified in the proposal with General Category "Sk"<br>
(modifier symbols). With that classification, the rules in<br>
"Tables" would automatically place them in DISALLOWED. But<br>
suppose the proposal had identified them as modifier letters<br>
instead (I'm told there is a case to be made for that, even<br>
though the relevant Unicode folks have --wisely from our point<br>
of view but perhaps not others-- decided otherwise). Then we<br>
would need to exclude them (the whole group, not<br>
character-by-character) as a backward-compatibility issue<br>
because otherwise, to quote a colleague, we would have a huge<br>
mess on our hands, with all sorts of equivalences failing.<br>
Again, this is _not_ an issue, but it may help in thinking about<br>
the Hangul problem.<br>
<br>
For Hangul, the individual Jamo (again, a clearly-identified<br>
group of characters, not a character-by-character decision) are<br>
used to construct conventional (and precomposed) characters<br>
("Hangul syllables"). To the extent to which there is an<br>
analogy in Latin-based script, they would be combining<br>
characters that combine without a base character. For<br>
Latin-based scripts, we don't need to worry about conflicts<br>
between precomposed characters and composing (base+combining<br>
character) forms of the same characters because the NFC<br>
requirement deals with the problem. For Korean, there is no<br>
equivalent because NFC doesn't produce the relevant precomposed<br>
forms. And, because it doesn't, our problem is not one of<br>
confusing similarity (a registry problem) but one of having<br>
comparisons work correctly (a much deeper issue which we have<br>
generally dealt with in the protocol, in the analogous case by<br>
the requirement for NFC. If Unicode had assigned properties<br>
that treated the Syllables differently from the Jamo, we would<br>
simply build a rule using those categories and we would not be<br>
having a discussion about, e.g., "character by character<br>
decisions". But there is apparently no such property --both the<br>
Jamo and the Syllables are in General Category "Lo" and the rest<br>
of the properties appear to match as well.<br>
<br>
I think the situation --and the comparison failures that would<br>
result if we don't deal with it-- makes a strong case for our<br>
disallowing either the Jamo or the Syllables. The ccTLD<br>
registry and local experts strongly prefer that we disallow the<br>
Jamo, even though it means that some archaic Syllables and<br>
fanciful forms are disallowed as a consequence. I think we<br>
just defer to them.<br>
<br>
Just my opinion, of course.<br>
<div class="Ih2E3d"><br>
> The argument that some people will get<br>
> that registry policy wrong has already been floated, and we<br>
> rejected it. Indeed, if we don't reject that premise, then<br>
> all of the local mapping approach that we've taken should be<br>
> tossed out, and we should go back to strict mapping in the<br>
> protocol.<br>
<br>
</div>Again, the issue here is one of comparison failures, not of<br>
confusability or other registry policy questions.<br>
<font color="#888888"><br>
john<br>
</font><div><div></div><div class="Wj3C7c"><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></div></div></div>