[precis] order of operations (was: Re: Milestones changed for precis WG)

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

Return-Path: <stpeter@stpeter.im>
X-Original-To: precis@ietfa.amsl.com
Delivered-To: precis@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 56B2112D857 for <precis@ietfa.amsl.com>; Wed, 4 May 2016 13:47:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.898
X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id GlT5hsMB_c7d for <precis@ietfa.amsl.com>; Wed, 4 May 2016 13:47:01 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im []) by ietfa.amsl.com (Postfix) with ESMTP id E059712D85F for <precis@ietf.org>; Wed, 4 May 2016 13:46:48 -0700 (PDT)
Received: from aither.local (unknown []) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D42C440016; Wed, 4 May 2016 14:56:26 -0600 (MDT)
To: Christian Schudt <christian.schudt@gmx.de>, Marc Blanchet <marc.blanchet@viagenie.ca>
References: <20160301221928.17792.35793.idtracker@ietfa.amsl.com> <1C1668EA-1734-4D90-82E6-3894ECB6407C@viagenie.ca> <56D61E27.40000@stpeter.im> <56F96A20.7030509@stpeter.im> <E5D59850-BE7B-4AB9-863F-E883DA9C4E13@viagenie.ca> <CECC45A3-B52F-489A-B64E-8D9B8DCDBD47@gmx.de>
From: Peter Saint-Andre <stpeter@stpeter.im>
Message-ID: <572A5FB7.9000305@stpeter.im>
Date: Wed, 4 May 2016 14:46:47 -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: <CECC45A3-B52F-489A-B64E-8D9B8DCDBD47@gmx.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/precis/OGoy0aKoMwdmKNL6HBaWj6QXlSY>
Cc: precis@ietf.org
Subject: [precis] order of operations (was: Re: Milestones changed for precis WG)
X-BeenThere: precis@ietf.org
X-Mailman-Version: 2.1.17
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, 04 May 2016 20:47:03 -0000

On 3/28/16 1:58 PM, Christian Schudt wrote:
> Hi,
> let me raise one concern, which I had while implementing RFC 7564 and
> 7613. I’ve raised it already on this mailing list, but it got no
> attention.

Sorry about that. Attention cycles come and go. Now that I'm working on 
the bis drafts, I for one will make it a point to reply more quickly.

> Instead of changing RFC 7564 §7 from MUST to SHOULD, why not changing
> RFC 7613 §3.2.2 (and likely other Enforcement sections) to stick to
> the order of rules?

Now that I look at RFC 7613 again more closely, I would say that it 
doesn't really violate the order of operations in §7 of RFC 7564, 
because for purposes of comparison it still applies the width-mapping 
rule before all the other rules. However, it's also true that RFC 7613 
applies the width-mapping rule before the "preparation" (or, perhaps 
better, "pre-processing") steps of (a) ensuring that the string consists 
only of Unicode code points that conform to the PRECIS IdentifierClass 
and (b) encoding the string as UTF-8. That doesn't violate the letter of 
RFC 7564 but perhaps it's confusing for implementers.

Note that the purpose of the order of operations is "to ensure proper 
comparison"; I'm not convinced that what happens during preparation or 
pre-processing needs to follow the same order of operations.

There's also the question of whether preparation / pre-processing is all 
that useful. We added it so that constrained clients (e.g., clients that 
can't realistically perform normalization) could avoid most of the 
problems associated with having their strings rejected by a more 
powerful server that actually does enforcement and comparison. Whether 
we really need to consider such applications is another story.

> For me as an implementer it simply felt more clean and
> straightforward, e.g. when I faced this issue:
> It’s still unclear what to do with U+212B (ANGSTROM SIGN) in
> Usernames.

For better thread tracking, I'll reply separately to your original message.