On 10/8/13 10:23 PM, Andrew Sullivan wrote: > On Tue, Oct 08, 2013 at 08:36:31PM -0600, Peter Saint-Andre wrote: >> I take it you're suggesting that we add a bit explaining that PRECIS >> does *not* include a way to specify the locale for purposes of >> restricting the range of codepoints that are allowed in a given >> profile? > > Because I'm not as clever as you, it hadn't occurred to me to suggest > that exactly. But that might well be another way to cope with the > topic: "Yeah, we know you want this. If you really want it, you need > a special-purpose internationalization framework, and not a > general-purpose one." The more I think about it, the more I think > that's true. The user's linguistic environment has so many > tightly-bound implications for an application that if you really need > to know about it, your application needs to get dirty. (Come to think > of it, this is another nice way of explaining the IDN problem around > this sort of request too. Thanks!)
Something along those lines sounds good. >>> clear how useful such a class would be. In any case, because of the >>> ability to subclass FreeformClass, a protocol needing something more >>> particular is always able to create it." I don't really care about >>> this; it was just something that struck me on the way by. >> OK, I will try to find better wording, or just reuse what you've sent. > > It could be that, with your other proposal (in another thread) about > getting rid of subclassing and making it all use profiles, this point > will find a more natural expression. Perchance. :-) >>> In section 6.7, I want to make sure we're ok with following IDNA2008's >>> lead on U+19DA, which moved from PVALID to DISALLOWED in Unicode 6.0. >>> In the precis case, it's FREE_PVAL. I think that's fine, but I just >>> want to call attention. >> Given that we're defining PRECIS in terms of Unicode 6.2, it seems >> that it might be more appropriate to make it DISALLOWED. But I don't >> have a strong feeling about that. > > Well, this was exactly my point. If we do that, we really _are_ > clearly treating at least one character differently than IDNA does. > In that case, we need to open the description in the text to point out > the difference. Given the plain fact that U+19DA is so obscure as to > be practically irrelevant, I don't want to make a big deal. But I > guess being picky about the details in this case allows us to see > where the seams are, and that's probably a good thing for the WG to > pay attention to. It seems to me best not to special-case this character. Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
