Re: [precis] Milestones changed for precis WG

Christian Schudt <christian.schudt@gmx.de> Mon, 28 March 2016 19:58 UTC

Return-Path: <christian.schudt@gmx.de>
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 4465712DB32 for <precis@ietfa.amsl.com>; Mon, 28 Mar 2016 12:58:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 9gxfRXT_8ivT for <precis@ietfa.amsl.com>; Mon, 28 Mar 2016 12:58:17 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC71012D155 for <precis@ietf.org>; Mon, 28 Mar 2016 12:58:16 -0700 (PDT)
Received: from christihudtsmbp.fritz.box ([77.0.28.202]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LiDrv-1ZyQai0ymZ-00nP7l; Mon, 28 Mar 2016 21:58:07 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Christian Schudt <christian.schudt@gmx.de>
In-Reply-To: <E5D59850-BE7B-4AB9-863F-E883DA9C4E13@viagenie.ca>
Date: Mon, 28 Mar 2016 21:58:04 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <CECC45A3-B52F-489A-B64E-8D9B8DCDBD47@gmx.de>
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>
To: Marc Blanchet <marc.blanchet@viagenie.ca>
X-Mailer: Apple Mail (2.3096.5)
X-Provags-ID: V03:K0:BFxNr44RNNH2uC9rfhuBBbrrbzAtuYqZ+p9kOvTEIVMeMdOlQ6g wLRfJciQMLfamP75Ij0/jnDXRTCzPatdRywjkEo61ZQo5RFKrxChqoOGXxYoUlkwz7soH9j pyZ+B3lSTFrfScn842wEyDA6mie+/DU0NlO/o7A16r3XPRw1O6H+F47OrD1tn2Zlxr+OSAO 0pfDf+JjOhbbqtrNCLcUA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:A4bdQVvf9YM=:hEWlQWvNv2xrXR/6/YoBDJ 3qODSy/X0UyBOBBPyld4z+zRVbZJRkr10jwD3lUVgpBBa01Esjq0If6dz9fb0dJG8VgN/SN4a uAQhppjvTQzOZmbjnYAXwn1C0GEEE2mJH7wkdj03BcpFZXQUWFZHHxwFCb5FJS8ctp3VTaHBY rLUKVdodGkH7mdJqN/fjea1gp+DM2MBMHZMH/y4i++8cFTuw1EPE5uwSv6NB35kHFLMAvbl3H G6xPmj+7iwfT6chrt8xObSg7tfD+NmGWmupDq+O2YwwFhbY97+g0em4Ki9IYes75R2UTdU1GQ UBxgKwKVyDgAC4V82hQnloKRPJvL9N/wqvbC3nAyKPW/FNCGJ1Cda+S00V2FZ7NZ9POfkrsOQ ERPOL7otSOsUm5Re/l02VJ8i8W0Gg0acwfgwuIMuRw14GRhS0vJZ7bX6qAJ8z+CBVHZ2IubuG xoUNqkQcuoxXE/wSuOVBGd4qwFnQ7GqaKZlA7tO2/tZsCIwLRJkRNsTQhcjewVHjRDkF40Nfg POM9X0qyMGq0bm+j6lME5sb2OjaKtUt5rhobHBdbjqzal7bNqce+kZKUHuMpVVLPbg50iU1DL PDXz5xcKIr1z4YWmQAl/I0BtkiFvexRo5OSHvC/5UwCygMRMbu5doAmL4+Gbb2Grg0g6Mp8bl bFf+Wza/385/OJ72zkQD46RpJc9Gb9KbafRmEAD1FhhXnyThJyufwpl/lzxGlaivnHMKZIDaj r6jTHqpnQVnU7+uylDYhDVVOFUCkhsNM0dYY4P/9o2mUSw1eVs8iglxKvzcHNuoYw3OmsWXx2 FoIHsqL
Archived-At: <http://mailarchive.ietf.org/arch/msg/precis/sUSSDVi7zNPfX4Gb6jmeH0XpQW4>
Cc: precis@ietf.org
Subject: Re: [precis] 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: Mon, 28 Mar 2016 19:58:19 -0000

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.

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?

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.

If I stick to the rules in RFC 7613 § 3.2.2, it would be disallowed (HasCompat == true, => preparation *before* other rules fails).
If I stick to the rules in RFC 7564 § 7, it would be allowed (NFC converts it to U+00C5 => preparation *after* other rules succeeds).

The workaround for half and fullwidth characters in RFC 7613 §3.2.1 suggests, that the authors *want* a workaround for HasCompat characters, but they only specified it for a few characters, which somehow feels like they overlooked it.
=> It would be nice if the authors could give their thoughts on it!

If all profiles simply sticked to the rules in §7, no workarounds are needed.


+1 for the clarification of the meaning of „preparation“. It suggests that a string, which passes the preparation step is valid. But in fact a rule could still fail during enforcement (e.g. Bidi rule).

Thanks for your attention,
Christian



> Am 28.03.2016 um 21:28 schrieb Marc Blanchet <marc.blanchet@viagenie.ca>:
> 
> On 28 Mar 2016, at 13:30, Peter Saint-Andre wrote:
> 
> On 3/1/16 3:56 PM, Peter Saint-Andre wrote:
> 
> On 3/1/16 3:23 PM, Marc Blanchet wrote:
> 
> hello,
> we were thinking of closing the working group since the main topics
> have been done and published as RFC. However, as some mailing list
> discussions require that some corrections to RFC 7564 and 7613 are
> needed, we added those two milestones to the charter. The intent is when
> those are done, we would close the working group.
> 
> Thanks, Marc. Here is my understanding of what needs to be done:
> 
> In RFC 7564:
> 
> 	• Change §5.2.3 to mention Unicode toLower() as an alternative to
> Unicode Default Case Folding and describe the circumstances in which
> toLower() is appropriate.
> 
> 	• Change the order of operations in §7 from MUST to SHOULD (we've
> already deviated from that slightly in RFC 7613 §3.2.1).
> 
> 	• Clarify the meaning of 'preparation' (because it is different from
> what stringprep meant by the term).
> 
> In RFC 7613:
> 
> a. Revisit Unicode Default Case Folding here, too.
> 
> b. Modify the presentation (but not the content) of the rules for each
> profile, along the lines of what we did in RFC 7700 (i.e., describe the
> rules in one section and then use them in separate sections on
> preparation, enforcement, and comparison).
> 
> We'll also want to review and correct the errata that have been reported.
> 
> I can commit to doing this work.
> 
> FYI, I plan to submit -00 versions of the bis documents when the submission window opens again on April 3.
> 
> Marc, would you like me to submit these as individual I-Ds or WG I-Ds? (They would be draft-[ietf|saintandre]-rfc[7564|7613|7700]-bis-00.)
> 
> I’m sure that the wg is likely to be ok with wg drafts, but let’s do the normal process. Please submit first as individual draft and we will call later for wg adoption.
> 
> Marc.
> 
> Peter
> 
> precis mailing list
> precis@ietf.org
> https://www.ietf.org/mailman/listinfo/precis
> 
> _______________________________________________
> precis mailing list
> precis@ietf.org
> https://www.ietf.org/mailman/listinfo/precis