Comments on bidi-04
Erik van der Poel
erikv at google.com
Mon Mar 3 21:43:32 CET 2008
> >> o No two labels, when presented in display order, should have the
> >> same sequence of characters without also having the same sequence
> >> of characters in network order. (This is the criterion that is
> >> explicit in RFC 3454).
> >
> > The above needs to be qualified, by adding something like "in the same
> > bidi context". That is, as pointed out below, if you change the embedding
> > context, 123-456 in one context may look like 456-123 in another; same
> > for abc.ABC and ABC.abc.
>
> Erik, did you verify this within one context, or between contexts?
I verified it for both contexts, each time within that one context.
I.e. two hash tables, one for each context. I checked whether each
bidi reordered string was already in the hash table. If so, it would
complain; if not, it would add that string to the table.
> > A label L satisfies the Label Grouping Condition when for any Delimiter
> > Characters D1 and D2 and any other strings S1 and S2 (possibly of length
> > zero):
> >
> > If the string formed by concatenating S1, D1, L, D2, S2 is subject to
> > bidi reordering,
> > then all of the characters of L2 in the reordered string are between D1
> > and D2.
> >
> > - The bidi reordering of L1, D1, L, D2, L2 may result in D2 coming
> > before D1
> > - Because S1 is any string, the bidi algorithm may set the paragraph
> > direction for the string to either Right-To-Left or Left-To-Right; thus
> > the reordering condition has to work in both bidi contexts.
>
> that indeed sounds better.
That isn't what I tested though. I only made sure the characters stay
together. The label L might be at the beginning or end of the (bidi
reordered) string. I don't know whether that occurs in the exhaustive
testing, but the test allows L to be at the beginning or end, not
necessarily *between* D1 and D2.
Erik
More information about the Idna-update
mailing list