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

Christian Schudt <christian.schudt@gmx.de> Sat, 21 November 2015 13:12 UTC

Return-Path: <christian.schudt@gmx.de>
X-Original-To: precis@ietfa.amsl.com
Delivered-To: precis@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A041D1A9031 for <precis@ietfa.amsl.com>; Sat, 21 Nov 2015 05:12:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPAukRguRxdv for <precis@ietfa.amsl.com>; Sat, 21 Nov 2015 05:12:42 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5C2A1A9035 for <precis@ietf.org>; Sat, 21 Nov 2015 05:12:41 -0800 (PST)
Received: from christihudtsmbp.fritz.box ([77.0.27.29]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LpKKr-1aWRus3Psr-00fB2t for <precis@ietf.org>; Sat, 21 Nov 2015 14:12:39 +0100
From: Christian Schudt <christian.schudt@gmx.de>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <3A5E5283-7BCC-41DA-A183-6872695D91DC@gmx.de>
Date: Sat, 21 Nov 2015 14:12:38 +0100
To: precis@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
X-Mailer: Apple Mail (2.3096.5)
X-Provags-ID: V03:K0:YZND4FwTElHtwZy1Fc9irTwDT8t2xUdy0zOXzLtpIOJF4qc8ftK n5QS3uP2o7JMuhxpMSqTyw4KkRt4+7MMd/k9z1hsCi+t/Y+tLwS2C0WfiXJ9bmtnkfF7DK9 jF0kGHpZRmq6BKaw9MZwzDAPAOOQDezShuIX5UwRjeW77jB3b9E+3dirT13/yMHeSU7s5Ca vCHDYcim6SiTHXBWC4OAA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:koD5G+YTbI4=:HXsiZKWVJIodK8Q4E9CkBA o0FEJB9+/lrRdILEgiqNh7T1lWxom3qmceAOWa8e3jfzSAGIDO127jQ9yv4Vf68lHrY9aGJ0a SAFCCrn9NdFNAPtxyq9FX9/3+azCZ2pnkBQ2nu3t7AGcAeEnFGRYHz5Nf4B/AE8LyCLQtesc4 KOXJqrYm+eEtMofcGEO0T2whRhP0BM+cIYVBmZRpXogQFNw0N12aFsg71RTWTkEOvl/SGA2OJ Xz/LWZUqHuB9MxR81rYvKyoDCQoriNyWI1Y7T4q256LnHLWsob8pZO7SH9bzRwOfFcMENas+/ kBSUUfJs04qbiQJN2SQFsutW8VZaaSyO7ddICWcp90fEAMqQb+T0Rm/v8w/Zjgsdhuk5TwWFU HZgmgpc3oNZx+Xd97Ou672D5nXx0mAsiXcABVEpwWyGtIGI925xJ+omUo2/niCGXvtLePONRC Ci/rr6SNf/L3UIocE7naKoq9y8EW6RtCoaUeiFRZUY0fuQOUMqWlpXWso6I8S3+bLZsrUoaUF FCG30GsUTvOSvSf0kHKXrOlgQ45Y7y1x13Ksdj/s2ZU9WelpnbO3U9qvvqjSVE3+OLQOp4xm7 bnXYl5qofu17w/PQvjaIDVVhKolKCm177a2a0tAHiuW+Bdtg5T5xv5Db//rQrgQR02CZ4vBWj bj7AZA1r72fru/SK2vpgel1+6kKIa7Qw3v4IFGsE2+nzuqn5yyU4bnP6kL15qqrZN4Qq5Yt15 BfSDrNqf8LemqGqzQy3yZbUG7/By2jg+XthXzC05E6ciKDN+h1jnXEt/tgsXGa0A7TXX/TcHN ROiILpg
Archived-At: <http://mailarchive.ietf.org/arch/msg/precis/lj1MGM1nqtHvQOSe8vXveo2UdiY>
Subject: [precis] U+212B (ANGSTROM SIGN) in Usernames
X-BeenThere: precis@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Preparation and Comparison of Internationalized Strings <precis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/precis>, <mailto:precis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/precis/>
List-Post: <mailto:precis@ietf.org>
List-Help: <mailto:precis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/precis>, <mailto:precis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Nov 2015 13:12:43 -0000

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