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