I think what Harald is trying to do at multiple levels:<br><ol><li>specify the mechanism</li><li>determine and describe the requisite properties for the mechanism (eg that characters don't "hop" between different labels)
<br></li><li>describe how to mechanically verify that the mechanism has the requisite properties.</li></ol>The last two parts might be a bit more complicated, but very few people would actually need to be concerned with them. And only (2) would require use of the bidi algorithm.
<br><br>Once we have #2 and #3, then we can verify that Michel's method and/or Harald's method works; tweak if necessary; and go with the simplest formulation.<br><br>Mark<br><br><div class="gmail_quote">On Jan 14, 2008 2:40 PM, Kenneth Whistler <
<a href="mailto:kenw@sybase.com">kenw@sybase.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">Michel said:
<br><br>> Just to remember that the bidi rules that I proposed in my message<br>> dated 11/30/2007 to this list (excerpt below with some further<br>> editing) do not require to implement the bidi algorithm but only
<br>> relies in bidi properties and some positional conditions, and are<br>> much simpler to define and implement than the bidi algorithm itself.<br>> As such there are a mere update of the rules expressed in clause
<br>> 6 of RFC 3454 (stringprep) and can be used as processing rule in<br>> the idna200x protocol definition.<br><br></div>I want to second Michel's approach here.<br><br>If you look at the current text of bidi-02.txt
, the<br>proposed fix for RFC 3454 is to rewrite the definition of<br>RandALCat character and LCat character as following:<br><br> For characters that have category "R", "AL" or "L", the<br>
category is fixed (UAX#9 defines them as having "strong"<br> category);...<br><br>Note that that much is unchanged in Michel's textual approach.<br><br> ... for characters in category EN, ES, ET, AN, CS, NSM, BN, B,
<br> S, WS and ON, the category is determined by applying the<br> algorithm described in UAX#9 section 3.3 to the string.<br><br>But here, Michel's approach is much simpler. It focusses on<br>the main problem noted in RFC 3454, the problem of not
<br>allowing labels to end with combining marks -- a problem<br>that was disallowing well-formed Dhivehi and Yiddish labels,<br>for example. That is also the main problem discussed<br>in Section 1 (and exemplified in Section 2) of
bidi-02.txt.<br><br>Since the categorical treatment of bc=NSM characters is<br>trivial in the bidirectional algorithm, and doesn't imply<br>full application of the algorithm to understand and specify<br>it, simply adding the definition of NSMCat characters, and
<br>tightening up the specification of allowable label strings,<br>to include the appropriate use of the NSMCat values, is<br>much, much simpler than requiring an actual application<br>of the full bidirectional algorithm to determine the
<br>final, contextual resolution of weak types (X3.3.3) and<br>neutral types (X3.3.4).<br><br>Also, as somewhat of an aside, the current proposed wording<br>above in bidi-02.txt is overly broad in what it attempts<br>to accomplish, even if retained. bc=BN, while a weak
<br>bidi type, is never resolved to a strong type by X3.3.3;<br>by rule X9 all BN codes are logically removed from the<br>string *before* any resolution of weak types. And bc=B,<br>bc=S, and bc=WS can never occur in IDN labels in the
<br>first place, so you don't have to deal with the complications<br>of rule L1 for those, either. And finally, bc=AN never<br>gets resolved to one of the strong types. So at the very least, the<br>statement could be simplified to:
<br><br> ... for characters in category EN, ES, ET, CS, NSM,<br> and ON, the category is determined by applying the<br> algorithm described in UAX#9 section 3.3 to the string.<br><br>But I think Michel's focus on just dealing with bc=NSM is
<br>much cleaner and still suffices to deal with the problem.<br><div><div></div><div class="Wj3C7c"><br>--Ken<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><br clear="all">
<br>-- <br>Mark