Dear colleagues, On Wed, Aug 28, 2013 at 03:46:03PM +0900, Yoshiro YONEYA wrote: > The WGLC will end on Wednesday, Sep 11th.
On the principle of "better late than never", I at last got to this document. Many apologies for taking so long. First, let me say that this is one of the best drafts I've read in some time. It's in very good shape, I think, and could go as it is. Naturally, however, I cannot help suggesting some gilt to go on that lily. The editors should feel free to ignore any or all of this. There was one largish issue that troubled me. The discussion in 9.5 basically talks about the risks from enormous character repertoires, and I wondered whether people won't start asking for a way to negotiate locale or something similar as a mechanism for narrowing the choices. Certainly, something along these lines has been requested (not to say "vehemently demanded") over and over for IDNA. In IDNA it's completely impractical, owing to caches, the need for compatibility with existing DNS stuff, and so on. It strikes me as pretty impractical here, too, but I thought I'd raise it if only so we can put it down. (I'm also aware that it's pretty late in the game to suggest this. Why it only struck me today I don't know. I have a dim memory of having discussed this once before, but I didn't find anything in the archive.) The paragraph in section 3.1 starting, "Although members of the community discussed the possibility of defining other PRECIS string classes " read oddly to me. As an alternative I can suggest, "Although it might be possible to create an additional class that falls somewhere between IdentifierClass and FreeformClass, it is not 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. The order of operations is laid out in section 3.2, but is really sort of explained in section 3.4.4. It might be nice to put at least a forward pointer in section 3.2 so that someone who knows what an NFKC is won't start spluttering. 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. I caught one typo in section 9.5: "stings". (I think my giggling over this might have alarmed the passenger next to me today.) Best regards, A -- Andrew Sullivan [email protected] _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
