* 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:[email protected] · 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/ _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
