On 4/15/14 7:32 PM, Peter Saint-Andre wrote:
On 4/14/14, 9:18 PM, Peter Saint-Andre wrote:
On 4/7/14, 11:40 AM, Pete Resnick wrote:
-----
Substantive issue:
-----
4.1.5: I'm not thrilled with this section in general, but in
particular
I'm not sure what "mixed-direction strings are not supported"
means. We
do know how to process strings that contain characters with a mix of
directionality. Such strings are sometimes a visual challenge, but
not a
processing challenge: RFC 5893 exists because IDNs want to use "."
as a
label separator yet have text display work in a context that is
unaware
of labels. Neither using 5893 nor considering any RTL character making
the whole string RTL is a good recommendation for most cases. Not sure
what to do about this.
See:
http://www.ietf.org/mail-archive/web/precis/current/msg00553.html
...wherein Martin seems to say that this is only allowing fully RTL and
fully LTR (i.e., no mixed direction strings).
http://www.ietf.org/mail-archive/web/precis/current/msg00557.html
...wherein you reply that not allowing mixed direction strings was
intended. :-(
I am not sure how helpful it is to distinguish between processing
challenges and presentation challenges.
There are scant few processing challenges, at least from my
long-ago-in-a-galaxy-far-far-away memory of the last time I wrote any
code in this area. They are all (again, as far as I remember)
presentation challenges.
I will ponder this further and reply again.
I recall discussion at one of our in-person meetings about bidi. As I
recall, John Klensin sagaciously pointed out that if the PRECIS WG
tried to define a new rule for directionality we would almost
certainly get it wrong, and that it was better to use the Bidi Rule
from RFC 5893 than to design something new. Even though it might be
true that the Bidi Rule might not be a good recommendation for most
cases, I do not have confidence in our ability to come up with a
better recommendation.
On that we can agree. I am sure I do not want to come up with other
rules for inclusion (because those rules are completely dependent on the
presentation challenges you are or are not willing to contend with). I
guess in the end I'd just like the text in 4.1.5 softened to say, "You
can have a directionality rule for your profile anything from 'whatever
mix of RTL and LTR characters you like' if you don't care how they're
presented, all the way to the complicated Bidi Rule from 5893 if you
expect users to be typing in protocol elements, and you have to deal
with strings with separator punctuation and presentation tools that
don't know about them."
Would you say that the Bidi Rule works for domain names because "." is
a label separator? In particular, my understanding of the Bidi Rule is
that it doesn't allow mixed-direction *labels*, although it does allow
mixed-direction domain names (where the direction changes at the point
of the label separator).
Correct. The *only* reason for the 5893 Bidi Rule is because they wanted
domain names to display identically in both LTR and RTL contexts when
the display engine didn't understand that the "." was a label separator.
(Well, I guess that's two reasons combined in one.)
It seems to me that not supporting mixed-direction strings in PRECIS
is consistent with RFC 5893.
It is consistent with 5893, but I am saying that there are a number of
cases where it's the wrong thing to do. There are protocols that
shouldn't care whether that strings display inconsistently when the user
changes from RTL to LTR contexts. What's the problem if I want my handle
to be:
pee e tee e dash pei samekh het
which if I type them in that order gets you:
Pete-פסח
which in a LTR context will display to you as (reading them off from
left to right):
pee e tee e dash het samekh pei
or in an RTL context will display to you as (reading them off from left
to right):
het samekh pei dash pee e tee e
The only problem is if you are worried that people will type them in
wrong because they don't know what directional context they're in. If
it's just my handle name and I'm the only one typing it, you should
leave me be.
I realize that's not ideal, but it might be the best that *we* can do
*now*. Whether some other group could do something better in the
future might be irrelevant.
Like I said, I'm not looking for a new rule. Just less overt pushing
that protocols never allow mixed direction text and that they should
lean toward 5893.
