On 10/04/2013 09:07 PM, Andrew Sullivan wrote:
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.
Thanks, Andrew. As an editor, one gets so close to the document that
it's hard to tell what's good and what's not.
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.)
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?
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.
OK, I will try to find better wording, or just reuse what you've sent.
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.
Will do.
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.
I caught one typo in section 9.5: "stings". (I think my giggling over
this might have alarmed the passenger next to me today.)
I'm happy that we were able to provide a bit of entertainment. :-)
Peter
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
