Re: [precis] Enforcement as an Idempotent operation

Sam Whited <> Wed, 19 April 2017 15:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7B005129B04 for <>; Wed, 19 Apr 2017 08:35:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1azGgE7DYKiy for <>; Wed, 19 Apr 2017 08:35:56 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D7225129B02 for <>; Wed, 19 Apr 2017 08:35:55 -0700 (PDT)
Received: by with SMTP id j9so13046117ywj.3 for <>; Wed, 19 Apr 2017 08:35:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=swgoo; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bzOI5yTTmGtByBZGyWyv48O+C8txtBUacW01Oi5FXk8=; b=yOlGO/MSdLWEsTOWVIiCNU+tVePIPWsc8RPi5fOR+4ahSyluh0J8SVbRb1Q4NOZzff kxDpW7SXBMCQxokFzjfL7JijG8d8+uDrFJcg2pfhhvw1uHybOi0IZU804ArHkJo+0YGP olMFjA9myJDCE5+4A+SJctEOFNUxmrZ8/RITE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bzOI5yTTmGtByBZGyWyv48O+C8txtBUacW01Oi5FXk8=; b=iVVmBeLjkQz9pRwzoP+Ecp6t+dAVHAei4/BmR2QVoR4s1YZubp4xcBWaaf9lLFF403 neZUPKi5NZJmzLmLnhbTEVmOWt1rNo/MNKhP4GRHa+EBPKJ5iqUkZ1q+7clrYsXIBiG+ OmDSiFuiwBYm/9sVw7r7IgqxQ6JdphpBCVN2HMOIWhC1MNhXgJKDxl7HlIAzaOgXoESM NHY1WnkAblmHvUGJldlOZ9XCV5ckKOjYsCvTYCxOOYaI8ZmmlFHVLFqNSJT/G6bvvo9+ 965w5MCttStTRXbI9qQA2zqzrvU4OE0/F9rH9V4YT8l/bfYPDmubwv/3sIXkgMgmRMT4 pQPA==
X-Gm-Message-State: AN3rC/6ikPWGtdXaZc6qWLzHCl9/us7u2kmSWNWcmkU/STCxAv0QU2Ia z915YBTsrQxGxtu2Uwn7UX3VNvjsxA==
X-Received: by with SMTP id q3mr2511146ywc.38.1492616155031; Wed, 19 Apr 2017 08:35:55 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 19 Apr 2017 08:35:14 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <> <>
From: Sam Whited <>
Date: Wed, 19 Apr 2017 10:35:14 -0500
Message-ID: <>
To: Peter Saint-Andre <>
Cc: William Fisher <>,
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Subject: Re: [precis] Enforcement as an Idempotent operation
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Preparation and Comparison of Internationalized Strings <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Apr 2017 15:35:57 -0000

On Tue, Mar 21, 2017 at 8:30 PM, Peter Saint-Andre <> wrote:
> Thinking about this further, I now lean against making this change in
> the PRECIS processing rules, for several reasons:

Sorry for dragging this back up again, but I ran into this for the
first time "in the real world" recently (a comprison using the
nickname profile that was unexpectedly failing in a non-obvious way)
and wanted to weigh in:

With the nickname profile in particular this might not be that big of
a deal, but other as-yet-unthought-of future security focused profiles
may need to use NFKC for some handwavey reason (although if they are
security focused they probaly shouldn't be using NFKC, but let's
assume that they have too), but may need to be idempotent for security
reasons. It is currently not possible (as far as I can tell) to create
a profile that both uses NFKC, and is idempotent. I know we don't want
to encourage profile proliferation, but I suspect at some point
someone will have a valid reason to write a new profile, so future
proofing would be nice.

Maybe it would be beneficial to add a new step to the PRECIS framework
(with the understanding that current profiles just don't have this
step, making them backwards compatible), a "finalization mapping"
step: this could be used to eg. run the additional mapping rule a
second time, run normalization again, or just perform specific known
mappings that fix edge cases. I'm not sure how generally useful it
would be, or if it would just be a huge change for relatively little
benefit (or maybe it would even be an actively bad thing somehow?);
just a thought.