Subject: [precis] U+212B (ANGSTROM SIGN) in Usernames

From: Christian Schudt <[email-masked]>
Date: Sat, 21 Nov 2015 14:12:38 +0100

Hi,

can you please help answering the following question:

When doing enforcement of a string of the UsernameCaseMappedProfile as per RFC 7613 § 3.2.2 and the string contains U+212B (ANGSTROM SIGN), I would first do the preparation and it would be disallowed by the IdentifierClass because it has a compatibility equivalent (which is U+00C5 LATIN CAPITAL LETTER A WITH RING ABOVE).

However, if I stick to the order rules specified in the Precis Core Framework (RFC 7564 § 7), the string would first be normalized with NFC (RFC 7613 § 4.2.2.4), becoming U+00C5, and then later would pass the IdentifierClass check.

If I stick to the rules in RFC 7613 § 3.2.2, such a string would be disallowed.
If I stick to the rules in RFC 7564 § 7, it would be allowed.

What’s correct behavior?

Preparation (RFC 7613 § 3.2.1) has introduced a workaround for the HasCompat issue, but only for full- and halfwidth characters (which U+212B is not).

Generally I don’t understand why RFC 7613 violates the order of rules (compared to RFC 7564 § 7): Doing the preparation (checking the IdentifierClass) first as opposed to do it after the normalization.

Thanks for your help and comments,
— Christian