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

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

On 5/4/18 12:40 PM, Peter Saint-Andre wrote:
> On 3/14/18 10:04 AM, Paul Crovella wrote:
>> Followup question on
>> https://www.ietf.org/mail-archive/web/precis/current/msg01445.html
>>
>>> implementations should follow the order of rules in Section 7 of RFC 8264.
>>
>> Should string class validation then be moved from the preparation step
>> of all profiles to the end of enforcement? I don't know whether
>> there'd be a practical effect on profiles using the FreeformClass
>> string class (OpaqueString and RFC 8266's Nickname), or if there's the
>> potential to be, but it'd be nice to know where to do things.
> 
> The intent in my head when working on RFC 8265 & RFC 8266 was to define
> the set of rules for a profile and then in each subsection (preparation,
> enforcement, comparison) specify each rule to be applied for that
> operation, without having them be additive (i.e., don't say in the
> enforcement operation than you first do everything in preparation, then
> some things in addition). Clearly, this did *not* get translated into
> the final text because I failed in my responsibility as a spec author.
> 
> I will send proposed text for errata to this list sometime soon.

I have in mind something like the following for Section 3.3 of RFC 8265.

###

OLD

3.3.3.  Enforcement

   An entity that performs enforcement according to this profile MUST
   prepare an input string as described in Section 3.3.2 and MUST also
   apply the following rules specified in Section 3.3.1 in the order
   shown:

   1.  Case Mapping Rule

   2.  Normalization Rule

   3.  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 result of the foregoing operations is an output string that
   conforms to the UsernameCaseMapped profile.  Until an implementation
   produces such an output string, it MUST NOT treat the string as
   conforming (in particular, it MUST NOT assume that an input string is
   conforming before the enforcement operation has been completed).

3.3.4.  Comparison

   An entity that performs comparison of two strings according to this
   profile MUST prepare each string as specified in Section 3.3.2 and
   then MUST enforce the rules specified in Section 3.3.3.  The two
   strings are to be considered equivalent if and only if they are an
   exact octet-for-octet match (sometimes called "bit-string identity").

   Until an implementation determines whether two strings are to be
   considered equivalent, it MUST NOT treat them as equivalent (in
   particular, it MUST NOT assume that two input strings are equivalent
   before the comparison operation has been completed).

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 result of the foregoing operations is an output string that
   conforms to the UsernameCaseMapped profile.  Until an implementation
   produces such an output string, it MUST NOT treat the string as
   conforming (in particular, it MUST NOT assume that an input string is
   conforming before the enforcement operation has been completed).

3.3.4.  Comparison

   An entity that performs comparison of two strings 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

   The two strings are to be considered equivalent if and only if they
   are an exact octet-for-octet match (sometimes called "bit-string
   identity").

   Until an implementation determines whether two strings are to be
   considered equivalent, it MUST NOT treat them as equivalent (in
   particular, it MUST NOT assume that two input strings are equivalent
   before the comparison operation has been completed).

###

Would this clarify string handling enough to be useful?

/psa