[precis] RFC 8264 / 8265 Order of rules

Christian Schudt <christian.schudt@gmx.de> Mon, 04 December 2017 23:06 UTC

Return-Path: <christian.schudt@gmx.de>
X-Original-To: precis@ietfa.amsl.com
Delivered-To: precis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A250128D69 for <precis@ietfa.amsl.com>; Mon, 4 Dec 2017 15:06:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 pCz1KPJSK2YI for <precis@ietfa.amsl.com>; Mon, 4 Dec 2017 15:06:10 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C119128D64 for <precis@ietf.org>; Mon, 4 Dec 2017 15:06:09 -0800 (PST)
Received: from christihudtsmbp.fritz.box ([88.77.154.196]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MC4R6-1eDENz2jtg-008sRd for <precis@ietf.org>; Tue, 05 Dec 2017 00:06:07 +0100
From: Christian Schudt <christian.schudt@gmx.de>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <0207F020-32D2-4181-A020-3143BD8E88FE@gmx.de>
Date: Tue, 05 Dec 2017 00:06:06 +0100
To: precis@ietf.org
X-Mailer: Apple Mail (2.3273)
X-Provags-ID: V03:K0:1wBLZ28tEMb1r4bxsBRVj+ME0z4ZNl7jlTcHMwL6sfEfpL5BrG5 s5B7aoImqaTgPoZEfVHmVXi26/79DcqlxRLtp0XqMdtUo1U/sj1GrEUmeKGGFNiSUTc7WMO OmT6753nrx7dc+aq6bLOCQHq9Bz2qMjNgAmyINn8PkOdRs0NgMG0mE4B0Qj+TlA/6fmgfh+ 33jCzqccZrq6OloF1bKRQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:L0ScTfCVKRM=:ge1Vm6JMelSycfLsNQCP2A OhmVBnzLmbl14E3MsvxF8t8XP5xiddUm87W7S4+/K/XoOq958fyB1Ajoi5G6lx7Rhm8b3zBsm Hcvz5b+qP7EWWljxRPPx0CSPvE8dh9asdGraZPc+Hy6QCbzUIkZ4ebqhHfzNPKaT5DqL5+OiY sqkLdzfMF9lzVbebGyGdbAATx+QqpxFmXD0FWQlbzm5rDpkinIYiA6ZaadMJZDNEhR4P8y+rt gp6sWaXATivsze8DrYiPJoGgZu5ioJFiAfOQ0cjY7o6X2xb/XmAGQbS4bbyc0WCCTPAq+KInk g6NkQI5KE7SSFHd//QCvSaoVrc+kJesJY6HnBBE4cDoVXqjYRYTtWDrs/op/TDhYYP11OT4Ht C/suxJpS61DkAE9opwX6WPZRRwJqPjEQyVdSufbrXKagj2hofsnnG+NWIQb211o7/4pIYHfjF pu+E6Bf4aCExUdwab7HjIpQcpP/stn/bJ+8jEShdU1vZloeKG94hEjtYu82ggBz/3B2z0BA+6 NktIPmrq7QjkJTsLUtJASKjsHDmfWViocjQWs7xQWexbB550+n7MqNcXPPtekpfbGenqhoTOQ w6ejBRdwUcIGzHYCbfMNqKaooaUmsLOWl9Fd23T9OjR4lBoPB/T1rEUQm7UKFAp/ag7ogSlnn B6/PN5D26PDgHKwor9IL1MJ3Mv2IuI8yJf8vgzXwBAP0Y0skv4L6Ri/j8LnKJ3DQEL8OJEAyC C33VXueZfNPulGsA3MPQBtofc70KW2DBhD24wnh68tRfsYq/c8OVvw4LCILlDFZda8jDLptWM P61bOTrd1FcHdVosRKt7ECTvnFiqnxbKhMl5QYQ2iDXwiqqKLAsEwAiYW1HXo4Q9NSrbFVp
Archived-At: <https://mailarchive.ietf.org/arch/msg/precis/ziJaH-_vOE0XS_VYey4B_VcfTi4>
Subject: [precis] RFC 8264 / 8265 Order of rules
X-BeenThere: precis@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 04 Dec 2017 23:06:12 -0000

Hi all,

now that the new RFC 8264 / 8265 are out, I wanted to update my implementation, which was based on the older RFCs.

Unfortunately the order of rules still confuses me.

During enforcement and comparison of a string, do I first validate a string, then apply the rules (as written in https://tools.ietf.org/html/rfc8265#section-3.3.4),
or do I first apply the rules and then validate it? (as in https://tools.ietf.org/html/rfc8264#section-7)

With "validate" I mean checking the "Behavioral rules for determining whether a code point is valid, allowed under a contextual rule, disallowed, or unassigned“.

The Appendix says:
"Corrected the order of operations for the UsernameCaseMapped profile to ensure consistency with [RFC8264].“
but I just can’t see that:
"MUST prepare then MUST enforce"


Concrete example (I asked it here already):

If a user wishes to create a username with U+212B (Angstrom sign), should an application reject it (because it’s disallowed) or allow it, because enforcement converts the character to a valid code point first?

Thanks!
Kind regards,
— Christian