From nobody Fri May 4 11:40:53 2018 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 09B0312D945 for ; Fri, 4 May 2018 11:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, 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 xRbguFsQwHZZ for ; Fri, 4 May 2018 11:40:49 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 B2B9D12D88D for ; Fri, 4 May 2018 11:40:49 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id q4-v6so4563482ite.3 for ; Fri, 04 May 2018 11:40:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=Y0U95md/POGIc1l53BD1biLoJcXG0Y4xj3P6uk+yfig=; b=Z6GK1bOqMqbZ/JwfwwLtEeeHJPXec2eZBD+XorQq5HjYOdzuP4T42tSKDYoaDsHfef pe7ORRZT2dTiETaS2cKOrSM+kjFQlVBYZ4pJhIvf2agoNL8f4V7PBRBGr4R2t1B/VxV+ 0F5EN2BSQ2l8EzIrBhMtSwX4p6IiKbDAD+7FY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=Y0U95md/POGIc1l53BD1biLoJcXG0Y4xj3P6uk+yfig=; b=Rf52Yh3V8BpoFAth+Tagq07pCBPI5mNFatrRyB7aaZl0jaYTZ2IW9ivZp1593VxyP3 rRpFB4y5TbnDjo8WUyd7b3Qy4bd5NJVa3wvif+dH4J7A0z0DoJXJLxH+ZoR9pHF2H9NY O/840F8u35u0AokEzG0Ny+dEyH1V3NPL+viCmmgdsZKD99mQdYIkAnYSilIrqoeNpeha JfSxpTvakwuMyxBQwLCzuTl8DSa54JB/yQVuFBMbi+jg26CBc6MVuz67UQlYo/+juEIA hA1NGqZk+s93FzohijL4I2PUN+DEJx3f8GkBAvdapfQPr8mvvlYz69ELqLFBLESQwsjw zD1Q== X-Gm-Message-State: ALQs6tCfCjP4RAl5nyp7baAtQKegoUVcl0NyEsaykT4BiGJ0Fr93vD65 Sck34JhZk8QlfZLTtx3gYH7udQ== X-Google-Smtp-Source: AB8JxZojHkBTx4ciO8bMiKh4KKV5cU+3QH61yLn8SrKPikes1zFrVXx4RRdp4ACJxL/tbGip74j5NQ== X-Received: by 2002:a24:14cb:: with SMTP id 194-v6mr24237366itg.79.1525459248976; Fri, 04 May 2018 11:40:48 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id n201-v6sm1355527itn.7.2018.05.04.11.40.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 May 2018 11:40:48 -0700 (PDT) To: Paul Crovella , precis@ietf.org References: From: Peter Saint-Andre 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: <10b17ef3-a34a-5fe2-3484-e86c4005a5a0@mozilla.com> Date: Fri, 4 May 2018 12:40:46 -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: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="E6lnUXmBAwnoNBPDTvYHGgYzLCuw7mSNx" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 18:40:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --E6lnUXmBAwnoNBPDTvYHGgYzLCuw7mSNx Content-Type: multipart/mixed; boundary="KOfYgjS7fxizXWcDdGYxwDb85w6YyBbG1"; protected-headers="v1" From: Peter Saint-Andre To: Paul Crovella , precis@ietf.org Message-ID: <10b17ef3-a34a-5fe2-3484-e86c4005a5a0@mozilla.com> Subject: Re: [precis] RFC 8264 / 8265 Order of rules References: In-Reply-To: --KOfYgjS7fxizXWcDdGYxwDb85w6YyBbG1 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 3/14/18 10:04 AM, Paul Crovella wrote: > Followup question on > https://www.ietf.org/mail-archive/web/precis/current/msg01445.html >=20 >> implementations should follow the order of rules in Section 7 of RFC 8= 264. >=20 > Should string class validation then be moved from the preparation step > of all profiles to the end of enforcement? I don't know whether > there'd be a practical effect on profiles using the FreeformClass > string class (OpaqueString and RFC 8266's Nickname), or if there's the > potential to be, but it'd be nice to know where to do things. The intent in my head when working on RFC 8265 & RFC 8266 was to define the set of rules for a profile and then in each subsection (preparation, enforcement, comparison) specify each rule to be applied for that operation, without having them be additive (i.e., don't say in the enforcement operation than you first do everything in preparation, then some things in addition). Clearly, this did *not* get translated into the final text because I failed in my responsibility as a spec author. I will send proposed text for errata to this list sometime soon. Peter --KOfYgjS7fxizXWcDdGYxwDb85w6YyBbG1-- --E6lnUXmBAwnoNBPDTvYHGgYzLCuw7mSNx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlrsqS4ACgkQZWGMGH9o FKmrhg//Y1vc8WFoXJbh9SRsWYmpQ/P/PZeEPmJMidYiYlqCdZNHqUw8LBx50ujr 7ETDvCeMTnBk4IAqYJ3+141avFjGYeX3+szhHEjk4cJqlKhsUiUrt4ajP0aT4QuY DxaZvQyeh1llSW/5e6NzzU0RRhhMfwHIh87qzuTpa1Kc+UjG9RHuDDrO4NY7+/Ed kYjBZHq5trPzzv9PurmN3YjKciTMtgzs/rYrA3ZLYu+89ij4lkN26taxtKGNDPfo eSV6kFXSqBEFxbrid72bGmvVqlDWtydEqix7Z06tD8mr2bh9W2is4Ps5awdpgxuM TUm5AO3h0tXagQhIrGqGiR6p9RvEZqwZEGIwmcJz4wUqdKQ8gydm73UNpy8GyHse ZGOrtbB327z9ohohhPzQeKzyMTt9IY/vdLWCeJekPESFVxSRe8jhayLL5sK26Sh0 eUsO6ADCXGo1p1hNIXCTemmuhoGm3NU/lHfNkZuSwgctAq386QFP3nBoXsn9aMjj mxfnCSdfxS2fiTPX/KsT15nJwvOo9LzUhwbEqWuaObPulZotiziWnR0QKVZHdtao lE0BlNnXaiBTjbrg2NnAgO21VTHXWDwmdKjrcaZiMJuu9/cRBw6TANAWkvooJxY5 5tNVzZHDFzdSWpfRTZRzxV6faEChYLsc8CBwWblUvOXgd9QiwkQ= =wB9R -----END PGP SIGNATURE----- --E6lnUXmBAwnoNBPDTvYHGgYzLCuw7mSNx-- From nobody Wed May 9 14:57:36 2018 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 4D1CA12D775 for ; Wed, 9 May 2018 14:57:35 -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 dDPPN_lQE2bt for ; Wed, 9 May 2018 14:57:33 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 DC190129C6B for ; Wed, 9 May 2018 14:57:32 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id g14-v6so734088ioc.7 for ; Wed, 09 May 2018 14:57:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:from:to:references:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=3UYicN129oCf8k4OMCxu0UWWY/lQsP87vLpyFx+xVHM=; b=YB8Ejn9H+zVZoqs4lToQhNOKeOQRbB5kUXqhCdy/+U2GeXlORr5ozID3O3QxU7FmOg JY5lf+/bN7fUFXWFwaLV4F5KQYnKidfZokKcj35u6gSU6g8WYPETDGPhpHEvx87PpKTu CMyRU1cWWME1/nDnls/NxjMmiEzkaPrqSq688= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=3UYicN129oCf8k4OMCxu0UWWY/lQsP87vLpyFx+xVHM=; b=Bg952g2Y9nQqlctAVtp/Z5BmiDAE4wGja+vRDt10faJsT/FwXIn5Ahm5nSxa5zJBTL 5LTE9/doRZ5EAw2/FTJBygHfOZnoFL/Os4KG9Q/U2htZK0l5yTY+BEnpU95pncq6CAoR I5Z/PuT8iAyNzoCclLsauAKJjHW8b5HDP2coYcDiFVFoS0659PSgGiLhEX/s25BfSGQu lkvbp4Y61AChn3v/hw/vbLRS62zjLlLZKRYMAFWvMvaUpl7jCHqO99YGfX6Ft4w/gOrY hB6xGEJsOb0UeQpIHsJIctH5Nr2llS5ATouca1B+NQKLLa5oGFAKwXTqz6XuIY4yyhwC FKSg== X-Gm-Message-State: ALQs6tBSw8FBxy+POSkgs01X3kM1Ibf/fhnYiVxvT0Z7z92z/lx157FS Tppwc+BzDl+9rGkd14+rGLOmvQ== X-Google-Smtp-Source: AB8JxZr6hxHIZyxOxiNJwdo//VC76qNgcIozvdBom8WZIsFOL52HufLdZlI5bDFlCOPp0nwLuQdd7g== X-Received: by 2002:a6b:4606:: with SMTP id t6-v6mr50204699ioa.158.1525903052229; Wed, 09 May 2018 14:57:32 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id z133-v6sm8087956itb.4.2018.05.09.14.57.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 May 2018 14:57:31 -0700 (PDT) From: Peter Saint-Andre To: precis@ietf.org References: <10b17ef3-a34a-5fe2-3484-e86c4005a5a0@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: Date: Wed, 9 May 2018 15:57:30 -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: <10b17ef3-a34a-5fe2-3484-e86c4005a5a0@mozilla.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GamjWl8ojc6djDyyidJvzsIA5rJkDdYld" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 21:57:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GamjWl8ojc6djDyyidJvzsIA5rJkDdYld Content-Type: multipart/mixed; boundary="SWmzV9w0eF48O8wYsAxLk9gDwczD8s3eX"; protected-headers="v1" From: Peter Saint-Andre To: precis@ietf.org Message-ID: Subject: Re: [precis] RFC 8264 / 8265 Order of rules References: <10b17ef3-a34a-5fe2-3484-e86c4005a5a0@mozilla.com> In-Reply-To: <10b17ef3-a34a-5fe2-3484-e86c4005a5a0@mozilla.com> --SWmzV9w0eF48O8wYsAxLk9gDwczD8s3eX Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 5/4/18 12:40 PM, Peter Saint-Andre wrote: > On 3/14/18 10:04 AM, Paul Crovella wrote: >> Followup question on >> https://www.ietf.org/mail-archive/web/precis/current/msg01445.html >> >>> implementations should follow the order of rules in Section 7 of RFC = 8264. >> >> Should string class validation then be moved from the preparation step= >> of all profiles to the end of enforcement? I don't know whether >> there'd be a practical effect on profiles using the FreeformClass >> string class (OpaqueString and RFC 8266's Nickname), or if there's the= >> potential to be, but it'd be nice to know where to do things. >=20 > The intent in my head when working on RFC 8265 & RFC 8266 was to define= > the set of rules for a profile and then in each subsection (preparation= , > enforcement, comparison) specify each rule to be applied for that > operation, without having them be additive (i.e., don't say in the > enforcement operation than you first do everything in preparation, then= > some things in addition). Clearly, this did *not* get translated into > the final text because I failed in my responsibility as a spec author. >=20 > I will send proposed text for errata to this list sometime soon. I have in mind something like the following for Section 3.3 of RFC 8265. ### OLD 3.3.3. Enforcement An entity that performs enforcement according to this profile MUST prepare an input string as described in Section 3.3.2 and MUST also apply the following rules specified in Section 3.3.1 in the order shown: 1. Case Mapping Rule 2. Normalization Rule 3. 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 result of the foregoing operations is an output string that conforms to the UsernameCaseMapped profile. Until an implementation produces such an output string, it MUST NOT treat the string as conforming (in particular, it MUST NOT assume that an input string is conforming before the enforcement operation has been completed). 3.3.4. Comparison An entity that performs comparison of two strings according to this profile MUST prepare each string as specified in Section 3.3.2 and then MUST enforce the rules specified in Section 3.3.3. The two strings are to be considered equivalent if and only if they are an exact octet-for-octet match (sometimes called "bit-string identity"). Until an implementation determines whether two strings are to be considered equivalent, it MUST NOT treat them as equivalent (in particular, it MUST NOT assume that two input strings are equivalent before the comparison operation has been completed). 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 result of the foregoing operations is an output string that conforms to the UsernameCaseMapped profile. Until an implementation produces such an output string, it MUST NOT treat the string as conforming (in particular, it MUST NOT assume that an input string is conforming before the enforcement operation has been completed). 3.3.4. Comparison An entity that performs comparison of two strings 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 The two strings are to be considered equivalent if and only if they are an exact octet-for-octet match (sometimes called "bit-string identity"). Until an implementation determines whether two strings are to be considered equivalent, it MUST NOT treat them as equivalent (in particular, it MUST NOT assume that two input strings are equivalent before the comparison operation has been completed). ### Would this clarify string handling enough to be useful? /psa --SWmzV9w0eF48O8wYsAxLk9gDwczD8s3eX-- --GamjWl8ojc6djDyyidJvzsIA5rJkDdYld Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlrzbsoACgkQZWGMGH9o FKnBQhAA1d3hKJkI96LhG0NIFNngRdfYFPgk3ZFtpW8LkGfAZIMMh3KDl+JR98jN N43tkGVy3iiqE/v87BUtbdo2YHx6gQVyhQYmGUA3vvSzmtavowSgMF5/E6fTzlAR UIEjY7SCGX1IFz04/VbvnYrbtFrv5EcrNfxhqLjtOJKx9OYazixZocG4un0mrOiq tSt0Z8geB4gJX/O4cbs9G2hhAZPRgHrdOGkgQVAC2xRcsQ/anCnWFTXq+QJzfJQU urpXoyoSDUOmdkI+nhKVaZ5ZpBAOr91KmbGUthL36F9+8ElUyQFTskhvc5UFZbDE 2/A2GQwlltxDUvFRUAqr7eMDfTOl3RZiNzDKqkYLb28GNaJuEoTtUuLgIj94ZU++ mayP4qLQb84tcq69klMUBLIZJxezscJpZdTFH2i6ceBLdfrzl03yMYDytY1CpbKd I90GayXY5I7BK5YISBDjOxReSD3nKr83yjE6y0RBIrKAzdwtghsRTJlI9XBlyo7p kgr6vR44CMnmDhAZZLF1mViIJkUKybsX4jLyabBJVQNWdASQNvWPIyLQxE4iCcA5 tSpj0sJmbiVMt9ksHOaP7gwtsovTdj3HsHQZEI+nuIP+cqFkxMWbZroI4rnC5a0A ePhWF8WzTh8KnHLJE96Gsrv+sPWwhtWN/lqWQpjfqp0sAeCrF30= =G7Yf -----END PGP SIGNATURE----- --GamjWl8ojc6djDyyidJvzsIA5rJkDdYld-- From nobody Fri May 11 12:04:46 2018 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 D5A0B12D86A for ; Fri, 11 May 2018 12:04:44 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 IQDjeQPIa0QT for ; Fri, 11 May 2018 12:04:43 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 302A6126D73 for ; Fri, 11 May 2018 12:04:43 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id r25-v6so9368792lfd.1 for ; Fri, 11 May 2018 12:04:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=K9xZl/1QKxKDnig/BKZZCsXc3YpyHiaSLiHyeCbwEII=; b=sgA1YOqZ7R+1eUQv6tsfSS0WfxjKUlyNaM1+MKTgepZvBVdU3JDaqv8x+ICf5YDym+ 6h/so3Aou6nH9cv6jpt20BLqXLw5VbFKf07w0i6TbV1nJig6UgLdso4L9JiXOuCtqwwn WbK0hQAuRELd+3AZrWw1zXuQtvSxB+JOBLHO7T4BthieThKc7voVKqTMvGTa36riWpQo 8CdW0HCJUonnuVOEIiCxBgXlP06Ln5sVJEzgyZZ5xAaoiH1j3d3oj2pih3WYquppIYQj OjYwgMiSw+wowWkprBRNE1RJqE/bVa898YcpazrijIXv5qOBLxeUYQ3s1TCL1aigKwLM yKyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=K9xZl/1QKxKDnig/BKZZCsXc3YpyHiaSLiHyeCbwEII=; b=RLmlEZFv10Z9KTqwLvw5L28xZwkt/pO5hI02ufzUi8W4JnV6ZoXRnrjxy7oxjOjYp5 M1ndEB1QxzkpGkHGc42of8M7OWXdIw694Q+2T8NLGA+Fuig4P+jwH8C487E2pqvXeeW4 ItkLxio20D5IicbDSFyD4725z/DKuq29lOpiYC1BdSomUIGID0BQayG2Se2VqQONQgRT 3GDn2fLrNgNaFCM5V0sahRLFLbDJG5/id2e52VGDytdh+8ZRIYL6fcMue0BC/iNz+E8P fg5Mg3M+x7QnmoKSjmBcggCyJhjtyRcsahe1EL7R1c11tUmQykxShkUF5Kj1p0il/mli hCmg== X-Gm-Message-State: ALKqPweIu6U69D9xLnJ5rtSkdJlQWQySvo06R5c/Tdf7oFT4ZhU1J0LP pZYPrZLXqKalPLRBn92rUdioQI7ktuNOlhHKO5NX0MBE X-Google-Smtp-Source: AB8JxZrNnjMsFzkXHUdmEaSPUN5ybJl59NIxgdJwOORhn+LAl3KtKLCKpZ/my4ZxVApFD5FYHD1oNa/4cTZOGfpNajs= X-Received: by 2002:a2e:86d9:: with SMTP id n25-v6mr4805160ljj.18.1526065481281; Fri, 11 May 2018 12:04:41 -0700 (PDT) MIME-Version: 1.0 References: <10b17ef3-a34a-5fe2-3484-e86c4005a5a0@mozilla.com> In-Reply-To: From: William Fisher Date: Fri, 11 May 2018 12:04:29 -0700 Message-ID: To: stpeter@mozilla.com Cc: precis@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2018 19:04:45 -0000 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 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]. > 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. 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. (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.) From nobody Wed May 16 10:17:50 2018 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 0FD1312D77D for ; 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 ; 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 ; Wed, 16 May 2018 10:17:46 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id 70-v6so3929514ity.2 for ; 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 Cc: precis@ietf.org References: <10b17ef3-a34a-5fe2-3484-e86c4005a5a0@mozilla.com> From: Peter Saint-Andre 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: 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: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9gNSz00RTuEyYUHG6zP26m92qKvIAdqV1" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 17:17:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9gNSz00RTuEyYUHG6zP26m92qKvIAdqV1 Content-Type: multipart/mixed; boundary="an8x86ruvGXXCyOFlklSY9b1wdsEdy6bJ"; protected-headers="v1" From: Peter Saint-Andre To: William Fisher Cc: precis@ietf.org Message-ID: Subject: Re: [precis] RFC 8264 / 8265 Order of rules References: <10b17ef3-a34a-5fe2-3484-e86c4005a5a0@mozilla.com> In-Reply-To: --an8x86ruvGXXCyOFlklSY9b1wdsEdy6bJ Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 5/11/18 1:04 PM, William Fisher wrote: > Hi Peter, >=20 > My thoughts on your proposed text is below. >=20 > I, for one, thought you did a good job with such a complex topic. >=20 > -Bill >=20 >=20 > On Wed, May 9, 2018 at 2:57 PM Peter Saint-Andre > wrote: >=20 >> NEW >=20 >> 3.3.3. Enforcement >=20 >> An entity that performs enforcement according to this profile MUST= >> apply the following rules specified in Section 3.3.1 in the order >> shown: >=20 >> 1. Width Mapping Rule >=20 >> 2. Case Mapping Rule >=20 >> 3. Normalization Rule >=20 >> 4. Directionality Rule >=20 >> After all of the foregoing rules have been enforced, the entity MU= ST >> 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 strin= gs >> are accepted, a non-empty sequence of characters can result in a >> zero-length username after canonicalization). >=20 > The output string still needs to be validated by the base "IdentifierCl= ass" > before it can be said to conform to the UsernameCaseMapped profile. >=20 > INSERT: >=20 > 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. >=20 >=20 > In RFC 8265, the opening sentence of section "3.3.2 Preparation" implie= s > preparation is done before enforcement.=20 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: >=20 > OLD: >=20 > An entity that prepares an input string for subsequent enforcement > according to this profile MUST proceed as follows (applying the ste= ps > in the order shown). >=20 > PROPOSED: >=20 > 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 (sect= ion > 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.) >=20 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 --an8x86ruvGXXCyOFlklSY9b1wdsEdy6bJ-- --9gNSz00RTuEyYUHG6zP26m92qKvIAdqV1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlr8Z7cACgkQZWGMGH9o FKkBxxAAvMlb1IymAKWqvo6As5rQRij3msdSJrMMJaI+SriMbLVZm4WzwmOpBKpF NDFWRowUzyhwVYUDcCsY6/Fr5yYFFiGUVAeMIWlI/20C5fbHvDVN3/rKhtjY3ymn hndBM4YIjtSI+KnOY1BKMJmluK8IoFz8+3jIHGlJl6JKClcKlXlWly2Novl2WBOu wwkqlBnP+GL6moD9oTCTjLegvrtjF8Dk0dHNi0aQKCTBcw6IRh9sBIt/s5Q3RWNg qfkFDxrAc5Gj1JgBo6PgEuH84AYU9NtQgLLhnSL2nK7WZ3a3/gnHMgnmxG8YjZJB OLk5ZRtzsg/MpAOuTuMG1pd76PY2oVRCxUkZroZb8c0MNx11G2MbMK+AXpq4pdzs SiJy4yHUXyg1zW6toxu0y1plnUVhzBPb2jaQS7SanXos6OZ2OrOJTQAYAY9i7Ol4 0NW6o3Emdw2QF1refiy+j94jpN9A/2vnzpW05TrqG5vw+x5K97GvgPKgHgTtnK6b s+aJDsNIj5mQOPlMwaJJKw2LFjTG++lJXiX88QuQ6Vv+icEhzX1nDV6i7wsp95XZ YQNrbbDlrBRs04ptmqbOXlcwPn4qwNTR+dsX1a9xaJR5j5a1iqyU5vYrNGUATjnz evL+vie6q8GTRp4x5jZO6srm2dfJmZV/D7VkJDvYrFlLjP+XcCU= =CIjB -----END PGP SIGNATURE----- --9gNSz00RTuEyYUHG6zP26m92qKvIAdqV1-- From nobody Thu May 17 08:03:32 2018 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 67CC412EAF6; Thu, 17 May 2018 08:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 rinZRjsgEOqe; Thu, 17 May 2018 08:03:07 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ADA3127601; Thu, 17 May 2018 08:03:07 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1fJKQs-000DPP-4I; Thu, 17 May 2018 11:03:06 -0400 Date: Thu, 17 May 2018 11:03:00 -0400 From: John C Klensin To: i18n-discuss@iab.org, precis@ietf.org, idna-update@ietf.org, ima@ietf.org Message-ID: <646A7647610EDC670B22283A@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [precis] FWD: call for comments on Charmod-Norm 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: Thu, 17 May 2018 15:03:15 -0000 Hi. Forwarding to the relevant IETF-related I18N for those who don't follow the IETF list. Charmod has been the key W3C document on non-ASCII string handling for the web. It has been referenced many times in our discussions even by those who disagreed with some of its provisions. This new Charmod-Norm draft has been in progress for a long time but represents a new (and, IMO, much-improved) specification for string normalization and comparison. I'd encourage anyone with interest or the belief that they have competence in this area to review it. Comments as specified below and _not_, please, to any of the list copied on this note. thanks, john ---------- Forwarded Message ---------- Date: Monday, May 14, 2018 17:57 +0000 From: "Phillips, Addison" To: ietf@ietf.org Subject: [W3C I18N] call for comments on Charmod-Norm Dear IETF participants, The W3C Internationalization (I18N) Working Group recently published a "last call for review" of the "Character Model for the World Wide Web: String Matching" Note [1]. Because our group felt it was of general interest to IETF, I was tasked [4] with posting this announcement on this list. We are looking for comments by Tuesday 29 May. This document builds on the document Character Model for the World Wide Web 1.0: Fundamentals [2] and provides authors of specifications, software developers, and content developers with a common reference on string identity matching on the World Wide Web, in order to increase interoperability. [It is similar, in that regard, to the PRECIS RFCs in IETF] All comments are welcome. Please raise them as github issues [3]. To make it easier to track comments, please raise separate issues for each comment and point to the section you are commenting on using a URL. Thanks, Addison Phillips Principal SDE, I18N Architect (Amazon) Chair (W3C I18N WG) Internationalization is not a feature. It is an architecture. [1] https://www.w3.org/TR/charmod-norm [2] https://www.w3.org/TR/charmod [3] https://github.com/w3c/charmod-norm/issues [4] https://www.w3.org/International/track/actions/709 ---------- End Forwarded Message ----------