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

From: Christian Schudt <[email-masked]>
Date: Tue, 5 Dec 2017 00:06:06 +0100

Hi all,

now that the new RFC 8264 / 8265 are out, I wanted to update my implementation, which was based on the older RFCs.

Unfortunately the order of rules still confuses me.

During enforcement and comparison of a string, do I first validate a string, then apply the rules (as written in https://tools.ietf.org/html/rfc8265#section-3.3.4),
or do I first apply the rules and then validate it? (as in https://tools.ietf.org/html/rfc8264#section-7)

With "validate" I mean checking the "Behavioral rules for determining whether a code point is valid, allowed under a contextual rule, disallowed, or unassigned“.

The Appendix says:
"Corrected the order of operations for the UsernameCaseMapped profile to ensure consistency with [RFC8264].“
but I just can’t see that:
"MUST prepare then MUST enforce"

Concrete example (I asked it here already):

If a user wishes to create a username with U+212B (Angstrom sign), should an application reject it (because it’s disallowed) or allow it, because enforcement converts the character to a valid code point first?

Thanks!
Kind regards,
— Christian

---

From: William Fisher <[email-masked]>
Date: Mon, 4 Dec 2017 20:58:24 -0700

> If a user wishes to create a username with U+212B (Angstrom sign), should an application reject it (because it’s disallowed) or allow it, because enforcement converts the character to a valid code…

I implemented enforcement based on the rules in RFC 8264 section 7.
The behavioral rules (IdentifierClass) are applied last.

>>> from precis_i18n import get_profile
>>> ic = get_profile('IdentifierClass')
>>> ic.enforce('\u212b')
Traceback (most recent call last):
 ...
UnicodeEncodeError: 'IdentifierClass' codec can't encode character
'\u212b' in position 0: DISALLOWED/has_compat
>>> un = get_profile('UsernameCasePreserved')
>>> un.enforce('\u212b')
'Å'

See also:
  https://www.ietf.org/mail-archive/web/precis/current/msg01225.html

You're right that the references to preparation in RFC 8265 (sections
3.3.2, 3.4.2) are at odds with RFC 8264 and the mailing list.

-Bill

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 6 Dec 2017 15:07:39 -0700

> 3.3.2, 3.4.2) are at odds with RFC 8264 and the mailing list.

Sigh.

I'm sorry that we failed to make things clear and consistent.

I agree with Bill that implementations should follow the order of rules
in Section 7 of RFC 8264.

Let me think about how we can clarify things. That might involve filing
an erratum against RFC 8265.

Peter

---

From: Christian Schudt <[email-masked]>
Date: Sat, 9 Dec 2017 12:39:55 +0100

> an erratum against RFC 8265.

Ok, thanks for clarifying it (again). My implementation will keep on following the rules in 8264 then.

— Christian