From nobody Sun Apr 16 20:41:00 2017 Return-Path: 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 766F1127A97 for ; Sun, 16 Apr 2017 20:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=ejyjZNgf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JlWsMMsi 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 Ft5-DIJRZiDp for ; Sun, 16 Apr 2017 20:40:57 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6BAD1273E2 for ; Sun, 16 Apr 2017 20:40:56 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id C215F20702; Sun, 16 Apr 2017 23:40:55 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Sun, 16 Apr 2017 23:40:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=7ScIwMV/nD6S0fBOpk FRxXmVWQ4dImzu4XeNGi6z+w0=; b=ejyjZNgfozYvaWKDMXPIloLS5owyUpB21E roXAO/x1ndYF4f5FBf5DuDai/qxVUobsV0syK/Rzd+mAKBHeW4HXmiZEgoSI6TIS wthFCSbiaegXSKKk1teynWTjJniX6H8nvq5jUPiy8Ed4/NYJqMZw3pjeP0z5UBlg /jXC05xbYasTgwmGRM88NVnMN4fuFqxmAsgj8qPDpKB3HE1322NTdVhRuVG5Eoir MUxiGxmGiM7mdxCW5JYHG66bLlkhbl89ephv4SkwpbXotP5bNSl8Qg+82rshM+kl lKQJ3o8Bns7vdb3P/dh8c38edRwf+v/Ln7iX0slC2kCpkY96tl+w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=7ScIwMV/nD6S0fBOpkFRxXmVWQ4dImzu4XeNGi6z+w0=; b=JlWsMMsi oFcPIJYbpSk/OOym+2t4lBE5b0yZlH2j1+xnkLYfWG8v+oI0piOqr9H5ZJIL8ECd vFKF6bpp0NP3eF9BqgYJ0fhT18CxSi8c1Zb2sAqcazCA1V0UKciKr8uPqbOsiitO wLYjdc2V1ztoSsEdr2HIi3X0VmgQCPsvKV1FXLpQsFKQUJ5OzD2JXHrOxgMftuGN rFlSxUNsW0D2VpGxPZwnGeFBKwxm9FZ8APDlnRyCYlXr5CdFHnnpGhZ6MsdkW4fA Nydy8KN95G5XixcE/YeO2THeu8v6+x4nPv2SCz+ILFarjNpUhd3lMrDhdGBkep5x kqB38XzKDopbgg== X-ME-Sender: X-Sasl-enc: tB2gvsRhgusmBoI76mNK6uGy9u6cktmEnPB2lqA6n29G 1492400455 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 207972469D; Sun, 16 Apr 2017 23:40:55 -0400 (EDT) To: Nikos Mavrogiannopoulos , precis@ietf.org References: <1490885635.10364.10.camel@redhat.com> <5d02a0bc-5f53-a9fe-33fe-be0c66de24ee@stpeter.im> <1490948974.24162.5.camel@redhat.com> From: Peter Saint-Andre Message-ID: Date: Sun, 16 Apr 2017 21:40:54 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1490948974.24162.5.camel@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [precis] rationale of rfc7613 decisions X-BeenThere: precis@ietf.org 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: Mon, 17 Apr 2017 03:40:58 -0000 Hi Nikos, I haven't forgotten about your message and will reply at greater length this week. Peter On 3/31/17 2:29 AM, Nikos Mavrogiannopoulos wrote: > On Thu, 2017-03-30 at 19:45 -0600, Peter Saint-Andre wrote: > >>> I'm checking both rfc7564 and rfc7613, and I cannot find the >>> rationale >>> of the restrictions being done. In particular: >>> 1. why rfc7613 restricts all spaces for passwords to U+0020? >> >> > [...] >>> 2. what is the purpose of "Contextual Rule Required" in section >>> 4.3.2 >>> of rfc7564? >> >> It's complicated, but in essence PRECIS is consistent with IDNA2008 >> here >> (see RFC 5891, RFC 5892, and RFC 5894). In particular, the code >> points >> ZERO WIDTH JOINER (U+200D) and ZERO WIDTH NON-JOINER (U+200C) are >> necessary to produce certain combinatiosn of characters in certain >> scripts (e.g., Arabic, Persian, and Indic scripts) but if used in >> other >> contexts can have consequences that violate the principle of least >> user astonishment. > > I think that such issues should warrant extensive discussions in an RFC > like 7613. It is not apparent for me for example why that principle > should apply for passwords (which are not visible). I guess there are > arguments for that, but should be presented in order to understand and > be able to convince people that RFC7613 is the way to go. > >> 3. why freeform class doesn't allow "Old Hangul Jamo characters"? >> As explained in §2.9 of RFC 5892: >> >> Elimination of conjoining Hangul Jamo from the set of PVALID >> characters results in restricting the set of Korean PVALID >> characters >> just to preformed, modern Hangul syllable characters. >> Here again PRECIS is consistent with IDNA2008. > > As I am mostly restricted in the context of passwords, my question is > mostly on why is this done for the passwords. E.g., Is it because the > Hangual Jamo set is a deprecated set which may not be in use years from > now or another reason? > >>> 4. why freeform class doesn't allow ignorable charaters? >> >> These are things like soft hyphen, certain joiners, specialized code >> points for use within Unicode itself (e.g., language tags and >> variation >> selectors), and so on. They were disallowed in RFC 4013 and are >> disallowed in IDNA2008, too. >> >> By saying "PRECIS is consistent with IDNA2008" I'm not appealing to >> authority or saying that a consistency is necessarily a good thing. >> Instead, defining as few string handling methods as possible helps >> users >> because strings aren't handled differently in different protocols and >> contexts (see §5.1 of RFC 7564). This has security implications, too, >> because the more such methods exist the easier it will be for >> attackers to trick users. > > In the context of 'passwords', I see very little applicability of such > attacks, though I may be wrong. The main concern I see for passwords > used for storage is compatibility, e.g., even with legacy software > which did not follow these rules, and simplicity, so that software can > follow the rules under reasonable for the task effort (I find the > effort RFC7613 requires for processing UTF-8 passwords unproportionaly > complex to the effort needed for US-ASCII passwords). > >>> The context of that, is that I am trying to understand what would >>> be >>> the drawbacks from recommending a fixed normalization form (e.g., >>> NFC), >>> for passwords, in contrast to recommending rfc7613. >> >> Nikos, instead of asking us why the foregoing restrictions were made, >> ask yourself why you would want to ignore them and whether you >> understand internationalization well enough to independently craft >> appropriate rules and guidelines for the RFC you're updating. Because >> you actively work on security technologies, think of it this way: >> would >> you want someone who doesn't understand all the issues to "just use >> TLS" >> without specifying appropriate cipher suites (ignoring RFC 7525) or >> certificate checking procedures (ignoring RFC 5280 and RFC 6125)? The >> issues involved with internationalization are just as complex (albeit >> in different ways) and the whole reason we developed IDNA2008 and >> PRECIS is so that well-meaning folks like you don't shoot yourselves >> in the foot. > > I cannot disagree with that, however, providing rationale for the > decisions is important, especially in documents which are developed in > disconnect with many existing protocols/practices. The current state in > PKCS#12, PKCS#8 encrypted files, is pass there whatever you have as > long as it is UTF-8. Convincing developers to deploy thousands lines of > code for pre-processing such passwords, would require to underline the > problems of the previous practice. RFC7613 unfortunately ignores that > part completely, and I have no arguments when trying to convince people > that this should be preferred. > >> I strongly encourage you to use the PRECIS profile for passwords in >> RFC7613, and we'd be happy to help you do so in the safest ways >> possible. > > I'm trying to make a list of items which make apparent why RFC7613 is > needed. What I have now is: > > "UTF-8 however, does not imply that strings conforming to it, are > unambiguously unique, since there are can be various forms of the same > string which may look identical to an observer, although being > represented by a different byte string. Some issues are the following." > > [The NFC argument is the easier to explain] > * Various normalization forms, which result to different data for the > same input. > > [why spaces need to be merged to 0x20 is harder to sell] > * The unicode standard includes a number of space characters which > cannot be distinguished from each other, or have no width resulting to > different results when switching to a different input method > > [Hangual Jamo even harder] > * There are deprecated alphabet sets, which are no longer in use(?) > and may not be available as input methods in the future. > > [contextual rule] > * Certain combinations of code points between certain scripts produce > unexpected visible results. (the question here is why would one care > for visible results on passwords which are not printed) > > regards, > Nikos > From nobody Wed Apr 19 08:35:58 2017 Return-Path: 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 7B005129B04 for ; Wed, 19 Apr 2017 08:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=samwhited.com 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 1azGgE7DYKiy for ; Wed, 19 Apr 2017 08:35:56 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 D7225129B02 for ; Wed, 19 Apr 2017 08:35:55 -0700 (PDT) Received: by mail-yw0-x234.google.com 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; d=samwhited.com; 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; d=1e100.net; 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 10.129.117.3 with SMTP id q3mr2511146ywc.38.1492616155031; Wed, 19 Apr 2017 08:35:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.118.10 with HTTP; Wed, 19 Apr 2017 08:35:14 -0700 (PDT) X-Originating-IP: [72.48.156.244] In-Reply-To: <6df28263-cdfa-cc61-4ba9-1bdae17bcca8@stpeter.im> References: <15c31273-c278-af61-2a01-0b68ab8af182@stpeter.im> <0f5b55f8-5fcb-2a61-435e-7b93d2d8f9e6@stpeter.im> <6df28263-cdfa-cc61-4ba9-1bdae17bcca8@stpeter.im> From: Sam Whited Date: Wed, 19 Apr 2017 10:35:14 -0500 Message-ID: To: Peter Saint-Andre Cc: William Fisher , precis@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [precis] Enforcement as an Idempotent operation X-BeenThere: precis@ietf.org 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. Best, Sam From nobody Wed Apr 19 14:37:24 2017 Return-Path: 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 16AE3128B37 for ; Wed, 19 Apr 2017 14:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 szYg1eP9-iwv for ; Wed, 19 Apr 2017 14:37:21 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 5820F128799 for ; Wed, 19 Apr 2017 14:37:21 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id a103so39240438ioj.1 for ; Wed, 19 Apr 2017 14:37:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/LOTt941wSkP45OyZt1ljouv2eJTMqQ2ypS4ys/+Kr8=; b=sWRdNR8ig1QJCkJCNzrx/yf6FiCPRGZLUZKwY11xim6HMTwUa5IXA5LeGJ5SjdctM9 D8C6ZehEJBr8ddiwg0FiC7QBPxTcKVuMzqxZI4qiRDBku/W4eSrC++SEJoVoYcaTTlhe GAt0YDtWXjivxnXM8HP5qCrgtRf5KqRoUhIzD1onTZoBOd0bkyoR+R+9IaXCRMv9kgrU JpIkr4LgN1d1Tks92vg1e0iNzrB3HCuv+8eGJ3j1EgvJqH1wLpkAL7QA4cdLWr8hQKiJ vVPMxLBUIIB6mqHvljps6+kPvV3Rq97PzuZGjMfNrQig/Wn3/qWbJe9Bl4Ree6+UGpfy DCbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/LOTt941wSkP45OyZt1ljouv2eJTMqQ2ypS4ys/+Kr8=; b=I3B/2xNY3kuydiUQy0mECEvL8ZvBBDzUa1705xDU9hUO+SrTW8p1CfH4uw6pIfI9VU tkr2nIeCUNBVXH4uiSYoxbn4oSw3eU6mx4UuFeZshd52q6XnYOTcunznDeAwz2YROHDI PNjpl9DEVuOcxrs8KfHDxd1aLwDdzeMltaZJe3LJMbEjB3jXIzlRJjv95U14vd4N94PW xeCL0BikHUrj76h3kAl02w8RQICFGPOG+wiylhS3SZgMXbTrk9s1Aabf5xpVaJKYXfj1 IpvoWmiX/WVPTng/f+2OhsIbi/k9dOO+3B3WXqPgOic94Qvi497Sa5ydvsSJ/4N/SHS2 jxmw== X-Gm-Message-State: AN3rC/6FI1kxYf6htgaZABGyQ7U6djCwOhkIojTBL6BLKQFyRsXqfrpq TU+6qR3obSXxvuIuQ4tXtfW3GF3tgg== X-Received: by 10.107.58.197 with SMTP id h188mr5511709ioa.221.1492637840306; Wed, 19 Apr 2017 14:37:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.12.13 with HTTP; Wed, 19 Apr 2017 14:37:19 -0700 (PDT) In-Reply-To: References: <15c31273-c278-af61-2a01-0b68ab8af182@stpeter.im> <0f5b55f8-5fcb-2a61-435e-7b93d2d8f9e6@stpeter.im> <6df28263-cdfa-cc61-4ba9-1bdae17bcca8@stpeter.im> From: William Fisher Date: Wed, 19 Apr 2017 14:37:19 -0700 Message-ID: To: Sam Whited Cc: Peter Saint-Andre , precis@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [precis] Enforcement as an Idempotent operation X-BeenThere: precis@ietf.org 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 21:37:23 -0000 An alternative is to treat finalization as an application/protocol responsibility. RFC 7564 section 6.2. "Further Excluded Characters" can be interpreted as allowing a protocol to post-process PRECIS output, just like section 6.3. "Building Application-Layer Constructs" allows pre-processing input before passing it to PRECIS. PRECIS is the recommended whitelist ("inclusion model"). A protocol/application can still blacklist specific inputs, which may include "fixing" non-idempotent results. -Bill On Wed, Apr 19, 2017 at 8:35 AM, Sam Whited wrote: > 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. > > Best, > Sam