Re: [precis] WGLC: draft-ietf-precis-framework-09.txt

[Peter Saint-Andre <[e-mail]>]

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