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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
