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

From: Yoshiro YONEYA <[email-masked]>
Date: Wed, 4 Sep 2013 16:25:58 +0900

Dear all,

This is reminder.  WG LC will end next week.
Please review the document and give your feedback.

Regards,

-- Marc & Yoneya, co-chairs

On Wed, 28 Aug 2013 15:46:03 +0900 Yoshiro YONEYA <[email-masked]> wrote:

> Dear all,
> 
> This message starts two weeks Working Group Last Call (WGLC) on 
> draft-ietf-precis-framework-09.txt (PRECIS Framework: Preparation and 
> Comparison of Internationalized Strings in Application Protocols).
> 
> Please review the document and send comments to the list ([email-masked]), 
> the co-chairs ([email-masked]), or the authors 
> ([email-masked]) by the end of WGLC.
> 
> The WGLC will end on Wednesday, Sep 11th.
> 
> Regards,
> 
> -- Marc & Yoneya, co-chairs
> 
> _______________________________________________
> precis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/precis
> 
>

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 08 Sep 2013 17:53:59 +0100

> The WGLC will end on Wednesday, Sep 11th.
I reviewed the document and generally found no issues with it.

I have 1 nit:

In Section 5: Please replace NAME with ID in a couple of places. (I 
think one of Precis classes was renamed, but this was not reflected 
everywhere in the document.)

---

From: Florian Zeitz <[email-masked]>
Date: Wed, 11 Sep 2013 04:06:43 +0200

> The WGLC will end on Wednesday, Sep 11th.
I've reviewed this draft, and generally think it takes a sensible approach.
However, I do have one major grief about it, as well as some smaller
comments.

The major thing that bothers me about this draft is that string classes
IMHO conflate to separate concepts. On the one hand they specify valid
and disallowed codepoints. On the other hand they specify (or rather,
let the application protocol specify) mappings and normalization.
The problem I have with this is, that it makes it unclear which strings
are valid in a certain class.

E.g. consider an applications protocol that specifies FreeformClass
mixed with NFKC. This means characters, which have a compatibility
equivalent are valid in the sense that they are FREE_PVAL, but are
invalid in the normalization form. It is unclear to me, whether a string
containing characters with a compatibility equivalent would be contained
in the FreeformClass, or more precisely, this specialization thereof.

Similar considerations are true for e.g. mixing case mapping with
IdentifierClass. Uppercase characters are PVALID/ID_PVAL, but shouldn't
be present after mapping.

I would prefer it if we specified classes solely in terms of valid and
disallowed codepoints and directionality requirements.
We would then have separate text saying that an application protocol
MUST also specify which mappings and normalization to apply, what entity
needs to apply them (e.g. only the server), and when they need to be
applied (e.g. when comparing strings, before storing them, before
display to a user). Both StringPrep-bis and 6122bis already have text to
this effect. It seems sensible to me to generally require application
protocols to specify the "who", and "when" beyond the "what". E.g. it is
often sensible to display identifiers with their case as entered, but
compare them after case folding. The current text might suggest that
mappings have to be applied to user input immediately.

The following are smaller comments ordered by section:

Section 3.1:
This section talks about "safety" of strings, without ever defining what
that means in this context. The term "very safe" used to describe the
IdentifierClass also strangely reminds me of statements about "absolute
security". Maybe there is a way to generally word this better?

The sentence "Directionality:  defines application behavior in the
presence of code points that have directionality" seems a bit off to me.
It is very different from the explanation given later in Section 4.1.
>From my understanding this is about the allowed combinations of
characters with directionality, and not about "application beahvior" in
their presence. It could be about both, but I have not seen a draft talk
about anything but allowed combinations (i.e. the Bidi Rule) yet.

Section 3.3.3 and 3.4.3:
While "unassigned codepoints are unassigned" is a nice tautology, I'm
not sure what this means in terms of their treatment. In general I feel
like more explanation is needed about unassigned codepoints and their
(possible) handling.

Section 3.3.6:
I think it would be sensible to suggest using the Unicode Default Case
Folding algorithm, if case mapping is to be applied.

Section 5:
I feel like this lacks a normative statement about contextual rules.
E.g. "A character with the derived property value CONTEXTJ or CONTEXTO
   (CONTEXTUAL RULE REQUIRED) MUST NOT be used unless an appropriate
   rule has been established and the context of the character is
   consistent with that rule."

Regards,
Florian Zeitz

---

From: Joseph Yee <[email-masked]>
Date: Wed, 11 Sep 2013 22:06:20 -0400

> > The WGLC will end on Wednesday, Sep 11th.
Reviewed the draft, think the approach is good.  Just one minor comment.

Same as Florian, had the 'hmm' reaction when reading about directionality
and application behaviour at Section 3.1.  It seems that the only
application behaviour is permitted pattern.  It doesn't deal with visual
appearance I believed.  Maybe replace 'application behaviour' with
'permitted patther of the string' (or 'allowed combination of the string')?

Best,
Joseph