Re: Bidi issues

 > > http://www.gnomon.org.uk/bidi-ambiguities.txt
 > > 
 > > Not sure how useful it is, and it's definitely unfinished
 > 
 > I have now read it, and found it very helpful in building some intuition
 > about bidi issues.  Thanks!

I'm glad you found it useful.  I was in two minds whether to post it
in its current form, but since I'm unlikely to have time to do any
more work on it this week, I figured I might as well...

 >  4) If a number can see class R before itself, and if its field of view
 >     also contains number separators, that is asking for trouble.  In
 >     Unicode 3.2 class R is just the Hebrew letters/ligatures/punctuation
 >     and the right-to-left mark.  The six number separators are / , . :
 >     no_break_space arabic_comma (and their compatibility equivalents,
 >     which are removed by NFKC).

You can be slightly more specific than this.  Consider a potential
number as as string of consecutive number characters, terminators and
separtors.  To create an ambiguity the potential number has to contain
european numbers (since there are no arabic terminators).  Also, it
needs to contain either number terminators or a mixture of european
and arabic numbers.  Without this, you can't create the case where the
separator character does not parse as part of the number.  You can do
slightly better still by considering the separator type and what has
to be on either side of it.

 > Did I make any mistakes?  (It's quite likely.)

What you say tallies with my current understanding.  But it's quite
likely I've made mistakes, too :)

 > This is not completely effective at avoiding ambiguity because there
 > were other constraints (simplicity and backward compatibility).  But if
 > avoiding amiguity had been the only goal, then I think the following
 > much less restrictive (and simpler) check would have been as effective:
 > 
 >   * The string must not contain strong LTR and strong RTL and number
 >     characters.

But note that the stringprep rules resolve the following case by
disallowing the second possibility.  AIUI, what you propose wouldn't.
So (whether by accident or by design) the stringprep rules do go some
way to towards avoiding inter-component ambiguity.  Whether that's by
accident or by design, I wouldn't like to say.

	abc123.ABC.com (logical order)
	abc123.CBA.com (display order)

*	abcABC.123.com (logical order)
	abc123.CBA.com (display order)

 > I'm still assuming that the direction of the context is known to the
 > person looking at the string.  If we drop that assumption, would that
 > motivate the more restrictive rules of the Stringprep bidi check?

Can we ask the designers of the stringprep bidi restrictions?  I guess
finding the relevent disussions in the IDN WG archives is going to be
a lot or work...

Maybe some rationale could be added to the stringprep document when it
is being revised as a draft standard?  This stuff isn't obvious, and
it would be very helpful to have it explained, rather than just
presented as a fait acompli.

	-roy