Re: [precis] RFC 8264 / 8265 Order of rules

Peter Saint-Andre <stpeter@mozilla.com> Wed, 16 May 2018 17:17 UTC

Return-Path: <stpeter@mozilla.com>
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 0FD1312D77D for <precis@ietfa.amsl.com>; Wed, 16 May 2018 10:17:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 z-GEaianF_rO for <precis@ietfa.amsl.com>; Wed, 16 May 2018 10:17:46 -0700 (PDT)
Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 A00A6126BF7 for <precis@ietf.org>; Wed, 16 May 2018 10:17:46 -0700 (PDT)
Received: by mail-it0-x234.google.com with SMTP id 70-v6so3929514ity.2 for <precis@ietf.org>; Wed, 16 May 2018 10:17:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=zvps/X5BCG3gOybcI+aBkou+bk9X6vcJjx1mLONHp08=; b=Mg+/GDPOtHEOn31nFfkjw5BGovIWT9+XzZcCXgYlTpkfR2144rGMq7IyOIOsN50/WW Gvjf+vN7rwTAyvx2w+VF6vBE0DqZVx1q9tUm/H/CSYkSl/tmz6PBtSuKO0n+iMKHWW6C CjphQ19ssQlEfRXmn5j4OwPyLJlN4wLYmJC94=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=zvps/X5BCG3gOybcI+aBkou+bk9X6vcJjx1mLONHp08=; b=s+Nhin1ee4F45y9fxuW9UtSOXPXdh7vrIwhUWcbBKMiMIOcHo2RVL40OkkDJmsDtmr cRz6E1giFP088DMUR5klDW5o4s/bCfvO/HlI4fK1E56svm5zZmWPz72Qq6yQ0STH/1ox ZY4IpltG43jKdWQcqxYvC9rWZeBdB/9Wv5zV9p6rZ5OGfcHS7GxxU9L+WZRJM8sdImyN IAl4STusAg43sEFnbfddmZNw1v9VTIWf6m9pkaefaeds9raeiqFu8FgMTF8hwDZ5be5s ed3phnIxYh+v90ZWV61mOjtAHyzC3VT7rK05i85rCfHOCNIsAxLFSP6NPetz3YaL9ckg AfZw==
X-Gm-Message-State: ALKqPwfV/NtgZFMeyLBRmbe96KGcI6FvNrE+MdjsRLzMmrHUia9GyuSF sW8HLMnezhDz4CZqLSGzHdlgPQ==
X-Google-Smtp-Source: AB8JxZpjWWzAO4KlfyTI3rLBpT+gc0P6cByaAp1yJEKV+1JE7eksNjGS1nXMtyM1Dkc85W8hLuhM+g==
X-Received: by 2002:a6b:ca83:: with SMTP id a125-v6mr2187457iog.111.1526491065818; Wed, 16 May 2018 10:17:45 -0700 (PDT)
Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id c27-v6sm1640310iod.58.2018.05.16.10.17.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 May 2018 10:17:44 -0700 (PDT)
To: William Fisher <william.w.fisher@gmail.com>
Cc: precis@ietf.org
References: <CAN2symj4jCLiM0y52Ey07rQSrh8ui4x9gZjmc53WbEYfWcoZtA@mail.gmail.com> <10b17ef3-a34a-5fe2-3484-e86c4005a5a0@mozilla.com> <e9e45d0a-5593-962d-690a-53dd7a33f07c@mozilla.com> <CAHVjMKGM3Qv-SUcD6a-eXbF=4XMxvaZ2FHrS3M7ZvRm5qK9aHA@mail.gmail.com>
From: Peter Saint-Andre <stpeter@mozilla.com>
Openpgp: preference=signencrypt
Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V
Message-ID: <bbc257f8-0f3b-71a8-c6c4-ebf27e03e8ab@mozilla.com>
Date: Wed, 16 May 2018 11:17:43 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <CAHVjMKGM3Qv-SUcD6a-eXbF=4XMxvaZ2FHrS3M7ZvRm5qK9aHA@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9gNSz00RTuEyYUHG6zP26m92qKvIAdqV1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/precis/QP5XgrsAIwyfq0trevPc0ctL5Nw>
Subject: Re: [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: Wed, 16 May 2018 17:17:49 -0000

On 5/11/18 1:04 PM, William Fisher wrote:
> Hi Peter,
> 
> My thoughts on your proposed text is below.
> 
> I, for one, thought you did a good job with such a complex topic.
> 
> -Bill
> 
> 
> On Wed, May 9, 2018 at 2:57 PM Peter Saint-Andre <stpeter@mozilla.com>
> wrote:
> 
>> NEW
> 
>> 3.3.3.  Enforcement
> 
>>     An entity that performs enforcement according to this profile MUST
>>     apply the following rules specified in Section 3.3.1 in the order
>>     shown:
> 
>>     1.  Width Mapping Rule
> 
>>     2.  Case Mapping Rule
> 
>>     3.  Normalization Rule
> 
>>     4.  Directionality Rule
> 
>>     After all of the foregoing rules have been enforced, the entity MUST
>>     ensure that the username is not zero bytes in length (this is done
>>     after enforcing the rules to prevent applications from mistakenly
>>     omitting a username entirely, because when internationalized strings
>>     are accepted, a non-empty sequence of characters can result in a
>>     zero-length username after canonicalization).
> 
> The output string still needs to be validated by the base "IdentifierClass"
> before it can be said to conform to the UsernameCaseMapped profile.
> 
> INSERT:
> 
>      Finally, the entity MUST ensure that the username consists only of
> Unicode code points that are explicitly allowed by the PRECIS
> IdentifierClass defined in Section 4.2 of [RFC8264].

Yes indeed.

>>     The result of the foregoing operations is an output string that
>>     conforms to the UsernameCaseMapped profile.
> 
> 
> In RFC 8265, the opening sentence of section "3.3.2 Preparation" implies
> preparation is done before enforcement. 

Right - I'm proposing that we remove that text by explicitly specifiying
for each operation what the steps are (and not saying that they are
additive, i.e., stop saying that enforcement is the steps defined in
preparation plus some other steps).

> This can lead to confusion:
> 
> OLD:
> 
>     An entity that prepares an input string for subsequent enforcement
>     according to this profile MUST proceed as follows (applying the steps
>     in the order shown).
> 
> PROPOSED:
> 
>     An entity that performs preparation according to this profile MUST apply
> the following steps in the order shown.

Ah, I see what you mean. Yes, that's better.

> (I am wary of the separate preparation step as something that an
> application developer might use. The notion mentioned in RFC 8264 (section
> 3) that a client might use the "preparation" step before handing the
> protocol string to an authoritative server which does the "enforcement"
> step is problematic for the Username profiles. It has been shown that
> preparation by itself can reject strings that enforcement would have
> accepted.  Example: '\u212b' under the UsernameCasePreserved profile.)
> 

The original idea was that some resource-constrained entities might not
have the capacity to do things like Unicode normalization, in part
because they might not have the storage capacity to hold the Unicode
tables and in part because they might lack the computing resources to
perform normalization operations (back then we were thinking of things
like in-browser messaging clients, but these days we might think of
things like IoT devices). As a result, we were thinking that such
entities might simply restrict themselves to a safe subset of code
points (not necessarily just the ASCII range) and consider that "good
enough". Naturally, other steps might be needed depending on the string
class or profile (e.g., the width mapping rule for usernames).

Peter