I strongly agree.<br><br clear="all">Mark<br>
<br><br><div class="gmail_quote">On Mon, Jul 20, 2009 at 18:07, Kenneth Whistler <span dir="ltr">&lt;<a href="mailto:kenw@sybase.com">kenw@sybase.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Patrik,<br>
<br>
&gt; <a href="http://stupid.domain.name/stuff/draft-ietf-idnabis-tables-06a.txt" target="_blank">http://stupid.domain.name/stuff/draft-ietf-idnabis-tables-06a.txt</a><br>
<br>
There are very, very serious errors in the two CONTEXTJ rules<br>
for ZWNJ and ZWJ. As currently stated, they are both<br>
underspecified and overspecified, and both rules actually<br>
eliminate *all* of the contexts that would actually<br>
be appropriate for use of ZWNJ or ZWJ in scripts of India.<br>
<br>
Furthermore, the two rules rathole on the unrelated problem<br>
of trying to constrain domain names to single scripts,<br>
which serves to accomplish nothing here but to hide the<br>
actual context constraints of relevance to these<br>
two characters.<br>
<br>
I would suggest that the two rules drop all reference to constraints<br>
trying to keep all the domain name in a single script -- that<br>
can better be handled by registries than by a protocol rule<br>
at this point.<br>
<br>
Here is the 10,000 meter overview of what these rules should<br>
be specifying:<br>
<br>
ZWNJ is needed in the Arabic script on occasion to break<br>
a cursive connection. Its useful<br>
context is when it is preceded by a left-joining or dual-joining<br>
character and followed by a right-joining or dual-joining<br>
character (possibly with transparent characters, such<br>
as combining vowel marks, intervening).<br>
<br>
ZWJ is *NOT* needed in the Arabic script (for the purposes we<br>
are concerned with).<br>
<br>
ZWNJ and ZWJ are both needed in the scripts of India and<br>
Sri Lanka on occasion. Their useful context is in consonant<br>
conjuncts, or more precisely when preceded by a virama<br>
which itself is preceded by a consonant letter.<br>
<br>
Note that the contexts as summarized above will already<br>
do a lot to constrain the use of ZWNJ and ZWJ in domain<br>
names to the appropriate scripts. Why? Because the *only*<br>
characters that have right-, left-, or dual-joining properties<br>
are those in cursive scripts that may require an orthographic<br>
break in a cursive connection: Arabic, most importantly, but<br>
also Syriac. Domain name labels in all other scripts would<br>
get automatically dumped by this constraint, because none of<br>
their letters have the requisite cursive properties.<br>
<br>
And for Indic scripts, the context is also automatically<br>
constrained by requiring a preceding virama. Only the<br>
relevant scripts have virama characters. Furthermore, each<br>
virama for each script has the corresponding script property,<br>
which means that any higher-level constraint sensitive to<br>
the scripts of labels would see and test any virama. Eliminate<br>
the virama, and you would automatically eliminate any<br>
inappropriate contexts for a ZWNJ or ZWJ.<br>
<br>
Given these considerations, the context rules for ZWNJ and<br>
ZWJ and be written much more succinctly, comprehensibly,<br>
simply, and reproducibly. I suggest the following:<br>
<br>
=============================================================<br>
<br>
Appendix A.2  ZERO WIDTH NON-JOINER<br>
   Code point:<br>
      U+200C<br>
   Overview:<br>
      This may occur in a formally cursive script (such<br>
      as Arabic) in a context where it breaks a cursive<br>
      connection as required for orthographic rules, as<br>
      in the Persian language, for example. It also may<br>
      occur in Indic scripts in a consonant conjunct<br>
      context (immediately following a virama), to<br>
      control required display of such conjuncts.<br>
   Lookup:<br>
      True<br>
   Rule Set:<br>
      False;<br>
      If Canonical_Combining_Class(Before(cp)) .eq. Virama Then True;<br>
      If RegExpMatch((Joining_Type:{L,D})(Joining_Type:T)*\u200C<br>
                     (Joining_Type:T)*(Joining_Type:{R,D})) Then True;<br>
<br>
=============================================================<br>
<br>
Appendix A.3  ZERO WIDTH JOINER<br>
   Code point:<br>
      U+200C<br>
   Overview:<br>
      This may occur in Indic scripts in a consonant conjunct<br>
      context (immediately following a virama), to<br>
      control required display of such conjuncts.<br>
   Lookup:<br>
      True<br>
   Rule Set:<br>
      False;<br>
      If Canonical_Combining_Class(Before(cp)) .eq. Virama Then True;<br>
<br>
=============================================================<br>
<br>
Note that I have also turned the default values around for<br>
these rule sets. With the more cleanly defined contexts,<br>
it is much better to default these to False, and then<br>
only return True for the precisely defined exceptional contexts<br>
where they may occur.<br>
<br>
I think if the rule sets are stated this way, there is a vastly<br>
greater chance that implementers will implement these context<br>
rules in compatible and interoperable ways. The code will<br>
also be immensely simpler (and less prone to irrelevant<br>
bugs) than as the rules sets are stated in the current draft.<br>
<br>
--Ken<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>
</blockquote></div><br>