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

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 4 May 2016 15:31:56 -0600

Hi Christian, thanks for your input. Please accept my apologies for the 
seriously delayed reply.

On 11/21/15 6:12 AM, Christian Schudt wrote:
> 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.

As hinted in the message I just sent to the PRECIS list, I think that 
using the order of operations specified in RFC 7564 is the right thing 
to do during enforcement and comparison because (a) the IdentifierClass 
is supposed to be a "safe" choice for things like usernames and (b) we 
don't want to willfully violate the "Principle of Least Astonishment" 
(U+212B looks and behaves like U+00C5 and in fact is canoniclaly 
equivalent to U+00C5).

Thus my inclination is to treat this as a spec bug in RFC 7613, by which 
I mean that for enforcement and comparison in 7613bis we would follow 
the order of operations specified in RFC 7564; this would imply that 
U+212B would be mapped to U+00C5 (which was also the result of applying 
SASLprep in accordance with RFC 4013).

Or so it seems to me.

Peter