Re: [precis] RFC 8264 / 8265 Order of rules

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

On 5/11/18 1:04 PM, William Fisher wrote:
> Hi Peter,
> 
> My thoughts on your proposed text is below.
> 
> I, for one, thought you did a good job with such a complex topic.
> 
> -Bill
> 
> 
> On Wed, May 9, 2018 at 2:57 PM Peter Saint-Andre <[e-mail]>
> wrote:
> 
>> NEW
> 
>> 3.3.3.  Enforcement
> 
>>     An entity that performs enforcement according to this profile MUST
>>     apply the following rules specified in Section 3.3.1 in the order
>>     shown:
> 
>>     1.  Width Mapping Rule
> 
>>     2.  Case Mapping Rule
> 
>>     3.  Normalization Rule
> 
>>     4.  Directionality Rule
> 
>>     After all of the foregoing rules have been enforced, the entity MUST
>>     ensure that the username is not zero bytes in length (this is done
>>     after enforcing the rules to prevent applications from mistakenly
>>     omitting a username entirely, because when internationalized strings
>>     are accepted, a non-empty sequence of characters can result in a
>>     zero-length username after canonicalization).
> 
> The output string still needs to be validated by the base "IdentifierClass"
> before it can be said to conform to the UsernameCaseMapped profile.
> 
> INSERT:
> 
>      Finally, the entity MUST ensure that the username consists only of
> Unicode code points that are explicitly allowed by the PRECIS
> IdentifierClass defined in Section 4.2 of [RFC8264].

Yes indeed.

>>     The result of the foregoing operations is an output string that
>>     conforms to the UsernameCaseMapped profile.
> 
> 
> In RFC 8265, the opening sentence of section "3.3.2 Preparation" implies
> preparation is done before enforcement. 

Right - I'm proposing that we remove that text by explicitly specifiying
for each operation what the steps are (and not saying that they are
additive, i.e., stop saying that enforcement is the steps defined in
preparation plus some other steps).

> This can lead to confusion:
> 
> OLD:
> 
>     An entity that prepares an input string for subsequent enforcement
>     according to this profile MUST proceed as follows (applying the steps
>     in the order shown).
> 
> PROPOSED:
> 
>     An entity that performs preparation according to this profile MUST apply
> the following steps in the order shown.

Ah, I see what you mean. Yes, that's better.

> (I am wary of the separate preparation step as something that an
> application developer might use. The notion mentioned in RFC 8264 (section
> 3) that a client might use the "preparation" step before handing the
> protocol string to an authoritative server which does the "enforcement"
> step is problematic for the Username profiles. It has been shown that
> preparation by itself can reject strings that enforcement would have
> accepted.  Example: '\u212b' under the UsernameCasePreserved profile.)
> 

The original idea was that some resource-constrained entities might not
have the capacity to do things like Unicode normalization, in part
because they might not have the storage capacity to hold the Unicode
tables and in part because they might lack the computing resources to
perform normalization operations (back then we were thinking of things
like in-browser messaging clients, but these days we might think of
things like IoT devices). As a result, we were thinking that such
entities might simply restrict themselves to a safe subset of code
points (not necessarily just the ASCII range) and consider that "good
enough". Naturally, other steps might be needed depending on the string
class or profile (e.g., the width mapping rule for usernames).

Peter