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

Christian Schudt <christian.schudt@gmx.de> Wed, 09 December 2015 18:36 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 0BEB71B2CE6 for <precis@ietfa.amsl.com>; Wed, 9 Dec 2015 10:36:58 -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 5rvvqqu0DX-g for <precis@ietfa.amsl.com>; Wed, 9 Dec 2015 10:36:56 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 26E2F1B2CDF for <precis@ietf.org>; Wed, 9 Dec 2015 10:36:55 -0800 (PST)
Received: from christihudtsmbp.fritz.box ([95.117.223.250]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MQzoI-1ZfgoV2mVy-00UKxd for <precis@ietf.org>; Wed, 09 Dec 2015 19:36:53 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Christian Schudt <christian.schudt@gmx.de>
In-Reply-To: <3A5E5283-7BCC-41DA-A183-6872695D91DC@gmx.de>
Date: Wed, 9 Dec 2015 19:36:52 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <02D6F037-4B2D-487F-88CA-72C7D8F7CA7B@gmx.de>
References: <3A5E5283-7BCC-41DA-A183-6872695D91DC@gmx.de>
To: precis@ietf.org
X-Mailer: Apple Mail (2.3096.5)
X-Provags-ID: V03:K0:33Z9JpLE75050Qi6Ph/Ph1+0tnh4RjkLFbq3AgiAO2bXkzf+Rkz gA+NCbC7jGo9GhsUsV8kl3I+rJTNw8oAUE1+P+ZstSC9nRmdY1ah5IgtJX+5YmH59D1kFCS xAWWENcOFN6bkMBWhR5A/hh8r6/QDN4x/jFeVbu9RtOYtkHLgzsBD6I7YzX6N1XRApjmr3C irXbCKvORx43Gemf3rh3Q==
X-UI-Out-Filterresults: notjunk:1;V01:K0:uGBfircsT4U=:iqZyNZn8/DBE1cXmmlfXq1 Kj/KJph/eH+AJfPuojstD/jkULqXlKQEG49mdvlKpmhgqfkXkOoBzm6x0I0V9MbfB8DgaCWSv kpOpJmNLfKOvj1tv3ofbdV1x7i4EE0cWOS3S/hF+jJSrfBpdw9/+q/RshIUoa53499dCAMdQx TkHi72gmD9LULDJPqeQ8VZhDOiN3rH9jH70I2S32THxGDOeMLwyp7dgKhHAJSyQSunywr7lQe bF2gjBTYJxd9r4wXfODxMQWcc//bf0+XDVgaeWEoQHJOFW+qVGgNakQEF71E0dD8rGpKYe/Go w4Y20hJS62zWmNC5gL35z7dgGQZgI6CCE+49seT6PYECEUM3+XArTxL4NA4C8Wbu0TLq1k7EG xTTPznRYVm0v7C2nlo6SVdTsGbGsw00EpQypyF1y7BF/gb3ACg20zd3nU0Hw69BGpFuKqFLeC 2iu98GPph4NsR9OaRDe9YK9PYaOVNnfHWO2qpTEwW1g+zlsHXVzINk1nIFqy7zlp5WCkuw4MZ 7Xl66c7bF3/VefbYw83bHDyHPmilL/e81BLoG/aDJozzVyRarjIOwJ2Kkv6EoeVvGBw29yog4 EPUQ5Hoo2YA2f/UCb00EPWlOLgVjypd+Y7f+d9D1arie2hyrN7s139bLRnZPsePuOaOCA5M7o 8Z+QXKPXGcQn0OsNHT1wdaMjwl4nxniV3h4BW/tuojOK9UHpRroiP7dYvPsk17j0xwlm/ciV3 z73Q1UQo84hd3veIxwqIF2ggRxdiNbPQudGPi79utPgMmJvdnoRZvZy7jZ60UW1RHEa8uvnzN q1Bmonc
Archived-At: <http://mailarchive.ietf.org/arch/msg/precis/vZitbRC9OyNedbupEN5OaW9R7IM>
Subject: Re: [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: Wed, 09 Dec 2015 18:36:58 -0000

Anybody has a clue about this? Thanks.


> Am 21.11.2015 um 14:12 schrieb Christian Schudt <christian.schudt@gmx.de>de>:
> 
> 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