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

[Florian Zeitz <[e-mail]>]

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.

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.

>> 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.

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

Florian