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

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

Heh, I was just now addressing your feedback in my working copy of the
spec. -)

On 10/11/2013 07:39 PM, Florian Zeitz wrote:
> On 09.10.2013 05:20, Peter Saint-Andre wrote:
>> Hi Florian, thanks for the review! Comments inline.
>>
>> On 09/10/2013 08:06 PM, Florian Zeitz wrote:
>>> 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.
>>
>> You are correct. Validity really applies at the level of a profile, not
>> a 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.
>> When you suggest that we specify a class in terms of codepoints, are you
>> suggesting that go back to something like the stringprep model, in which
>> a class or profile defines a lookup table?
> Well, yes and no. We certainly want the rule/category based algorithm in
> order to have Unicode version agility, and I'm not suggesting we get rid
> of it. I'm also not suggesting we drop the rules about having some
> codepoints only valid in a certain context.
> I do however think it may be more sensible to say a string is within a
> PRECIS class iff all its characters are PVALID, CONTEXTO, or CONTEXTJ
> for this class, and a contextual rule is fulfilled, if required.

The way I see it, it doesn't make much sense to talk about a string
matching a class. In practice within an application protocol, a string
will be checked against the full set of rules as defined by a profile. A
string class provides a kind of "substrate", if you will, but it doesn't
define things in enough detail to perform string matching.

> This may even already be the intent, but as I said a profile can easily
> be defined such, that a string matches this criteria, but can never be
> produced after the specified normalization and all mappings were applied.
> At any rate I think we need clearer text about the intention here,
> answering the question: "When is a string allowed by a profile?". I
> personally can not really tell from the draft right now.

In part, I don't think it is the responsibility of this specification to
answer that question, other than to make it clear that you need to check
a string against the full set of rules defined by a profile. I do think
it would be helpful to provide some examples, although I think they
probably belong in the various specs that define the profiles (so far
that would be nickname, saslprepbis, and 6122bis).

>>> 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.
>> I agree that all good application protocols that use PRECIS need to
>> specify the enforcement rules, as we already do for SASL and XMPP. I am
>> less sure that the PRECIS framework needs to legislate that.
> I think not legislating this only gives people a great way to shoot
> themselves in the foot. I could be convinced otherwise though.

Yes, we are trying to prevent such "foot guns". I don't think we can get
very specific (e.g., some technologies that use PRECIS might not have a
client-server architecture). I'll see about proposing some text here...

>>> [...]
> I think we have agreement (or separate threads) about all other points.

Great, thanks.

Peter