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

Peter Saint-Andre <stpeter@stpeter.im> Wed, 04 May 2016 21:31 UTC

To: Christian Schudt <christian.schudt@gmx.de>, precis@ietf.org
References: <3A5E5283-7BCC-41DA-A183-6872695D91DC@gmx.de>
From: Peter Saint-Andre <stpeter@stpeter.im>
Message-ID: <572A6A4C.8080102@stpeter.im>
Date: Wed, 04 May 2016 15:31:56 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <3A5E5283-7BCC-41DA-A183-6872695D91DC@gmx.de>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/precis/hYbbwkxSUDzbNtGPNsVCP4jyJ_s>
Subject: Re: [precis] U+212B (ANGSTROM SIGN) in Usernames
Precedence: list

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] U+212B (ANGSTROM SIGN) in Usernames Christian Schudt
Re: [precis] U+212B (ANGSTROM SIGN) in Usernames Christian Schudt
Re: [precis] U+212B (ANGSTROM SIGN) in Usernames Peter Saint-Andre