Anybody has a clue about this? Thanks.
> Am 21.11.2015 um 14:12 schrieb Christian Schudt <[email protected]>: > > 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
