Re: [precis] Directionality rule (Was: Review of current document draft-ietf-precis-framework-20)

[Bjoern Hoehrmann <[e-mail]>]

* Pete Resnick wrote:
>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.

I am not happy with "this document generally recommends"; it's not clear
if this is the recommendation or if the recommendation is elswhere; it's
also not clear if this a RFC 2119 RECOMMENDED or something weaker, made
worse by "generally" and also the preceding "unless". Should be easy to
rephrase, but I do not have a good idea right now.
-- 
Björn Höhrmann · mailto:[e-mail] · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/