> (1) Directionality can be tricky. (not actionable, but > important context) > (2) If you have something identifier-like, use 5893 unless you > know better. > (3) If you have something more free form-like, use UAX #9 unless > you know better. > (4) If you think you know better, you are probably wrong; see > above.
+1 - I like that listing of principles. Items (2) and (3) look like they could be stated with "SHOULD" although I could live with weaker wording. In contrast, I think the text for (4) ought to definitely say "SHOULD NOT define a new directionality rule" and that ought to be called out in the IANA Considerations for the profiles registry in section 11.3 as important guidance to the designated expert reviewer(s). Thanks, --David > -----Original Message----- > From: precis [mailto:[email protected]] On Behalf Of John C Klensin > Sent: Thursday, February 12, 2015 1:08 PM > To: Peter Saint-Andre - &yet; Pete Resnick > Cc: [email protected] > Subject: Re: [precis] Directionality rule (Was: Review of current document > draft-ietf-precis-framework-20) > > > > --On Wednesday, February 11, 2015 18:59 -0700 Peter Saint-Andre > - &yet <[email protected]> wrote: > > >... > > How's this? > > > The authors of a profile might believe that they need to > > define a new directionality rule of their own. Because of the > > complexity of the issues involved, such a belief is almost > > always misguided, even if the authors have done a great deal > > of careful research into the problems of displaying > > bidirectional strings. This document suggests that profile > > authors who are thinking about defining a new directionality > > rule think again, and instead consider using the "Bidi Rule" > > [RFC5893] (for profiles based on the IdentifierClass) or > > following the Unicode bidirectional algorithm [UAX9] directly > > (for profiles based on the FreeformClass or in situations > > where the IdentifierClass is not appropriate). > > Wfm. > > > One thing that bothers me here is that we're not providing > > actionable guidance to the vast majority of non-delusional > > profile authors. Are we saying that it's not a good idea to > > say anything about directionality at all? > > I think I don't understand what you are saying/ asking for. It > seems to me that every version of the statement posted to the > list in the last 24 hours has said things that come down to: > > (1) Directionality can be tricky. (not actionable, but > important context) > (2) If you have something identifier-like, use 5893 unless you > know better. > (3) If you have something more free form-like, use UAX #9 unless > you know better. > (4) If you think you know better, you are probably wrong; see > above. > > (2) and (3) are, AFAICT, about as actionable as things get, > representing clear statement of the character of "if <condition> > then do this..." The "unless you know better" statements and > (4) is a warning about (2) and (3) to avoid our getting too > normative about situations we can't anticipate > > The only substantive difference I've seen in the various > statements is whether the equivalent to (3) suggests saying as > little as possible about FreeformClass. > > I'd rather we didn't, but the above could be restated in > 2119-speak as: > > (2) If you have something identifier-like, you SHOULD use 5893. > (3) If you have something more free form-like, you SHOULD use > UAX #9. > (1) and (4) Directionality is tricky. If you have specific > knowledge of the characters or script(s) you are using that the > contexts in which they are used, you MAY invent your own > techniques and specifications, as allowed by the above. > However, there is considerable experience to indicate that you > should not do so unless it is also absolutely necessary because > you are likely to get it wrong and, even if you don't, adopting > rules different from 5893 or UAX 9 is likely to confuse and > irritate users. > > john > > _______________________________________________ > precis mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/precis _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
