I like this proposed change better. A
On Wed, Feb 11, 2015 at 05:40:09PM -0700, Peter Saint-Andre - &yet wrote: > 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 -- Andrew Sullivan [email protected] _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
