On 2/11/15 2:33 PM, Pete Resnick wrote:
On 2/9/15 4:53 PM, Peter Saint-Andre - &yet wrote:
On 2/9/15 1:42 PM, Pete Resnick wrote:
But give me a bit to chat with Klensin and we'll see if we can come
up with sanity.
I agree that the Bidi Rule from RFC 5893 is designed for use with DNS
labels, and that it's not a perfect fit for PRECIS strings. But it
might be the best we can do right now.
OK, here is some text that I worked on with John. We think this has the
desirable properties that it is both as close to correct as we're going
to get *and* what the WG intended. This is meant to be a replacement for
all of the text in 5.2.5:
The directionality rule of a profile specifies how to treat strings
containing what are often called "right-to-left" (RTL) characters.
RTL characters come from scripts that are normally written from right
to left and are considered by Unicode to, themselves, have right to
left directionality. Strings containing RTL characters often also
contain "left-to-right" (LTR) characters, such as numerals, as well
as characters without directional properties. Consequently, such
strings are known as "bidirectional strings". Using bidirectional
strings in different layout contexts may yield display results that,
while predictable to those who understand the display rules, may be
counter-intuitive to casual users. Therefore some profiles may wish
to restrict their use by specifying a directionality rule.
The PRECIS framework does not directly address how to deal with
bidirectional strings, since there is currently no widely accepted
and implemented solution for the safe display of arbitrary
bidirectional strings beyond the general Unicode bidirectional
specification [UAX9]. Rules for management and display of
bidirectional strings have been defined for domain name labels and
similar identifiers in the "Bidi Rule" from [RFC5893]. If a profile
really needs to specify a directionality rule, unless a great deal of
careful research into the problems of displaying bidirectional text
is done (which is outside of the scope of this framework), this
document generally recommends using the "Bidi Rule" from [RFC5893]
for profiles based on IdentifierClass, and for profiles based on
FreeformClass or other situations in which IdentifierClass is not
appropriate, that consideration be given to using UAX #9 directly.
What do you think?
I think it's good up until the last sentence, which is convoluted. But
the tone is right and we might even want to borrow some text from
Section 3 of RFC 5895. ;-)
A possible refactoring...
OLD
If a profile
really needs to specify a directionality rule, unless a great deal of
careful research into the problems of displaying bidirectional text
is done (which is outside of the scope of this framework), this
document generally recommends using the "Bidi Rule" from [RFC5893]
for profiles based on IdentifierClass, and for profiles based on
FreeformClass or other situations in which IdentifierClass is not
appropriate, that consideration be given to using UAX #9 directly.
NEW
The authors of a profile might think that they need to define a new
directionality rule of their own. This is not a good idea, even if
the authors have done a great deal of careful research into the
problems of displaying bidirectional text. Instead, this document
recommends the following:
o For profiles based on the IdentifierClass, it is best to use the
"Bidi Rule" from the IDNA2008 specification on right-to-left
scripts [RFC5893].
o For profiles based on FreeformClass (or in situations where
IdentifierClass is not appropriate), it is best to follow the
recommendations of Unicode Standard Annex #9 [UAX9] directly.
Peter
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
