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