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

[William Fisher <[e-mail]>]

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

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

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