From nobody Wed May 4 08:07:27 2016 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 34E1412D6E9 for ; Wed, 4 May 2016 08:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-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 Rl6LKCduLOk8 for ; Wed, 4 May 2016 08:07:19 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 24C2A12D6CD for ; Wed, 4 May 2016 08:06:29 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B79A640014; Wed, 4 May 2016 09:16:05 -0600 (MDT) To: Sam Whited , RFC Errata System References: <20151223045826.9CED018000D@rfc-editor.org> From: Peter Saint-Andre Message-ID: <572A0FF3.8040707@stpeter.im> Date: Wed, 4 May 2016 09:06:27 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: alissa@cooperw.in, precis@ietf.org, barryleiba@computer.org Subject: Re: [precis] [Technical Errata Reported] RFC7700 (4570) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 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, 04 May 2016 15:07:26 -0000 On 12/23/15 8:09 AM, Sam Whited wrote: > Hi all, > > After submitting this yesterday I had a discussion with Christian > Schudt about it and he pointed out that you probably want to be able > to display the text output by the enforce operation, and therefore > this was most likely a deliberate change. With that in mind, I'd like > to ammend my suggestions somewhat: > > The directionality rule should still be removed from the list of rules > in section 2.3 as well as the list in section 2.4 (there is no > directionality rule, so having it in the order of operations is just > confusing), Agreed. > and section 2 item 3 should be updated to clarify that > Unicode default case folding only needs to be applied during the > comparison step (right now it states that it "MUST be applied" which > is ambiguous since it doesn't list what step (or steps) need to apply > it and makes it seem like it should be part of the enforcement step). IMHO it would be best if the definitions of the rules do not contain normative keywords, e.g., "the mapping rule is to apply Unicode Default Case Folding" or "the normalization rule is to apply Unicode Normalization Form KC" or whatever. This change will be reflected in the next version of 7700bis and 7613bis. Peter > > Best, > Sam > > > On Tue, Dec 22, 2015 at 10:58 PM, RFC Errata System > wrote: >> The following errata report has been submitted for RFC7700, >> "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=7700&eid=4570 >> >> -------------------------------------- >> Type: Technical >> Reported by: Sam Whited >> >> Section: 2.3 >> >> Original Text >> ------------- >> An entity that performs enforcement according to this profile MUST >> prepare a string as described in Section 2.2 and MUST also apply the >> following rules specified in Section 2.1 in the order shown: >> >> 1. Additional Mapping Rule >> 2. Normalization Rule >> 3. Directionality Rule >> >> After all of the foregoing rules have been enforced, the entity MUST >> ensure that the nickname is not zero bytes in length (this is done >> after enforcing the rules to prevent applications from mistakenly >> omitting a nickname entirely, because when internationalized >> characters are accepted, a non-empty sequence of characters can >> result in a zero-length nickname after canonicalization). >> >> >> Corrected Text >> -------------- >> An entity that performs enforcement according to this profile MUST >> prepare a string as described in Section 2.2 and MUST also apply the >> following rules specified in Section 2.1 in the order shown: >> >> 1. Additional Mapping Rule >> 2. Case Mapping Rule >> 3. Normalization Rule >> >> After all of the foregoing rules have been enforced, the entity MUST >> ensure that the nickname is not zero bytes in length (this is done >> after enforcing the rules to prevent applications from mistakenly >> omitting a nickname entirely, because when internationalized >> characters are accepted, a non-empty sequence of characters can >> result in a zero-length nickname after canonicalization). >> >> >> Notes >> ----- >> There is no directionality rule to be applied during enforcement as the directionality rule is part of NFKC, the case mapping rule (as mentioned in section 2.1). >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC7700 (draft-ietf-precis-nickname-19) >> -------------------------------------- >> Title : Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames >> Publication Date : December 2015 >> Author(s) : P. Saint-Andre >> Category : PROPOSED STANDARD >> Source : Preparation and Comparison of Internationalized Strings >> Area : Applications and Real-Time >> Stream : IETF >> Verifying Party : IESG >> > > > From nobody Wed May 4 11:05:37 2016 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 85B2212D147 for ; Wed, 4 May 2016 11:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-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 5noDrWP543QM for ; Wed, 4 May 2016 11:05:34 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 55FE212D113 for ; Wed, 4 May 2016 11:05:34 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 91FE041652; Wed, 4 May 2016 12:15:11 -0600 (MDT) To: precis@ietf.org References: From: Peter Saint-Andre Message-ID: <572A39EC.8070204@stpeter.im> Date: Wed, 4 May 2016 12:05:32 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [precis] Test Vectors X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 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, 04 May 2016 18:05:36 -0000 On 4/17/16 11:04 AM, Sam Whited wrote: > Hi all, > > I've begun working on an RFC to specify a set of test vectors for > PRECIS (both for characters in the existing base classes and for > several profiles). > > I think this idea has been mentioned on this list before, but was > never added to the roadmap. Is this something the working group would > be interested in adopting / adding to its agenda, or would it be > preferable for me to publish these as an independant submission? > > Best, > Sam Hi Sam, This sounds useful. Submitting it as an individual Internet-Draft (draft-whited-precis-test-vectors-00) is the best first step. That enables the working group to determine if the document is suitable for adoption as a working group item. I'd be happy to help you in your work on this document. Peter From nobody Wed May 4 13:47:05 2016 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 56B2112D857 for ; Wed, 4 May 2016 13:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-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 GlT5hsMB_c7d for ; Wed, 4 May 2016 13:47:01 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E059712D85F for ; Wed, 4 May 2016 13:46:48 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D42C440016; Wed, 4 May 2016 14:56:26 -0600 (MDT) To: Christian Schudt , Marc Blanchet References: <20160301221928.17792.35793.idtracker@ietfa.amsl.com> <1C1668EA-1734-4D90-82E6-3894ECB6407C@viagenie.ca> <56D61E27.40000@stpeter.im> <56F96A20.7030509@stpeter.im> From: Peter Saint-Andre Message-ID: <572A5FB7.9000305@stpeter.im> Date: Wed, 4 May 2016 14:46:47 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: precis@ietf.org Subject: [precis] order of operations (was: Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 20:47:03 -0000 On 3/28/16 1:58 PM, Christian Schudt wrote: > 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. Sorry about that. Attention cycles come and go. Now that I'm working on the bis drafts, I for one will make it a point to reply more quickly. > 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? Now that I look at RFC 7613 again more closely, I would say that it doesn't really violate the order of operations in §7 of RFC 7564, because for purposes of comparison it still applies the width-mapping rule before all the other rules. However, it's also true that RFC 7613 applies the width-mapping rule before the "preparation" (or, perhaps better, "pre-processing") steps of (a) ensuring that the string consists only of Unicode code points that conform to the PRECIS IdentifierClass and (b) encoding the string as UTF-8. That doesn't violate the letter of RFC 7564 but perhaps it's confusing for implementers. Note that the purpose of the order of operations is "to ensure proper comparison"; I'm not convinced that what happens during preparation or pre-processing needs to follow the same order of operations. There's also the question of whether preparation / pre-processing is all that useful. We added it so that constrained clients (e.g., clients that can't realistically perform normalization) could avoid most of the problems associated with having their strings rejected by a more powerful server that actually does enforcement and comparison. Whether we really need to consider such applications is another story. > 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. For better thread tracking, I'll reply separately to your original message. Peter From nobody Wed May 4 14:32:02 2016 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 B615412D88C for ; Wed, 4 May 2016 14:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-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 dD-WFq6OY7ZC for ; Wed, 4 May 2016 14:31:58 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6984512D8B5 for ; Wed, 4 May 2016 14:31:58 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 902FCE8241; Wed, 4 May 2016 15:41:36 -0600 (MDT) To: Christian Schudt , precis@ietf.org References: <3A5E5283-7BCC-41DA-A183-6872695D91DC@gmx.de> From: Peter Saint-Andre Message-ID: <572A6A4C.8080102@stpeter.im> Date: Wed, 4 May 2016 15:31:56 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <3A5E5283-7BCC-41DA-A183-6872695D91DC@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [precis] U+212B (ANGSTROM SIGN) in Usernames X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 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, 04 May 2016 21:31:59 -0000 Hi Christian, thanks for your input. Please accept my apologies for the seriously delayed reply. On 11/21/15 6:12 AM, Christian Schudt wrote: > Hi, > > can you please help answering the following question: > > When doing enforcement of a string of the UsernameCaseMappedProfile > as per RFC 7613 § 3.2.2 and the string contains U+212B (ANGSTROM > SIGN), I would first do the preparation and it would be disallowed by > the IdentifierClass because it has a compatibility equivalent (which > is U+00C5 LATIN CAPITAL LETTER A WITH RING ABOVE). > > However, if I stick to the order rules specified in the Precis Core > Framework (RFC 7564 § 7), the string would first be normalized with > NFC (RFC 7613 § 4.2.2.4), becoming U+00C5, and then later would pass > the IdentifierClass check. > > If I stick to the rules in RFC 7613 § 3.2.2, such a string would be > disallowed. If I stick to the rules in RFC 7564 § 7, it would be > allowed. > > What’s correct behavior? > > Preparation (RFC 7613 § 3.2.1) has introduced a workaround for the > HasCompat issue, but only for full- and halfwidth characters (which > U+212B is not). > > Generally I don’t understand why RFC 7613 violates the order of rules > (compared to RFC 7564 § 7): Doing the preparation (checking the > IdentifierClass) first as opposed to do it after the normalization. As hinted in the message I just sent to the PRECIS list, I think that using the order of operations specified in RFC 7564 is the right thing to do during enforcement and comparison because (a) the IdentifierClass is supposed to be a "safe" choice for things like usernames and (b) we don't want to willfully violate the "Principle of Least Astonishment" (U+212B looks and behaves like U+00C5 and in fact is canoniclaly equivalent to U+00C5). Thus my inclination is to treat this as a spec bug in RFC 7613, by which I mean that for enforcement and comparison in 7613bis we would follow the order of operations specified in RFC 7564; this would imply that U+212B would be mapped to U+00C5 (which was also the result of applying SASLprep in accordance with RFC 4013). Or so it seems to me. Peter From nobody Wed May 4 15:27:32 2016 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 9F12C12D655 for ; Wed, 4 May 2016 15:27:30 -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=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 VG9e-Zbx1Uoo for ; Wed, 4 May 2016 15:27:28 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 9084E12D923 for ; Wed, 4 May 2016 15:27:28 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id x7so34179612qkd.3 for ; Wed, 04 May 2016 15:27:28 -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:content-transfer-encoding; bh=manMWK7vaKyJtOpnvcAhqKXJOCjlg3YHnNLXkFNLx5o=; b=hjO/V0OtZO/Jzj97nKGLBHxOdp8xcM1omaYzvSJBsJb1wjLtcyev2Z18y+1ZmSVVxd Pyio3qMXfw1FHNuEfS8YTUwB14XYZ3klhUlxzjRBWlfVtZ3gHslbj7r91iXFFuwG0phk /fxbJZDHP1bsEl4rCNAd9ac9PiIH6wlANuE4Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=manMWK7vaKyJtOpnvcAhqKXJOCjlg3YHnNLXkFNLx5o=; b=UZXkOqt1IzPFEjEOcnqDsz9XgGLIJA7GEJtJqk6/v6ckMDDlOLutVO3HRocWaM0TAx /LhqnjskcN/Tts7dcg5kw/B10QJ38UiwDG1n7T0lULUIaF1uY+hQe/fGhPStb8lH9zJ1 XeCHHbMWjEXfrnsFwkZFldriFXp8R6H4DieU3CjYbmuXaw4lUiQHBKISizeyHRTMh5Vp 5BR3Zpa2Je2YU/e3290nHTqEHZoXCOw4G2J1JabtiG2AF2YjrXSSzQ1+KGfTFaPce53Q blaJaZ4FRuUFdNItPgscwMljTy0/RTa6Hzlu7rIIdUpaYH5G+kEUx31POZ6tYjgTW91c YiDg== X-Gm-Message-State: AOPr4FUl7C4qqAG9n4QouBA1pE2LWCuOTny15QPFH5LWplXKgDSlvgfbVOzaPrTd/sZN40gs3IjLphI2AadUZQ== X-Received: by 10.55.23.164 with SMTP id 36mr11840359qkx.149.1462400847195; Wed, 04 May 2016 15:27:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.197.132 with HTTP; Wed, 4 May 2016 15:26:47 -0700 (PDT) X-Originating-IP: [72.48.156.244] In-Reply-To: <572A5FB7.9000305@stpeter.im> References: <20160301221928.17792.35793.idtracker@ietfa.amsl.com> <1C1668EA-1734-4D90-82E6-3894ECB6407C@viagenie.ca> <56D61E27.40000@stpeter.im> <56F96A20.7030509@stpeter.im> <572A5FB7.9000305@stpeter.im> From: Sam Whited Date: Wed, 4 May 2016 17:26:47 -0500 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: precis@ietf.org Subject: Re: [precis] order of operations (was: Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 22:27:30 -0000 On Wed, May 4, 2016 at 3:46 PM, Peter Saint-Andre wrot= e: > There's also the question of whether preparation / pre-processing is all > that useful. We added it so that constrained clients (e.g., clients that > can't realistically perform normalization) could avoid most of the proble= ms > associated with having their strings rejected by a more powerful server t= hat > actually does enforcement and comparison. Whether we really need to consi= der > such applications is another story. I'd be curious to know a "real world" use case for the preparation step optimization where enforcement is prohibitively expensive and comparison is not necessary (since comparison necessitates enforcement)? While benchmarking the implementation I did for Go I decided that it wasn't necessary to include a preparation step. Even on a heavily resource constrained server the enforcement step was easy to run concurrently or in parallel, and was very fast, even in its unoptimized form (most of the time spent in the algorithm was on memory allocation, which could easily be reduced). You can't count on concurrency or parallelism in all systems of course, but since it also wasn't all that time complex my suspicion is that the preparation step is premature optimization even on synchronous systems (although I haven't actually tested this). =E2=80=94Sam --=20 Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com From nobody Wed May 4 15:43:09 2016 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 D646612D913 for ; Wed, 4 May 2016 15:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-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 SnhiWANkIcyl for ; Wed, 4 May 2016 15:43:06 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3623612D673 for ; Wed, 4 May 2016 15:43:06 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8C082E8241; Wed, 4 May 2016 16:52:44 -0600 (MDT) To: "precis@ietf.org" From: Peter Saint-Andre Message-ID: <572A7AF9.3050903@stpeter.im> Date: Wed, 4 May 2016 16:43:05 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [precis] toLower() vs. toCaseFold() X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 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, 04 May 2016 22:43:08 -0000 In a previous thread, we (mostly John) discussed the relative desirability of using toLower() vs. toCaseFold(); see for instance: https://www.ietf.org/mail-archive/web/precis/current/msg01158.html https://www.ietf.org/mail-archive/web/precis/current/msg01159.html I suggested that we add some text about this to 7564bis. Here is a proposed paragraph for insertion in §5.2.3 ("Case-Mapping Rule"): The Unicode toCaseFold() operation defined by the Unicode Default Case Folding algorithm is most appropriate when an application needs to compare two strings. When an application merely wishes to convert uppercase and titlecase code points to the lowercase equivalents while preserving lowercase code points, the Unicode toLower() operation is more appropriate and is less likely to violate the "Principle of Least Astonishment". Therefore, application developers are advised to carefully consider whether they truly need to use the toCaseFold() operation in a given situation, or whether the toLower() operation would be more appropriate than the toCaseFold() operation. Suggestions for improvement are welcome, especially from John. (E.g., we might want to more explicitly call out comparison vs. other contexts in the normative text elsewhere in §5.2.3). Thanks, Peter From nobody Wed May 4 15:52:23 2016 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 576CB12D5B7 for ; Wed, 4 May 2016 15:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-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 Wvzfl1t5C-el for ; Wed, 4 May 2016 15:52:21 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id EAF8912D5A3 for ; Wed, 4 May 2016 15:52:20 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 68F98E8241; Wed, 4 May 2016 17:01:59 -0600 (MDT) To: Sam Whited References: <20160301221928.17792.35793.idtracker@ietfa.amsl.com> <1C1668EA-1734-4D90-82E6-3894ECB6407C@viagenie.ca> <56D61E27.40000@stpeter.im> <56F96A20.7030509@stpeter.im> <572A5FB7.9000305@stpeter.im> From: Peter Saint-Andre Message-ID: <572A7D23.4080404@stpeter.im> Date: Wed, 4 May 2016 16:52:19 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: precis@ietf.org Subject: Re: [precis] order of operations X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 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, 04 May 2016 22:52:22 -0000 On 5/4/16 4:26 PM, Sam Whited wrote: > On Wed, May 4, 2016 at 3:46 PM, Peter Saint-Andre wrote: >> There's also the question of whether preparation / pre-processing is all >> that useful. We added it so that constrained clients (e.g., clients that >> can't realistically perform normalization) could avoid most of the problems >> associated with having their strings rejected by a more powerful server that >> actually does enforcement and comparison. Whether we really need to consider >> such applications is another story. > > I'd be curious to know a "real world" use case for the preparation > step optimization where enforcement is prohibitively expensive and > comparison is not necessary (since comparison necessitates > enforcement)? The original suggestion (some years ago now) was browser-based clients that could not easily download the entire Unicode character database from a web server to the browser in order to do enforcement or comparison, but which could do something simpler like allow a user to create a username using a restricted repertoire of characters such as ASCII or "extended Latin". Another example might be IoT clients running on microcontrollers with very limited memory and processor speed. However, I have not seen benchmarks for such applications with respect to handling of internationalized strings. > While benchmarking the implementation I did for Go I > decided that it wasn't necessary to include a preparation step. Even > on a heavily resource constrained server Right, we've always figured that servers have more horsepower. Peter From nobody Wed May 4 18:19:16 2016 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 916D712D629 for ; Wed, 4 May 2016 18:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-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 FINmmaAEAazI for ; Wed, 4 May 2016 18:19:12 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B596A12D9C0 for ; Wed, 4 May 2016 18:19:12 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id ABE7141651; Wed, 4 May 2016 19:28:50 -0600 (MDT) To: Barry Leiba , RFC Errata System References: <20151220193202.24380180006@rfc-editor.org> From: Peter Saint-Andre Message-ID: <572A9F8D.2070701@stpeter.im> Date: Wed, 4 May 2016 19:19:09 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Peter Saint-Andre , precis@ietf.org Subject: Re: [precis] [Technical Errata Reported] RFC7564 (4568) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 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, 05 May 2016 01:19:14 -0000 Something along the lines of the proposed text makes sense to me, and I plan to incorporate such text into 7564bis. I might prefer slightly different wording, such as: o Preparation primarily entails ensuring that the characters in an individual string are allowed by the underlying PRECIS string class, and sometimes also entails applying one or more of the rules specified for a particular string class or profile thereof. Preparation can be appropriate for constrained devices that can to some extent restrict the characters in a string to a limited repertoire but that do not have the processing power or onboard memory to perform operations such as Unicode normalization. However, preparation does not ensure that an input string conforms to all of the rules for a string class or profile thereof. Peter On 1/21/16 6:29 AM, Barry Leiba wrote: > Are there comments from the authors or working group on this errata report? > > Barry, ART AD > > > On Sun, Dec 20, 2015 at 2:32 PM, RFC Errata System > wrote: >> The following errata report has been submitted for RFC7564, >> "PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=7564&eid=4568 >> >> -------------------------------------- >> Type: Technical >> Reported by: Sam Whited >> >> Section: 3 >> >> Original Text >> ------------- >> Preparation entails only ensuring that the characters in an >> individual string are allowed by the underlying PRECIS string >> class. >> >> Corrected Text >> -------------- >> Preparation entails applying some or none of the rules specified for a >> particular string class or profile thereof to an individual string, and >> ensuring that characters in the resulting string are allowed by the >> underlying PRECIS string class. >> >> Notes >> ----- >> The original text makes it sound like preparation is ONLY validating that the characters in a string are allowed in the underlying PRECIS string class, however, some profiles (for example, see the UsernameCaseMapped profile) specify that some of the rules must be applied first (in the case of UsernameCaseMapped, preparation includes first applying the Width rule). >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC7564 (draft-ietf-precis-framework-23) >> -------------------------------------- >> Title : PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols >> Publication Date : May 2015 >> Author(s) : P. Saint-Andre, M. Blanchet >> Category : PROPOSED STANDARD >> Source : Preparation and Comparison of Internationalized Strings APP >> Area : Applications >> Stream : IETF >> Verifying Party : IESG >> From nobody Wed May 4 18:26:40 2016 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 D3D7312B00F for ; Wed, 4 May 2016 18:26:38 -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, HTML_MESSAGE=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 (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 4hSdspZ1VbdX for ; Wed, 4 May 2016 18:26:37 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (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 2EEC112D18F for ; Wed, 4 May 2016 18:26:37 -0700 (PDT) Received: by mail-qg0-x230.google.com with SMTP id 90so33229810qgz.1 for ; Wed, 04 May 2016 18:26:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samwhited.com; s=swgoo; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=G+SJFR4LGM8bOTi3Iw5JF2ggrVF2zDWnyGMpz38gM90=; b=x7fayxfkcq4CRQNKfPVtezecp8QSfCL03NB6lfYDY6EyDnPq7l01rN6T2hCjeWFr6c pY2zl2vMKk50ZaTjsneuZSJ5gwyZ9zHy5SkQTvYcBK9uU4FPScnpamx2KBX8aGj6CZqc VcQAMY5LT6E0v7PNPFso0bBNGJNHxr9SppWHw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=G+SJFR4LGM8bOTi3Iw5JF2ggrVF2zDWnyGMpz38gM90=; b=kw5QeA/l5zVGAayP3/HMCc5rZy78vZZ3bCO8q4UX/DeM6pD3N4SMEjqCUW/e4CV/qo k3mmvucmJp2UAf+q27j4bTay+GC7ChZovrXDhbA76p8POH4ygP8j6tif/gh2o0fbfdiL Bx444Sdg91fA3fUAoUbiIkb7myDWqWwv+OaTATT71AlwYlhsmgaqdKzlWABOrtC2fPnB pEOd9Rn6A05SKrOZWAbe3E/ycfLbUUabfhJtg7DxK0KZCAy7IsUfgSMjrRbh9YsOHUEW sAQ+8Tl+4XFSmwPpzsVhMC99t2rPCZOLVt+h/BpFdzF3hUoYB1GsyQEWdklbol3KE+z+ 5wVQ== X-Gm-Message-State: AOPr4FUAU9NKqpIABzPBpf5VnsR20Odai6jJMYKlucith8OfelhOqY3ChBn5kprAkLTvA4nVsUDCf5dG9uUzRA== MIME-Version: 1.0 X-Received: by 10.140.133.5 with SMTP id 5mr93885qhf.19.1462411596352; Wed, 04 May 2016 18:26:36 -0700 (PDT) Received: by 10.55.197.132 with HTTP; Wed, 4 May 2016 18:26:35 -0700 (PDT) X-Originating-IP: [2607:fb90:1c3d:b3e2:5ef3:cd5a:b1d2:465e] Received: by 10.55.197.132 with HTTP; Wed, 4 May 2016 18:26:35 -0700 (PDT) In-Reply-To: <572A9F8D.2070701@stpeter.im> References: <20151220193202.24380180006@rfc-editor.org> <572A9F8D.2070701@stpeter.im> Date: Wed, 4 May 2016 20:26:35 -0500 Message-ID: From: Sam Whited To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=001a1135df9ab768a405320e3bcc Archived-At: Cc: Peter Saint-Andre , precis@ietf.org, Barry Leiba , RFC Errata System Subject: Re: [precis] [Technical Errata Reported] RFC7564 (4568) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 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, 05 May 2016 01:26:39 -0000 --001a1135df9ab768a405320e3bcc Content-Type: text/plain; charset=UTF-8 On May 4, 2016 20:19, "Peter Saint-Andre" wrote: > I might prefer slightly different wording, such as: > > o Preparation primarily entails ensuring that the characters in an > > individual string are allowed by the underlying PRECIS string > class, and sometimes also entails applying one or more of the > rules specified for a particular string class or profile thereof. > Preparation can be appropriate for constrained devices that can to > some extent restrict the characters in a string to a limited > repertoire but that do not have the processing power or onboard > memory to perform operations such as Unicode normalization. > However, preparation does not ensure that an input string conforms > to all of the rules for a string class or profile thereof. That sounds very clear to me and addresses my concerns. Best, Sam --001a1135df9ab768a405320e3bcc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On May 4, 2016 20:19, "Peter Saint-Andre" <stpeter@stpeter.im> wrote:
> I might prefer slightly different wording, such as:
>
> =C2=A0 =C2=A0o=C2=A0 Preparation primarily entails ensuring that the c= haracters in an
>
> =C2=A0 =C2=A0 =C2=A0 individual string are allowed by the underlying P= RECIS string
> =C2=A0 =C2=A0 =C2=A0 class, and sometimes also entails applying one or= more of the
> =C2=A0 =C2=A0 =C2=A0 rules specified for a particular string class or = profile thereof.
> =C2=A0 =C2=A0 =C2=A0 Preparation can be appropriate for constrained de= vices that can to
> =C2=A0 =C2=A0 =C2=A0 some extent restrict the characters in a string t= o a limited
> =C2=A0 =C2=A0 =C2=A0 repertoire but that do not have the processing po= wer or onboard
> =C2=A0 =C2=A0 =C2=A0 memory to perform operations such as Unicode norm= alization.
> =C2=A0 =C2=A0 =C2=A0 However, preparation does not ensure that an inpu= t string conforms
> =C2=A0 =C2=A0 =C2=A0 to all of the rules for a string class or profile= thereof.

That sounds very clear to me and addresses my concerns.

Best,
Sam

--001a1135df9ab768a405320e3bcc-- From nobody Wed May 4 18:48:17 2016 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 6EBE812B044 for ; Wed, 4 May 2016 18:48:15 -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, HTML_MESSAGE=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 (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 3nMctZOETSjv for ; Wed, 4 May 2016 18:48:13 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (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 7F62312D0EA for ; Wed, 4 May 2016 18:48:13 -0700 (PDT) Received: by mail-qg0-x22f.google.com with SMTP id f74so33433627qge.2 for ; Wed, 04 May 2016 18:48:13 -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=ez2ossLv+WYjmN2WsQX6kLtl5mYcA4Ev1SoeSTe5MZA=; b=jfdfrKj4HME2NMoVK+bBsVxI/sJZqcBflYtF53lclVSjV1Uax+eOysBtvXMXMwH9Hc 3oQFt7p5ge5PUVQffNZCl7+9GW28r5uePmWt7wE/H3fAaL+b0NY7zL/6oHK2by7+p4eK hS+8XfNdYuKabfRiXWlK+fkrYQERRaWRyH46c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ez2ossLv+WYjmN2WsQX6kLtl5mYcA4Ev1SoeSTe5MZA=; b=YsyGKXdX23nw4yqImlAIMZAkBqmjEjjdR9Dpx4Arv3UWytkwinPINQFRV7A2qDj25W f1xLgQwlN3V3Tmr/mhJaWKOHNnMSS4UmtN8ZAceBiroZdhtq5rmuktIcvBYkxdAbThJh 2s8KQmQGndexpAi3fpp2N7uovxGSFHt+IZUiRLEr81lcITNQHwFCr7g7R5sVSUQJ/g3F 7pt9z+/y4rDRObieHc06QG0X4Ajs/NSqrhSj8gTQIZv/gT1d7gefE/uAKLAu5ExZDGzD E33SqFDx9+LZTXXFykWMK52RkxPPnoaoBekvowLPsSM7BaLkOtkqNBgN34y36NFYobHj /D7w== X-Gm-Message-State: AOPr4FVwFivVgs3LBaZiVBnHVreBpGm+ufwwu+adBJSYgHqw0VTX0jnE10ZAhU+Kdx6gz8kZ6+6pgcM01/wCxA== X-Received: by 10.140.133.5 with SMTP id 5mr157315qhf.19.1462412892678; Wed, 04 May 2016 18:48:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.197.132 with HTTP; Wed, 4 May 2016 18:47:33 -0700 (PDT) X-Originating-IP: [208.54.86.205] In-Reply-To: <572A7D23.4080404@stpeter.im> References: <20160301221928.17792.35793.idtracker@ietfa.amsl.com> <1C1668EA-1734-4D90-82E6-3894ECB6407C@viagenie.ca> <56D61E27.40000@stpeter.im> <56F96A20.7030509@stpeter.im> <572A5FB7.9000305@stpeter.im> <572A7D23.4080404@stpeter.im> From: Sam Whited Date: Wed, 4 May 2016 20:47:33 -0500 Message-ID: To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=001a1135df9afbbaf805320e8842 Archived-At: Cc: precis@ietf.org Subject: Re: [precis] order of operations X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 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, 05 May 2016 01:48:15 -0000 --001a1135df9afbbaf805320e8842 Content-Type: text/plain; charset=UTF-8 On May 4, 2016 17:52, "Peter Saint-Andre" wrote: > The original suggestion (some years ago now) was browser-based clients that could not easily download the entire Unicode character database from a web server to the browser in order to do enforcement or comparison, That makes sense; the trie I use to store the derived properties for all of Unicode 8.0.0 is 23 KB in memory (it would be a bit bigger over the wire; though there's also room for improvement there). This seems reasonable at first glance, however, a similar structure for normalization ends up being 53 KB, and the one for width mapping is 11 KB; I suppose it begins to add up quickly if you're on a slow connection I suppose it comes down to a trade off between complexity and portability; I'm not sure which makes the most sense in this case. Best, Sam --001a1135df9afbbaf805320e8842 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On May 4, 2016 17:52, "Peter Saint-Andre" <stpeter@stpeter.im> wrote:
> The original suggestion (some years ago now) was browser-based clients= that could not easily download the entire Unicode character database from = a web server to the browser in order to do enforcement or comparison,

That makes sense; the trie I use to store the derived proper= ties for all of Unicode 8.0.0 is 23 KB in memory (it would be a bit bigger = over the wire; though there's also room for improvement there). This se= ems reasonable at first glance, however, a similar structure for normalizat= ion ends up being 53 KB, and the one for width mapping is 11 KB; I suppose = it begins to add up quickly if you're on a slow connection

I supp= ose it comes down to a trade off between complexity and portability; I'= m not sure which makes the most sense in this case.


Best,<= /p>

Sam

--001a1135df9afbbaf805320e8842-- From nobody Wed May 4 19:04:51 2016 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 78C1512D0EA for ; Wed, 4 May 2016 19:04:50 -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=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 qSxzs5ysdXEI for ; Wed, 4 May 2016 19:04:48 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::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 556A012B074 for ; Wed, 4 May 2016 19:04:48 -0700 (PDT) Received: by mail-qg0-x233.google.com with SMTP id f74so33573255qge.2 for ; Wed, 04 May 2016 19:04:47 -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=sqWISlrCcP2ah58cZnTwdOKXPuqcTRlD6BfbZcveJbU=; b=vjHrSGbu0lt6FPPjhQedJVMNUUrmBIWuyDuc4TKAcTO9/qYV0OGZa15be9PMWJ6+qV WkzpARFLhzRx1QMqpV0CTiIisCDCbsWj9NsyNwoX4g7wncFc1IwXnvK/D8vo7ukDVyDE vYhvfqCnnmGn9kn1MTwTz32MuQdOzLTAfLTZE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sqWISlrCcP2ah58cZnTwdOKXPuqcTRlD6BfbZcveJbU=; b=PLwjhWb7nKsTDxcEQqUVsLEETlkUkN0jixUsuYGjlgkfnbSYfC50i0gPOCWb3xt9Ha QScfYQoWCOErmG8JTS1oPUfNg8pumLHcw27i23tPlndDu5ybkQuQptpTOlevLZOXW+aI stlKYrQnB2wGOtLboGIFYb1OKblIqBpe+ce3VxgOdxq+Vq1p9fYsgZDy4YkyRfSRXEEB 8SNEyzYdU6FM8p6XicVJimbX92tBoIBkhtyLJ/OugNoNVWgsDkuhGdx10FqdJXlaAsLS 7vxdj587sX1sUM+NY8CgLcqGed09oBIS7mrbcbJkd8ao4iWGnURRsFdN2gKuJeV8qlSp fwxw== X-Gm-Message-State: AOPr4FV0CZg1bqCRZ2g1UZWqz6l7ToKINvIGiRgZ1kY9GpVz7uO3Xyu1ijPngDu2wWSWJhZmZw5G9YkT2Y0FGw== X-Received: by 10.140.101.137 with SMTP id u9mr11643062qge.92.1462413887099; Wed, 04 May 2016 19:04:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.197.132 with HTTP; Wed, 4 May 2016 19:04:07 -0700 (PDT) X-Originating-IP: [208.54.86.205] In-Reply-To: <572A39EC.8070204@stpeter.im> References: <572A39EC.8070204@stpeter.im> From: Sam Whited Date: Wed, 4 May 2016 21:04:07 -0500 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: precis@ietf.org Subject: Re: [precis] Test Vectors X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 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, 05 May 2016 02:04:50 -0000 On Wed, May 4, 2016 at 1:05 PM, Peter Saint-Andre wrote: > This sounds useful. Submitting it as an individual Internet-Draft > (draft-whited-precis-test-vectors-00) is the best first step. That enables > the working group to determine if the document is suitable for adoption as a > working group item. I'd be happy to help you in your work on this document. Thanks Peter, I've started outlining a draft here: http://samwhited.bitbucket.org/rfcs/draft-whited-precis-token.nroff Best, Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com From nobody Thu May 5 09:57:58 2016 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 7518B12D527 for ; Thu, 5 May 2016 09:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-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 PG3NuaXERFYm for ; Thu, 5 May 2016 09:57:56 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 04EEC12D1B2 for ; Thu, 5 May 2016 09:57:55 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3A77441669; Thu, 5 May 2016 11:07:37 -0600 (MDT) To: Sam Whited References: <20160301221928.17792.35793.idtracker@ietfa.amsl.com> <1C1668EA-1734-4D90-82E6-3894ECB6407C@viagenie.ca> <56D61E27.40000@stpeter.im> <56F96A20.7030509@stpeter.im> <572A5FB7.9000305@stpeter.im> <572A7D23.4080404@stpeter.im> From: Peter Saint-Andre Message-ID: <572B7B92.9050703@stpeter.im> Date: Thu, 5 May 2016 10:57:54 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: precis@ietf.org Subject: Re: [precis] order of operations X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 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, 05 May 2016 16:57:57 -0000 On 5/4/16 7:47 PM, Sam Whited wrote: > On May 4, 2016 17:52, "Peter Saint-Andre" > wrote: > > The original suggestion (some years ago now) was browser-based > clients that could not easily download the entire Unicode character > database from a web server to the browser in order to do enforcement or > comparison, > > That makes sense; the trie I use to store the derived properties for all > of Unicode 8.0.0 is 23 KB in memory (it would be a bit bigger over the > wire; though there's also room for improvement there). This seems > reasonable at first glance, however, a similar structure for > normalization ends up being 53 KB, and the one for width mapping is 11 > KB; I suppose it begins to add up quickly if you're on a slow connection That's an interesting approach. The person who originally brought this up (I think it was Joe Hildebrand) might have been thinking that a web client would need to import the entire UCD from a web server upon initial connection, which would be prohibitive. Peter From nobody Thu May 5 10:09:01 2016 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 5601F12D72D for ; Thu, 5 May 2016 10:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 pWd56_sgc0Dl for ; Thu, 5 May 2016 10:08:57 -0700 (PDT) Received: from babelmonkeys.de (babelmonkeys.de [IPv6:2a02:d40:3:1:10a1:5eff:fe52:509]) by ietfa.amsl.com (Postfix) with ESMTP id 8F64A12D6EF for ; Thu, 5 May 2016 10:08:57 -0700 (PDT) Received: from [IPv6:2001:4dd0:2019:913:7d31:cb95:4ca7:ffb4] (2001-4dd0-2019-913-7d31-cb95-4ca7-ffb4.ipv6dyn.netcologne.de [IPv6:2001:4dd0:2019:913:7d31:cb95:4ca7:ffb4]) by babelmonkeys.de (Postfix) with ESMTPSA id 149CB101051B1 for ; Thu, 5 May 2016 19:08:56 +0200 (CEST) To: precis@ietf.org References: <572A39EC.8070204@stpeter.im> From: Florian Zeitz Message-ID: <3e1df3b5-e2bc-3450-297c-596ea6ae88c5@babelmonkeys.de> Date: Thu, 5 May 2016 19:08:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [precis] Test Vectors X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 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, 05 May 2016 17:09:00 -0000 Am 05.05.2016 um 04:04 schrieb Sam Whited: > On Wed, May 4, 2016 at 1:05 PM, Peter Saint-Andre wrote: >> This sounds useful. Submitting it as an individual Internet-Draft >> (draft-whited-precis-test-vectors-00) is the best first step. That enables >> the working group to determine if the document is suitable for adoption as a >> working group item. I'd be happy to help you in your work on this document. > > Thanks Peter, > > I've started outlining a draft here: > http://samwhited.bitbucket.org/rfcs/draft-whited-precis-token.nroff > I presume you meant to link or . As an aside, I personally think programming language identifiers are sufficiently covered by UAX # 31 . I'd expect any I-D in this direction to reference it and/or discuss it's deficiencies. Regards, Florian Zeitz From nobody Thu May 5 10:42:37 2016 Return-Path: X-Original-To: precis@ietf.org Delivered-To: precis@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D7212D6E7; Thu, 5 May 2016 10:42:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160505174234.20632.12476.idtracker@ietfa.amsl.com> Date: Thu, 05 May 2016 10:42:34 -0700 Archived-At: Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-7564bis-01.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 17:42:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Preparation and Comparison of Internationalized Strings of the IETF. Title : PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols Authors : Peter Saint-Andre Marc Blanchet Filename : draft-ietf-precis-7564bis-01.txt Pages : 40 Date : 2016-05-05 Abstract: Application protocols using Unicode characters in protocol strings need to properly handle such strings in order to enforce internationalization rules for strings placed in various protocol slots (such as addresses and identifiers) and to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation, enforcement, and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode characters and thus is agile with respect to versions of Unicode. As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454). This document obsoletes RFC 7564. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-7564bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-precis-7564bis-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-precis-7564bis-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 5 10:42:52 2016 Return-Path: X-Original-To: precis@ietf.org Delivered-To: precis@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D05E212D7E4; Thu, 5 May 2016 10:42:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160505174244.20612.16872.idtracker@ietfa.amsl.com> Date: Thu, 05 May 2016 10:42:44 -0700 Archived-At: Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-7613bis-01.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 17:42:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Preparation and Comparison of Internationalized Strings of the IETF. Title : Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords Authors : Peter Saint-Andre Alexey Melnikov Filename : draft-ietf-precis-7613bis-01.txt Pages : 25 Date : 2016-05-05 Abstract: This document describes updated methods for handling Unicode strings representing usernames and passwords. The previous approach was known as SASLprep (RFC 4013) and was based on stringprep (RFC 3454). The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords. The preparation, enforcement, and comparison of internationalized strings (PRECIS) framework, RFC 7564, obsoletes RFC 3454, and this document obsoletes RFC 7613. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-7613bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-precis-7613bis-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-precis-7613bis-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 5 10:43:11 2016 Return-Path: X-Original-To: precis@ietf.org Delivered-To: precis@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA7712D7F0; Thu, 5 May 2016 10:42:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160505174255.20595.13753.idtracker@ietfa.amsl.com> Date: Thu, 05 May 2016 10:42:55 -0700 Archived-At: Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-7700bis-01.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 17:42:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Preparation and Comparison of Internationalized Strings of the IETF. Title : Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames Author : Peter Saint-Andre Filename : draft-ietf-precis-7700bis-01.txt Pages : 11 Date : 2016-05-05 Abstract: This document describes methods for handling Unicode strings representing memorable, human-friendly names (called "nicknames", "display names", or "petnames") for people, devices, accounts, websites, and other entities. This document obsoletes RFC 7700. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-7700bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-precis-7700bis-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-precis-7700bis-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 5 10:45:11 2016 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 9802B12D7F1 for ; Thu, 5 May 2016 10:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-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 ZCvP4lMHCU2U for ; Thu, 5 May 2016 10:45:09 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0D71C12D764 for ; Thu, 5 May 2016 10:45:05 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DFBF1E8244; Thu, 5 May 2016 11:54:46 -0600 (MDT) To: "precis@ietf.org" From: Peter Saint-Andre Message-ID: <572B86A0.3030809@stpeter.im> Date: Thu, 5 May 2016 11:45:04 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [precis] -01 I-Ds X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 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, 05 May 2016 17:45:10 -0000 In the interest of moving forward, I've posted revised I-Ds for 7564bis, 7613bis, and 7700bis. We still have some list discussions going on, so these are interim versions. Keep that feedback coming! Peter From nobody Thu May 5 10:50:00 2016 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 6EA0612D0A2 for ; Thu, 5 May 2016 10:49:58 -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=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 ir3OvNbjQkVo for ; Thu, 5 May 2016 10:49:56 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (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 7AC9F12D1DA for ; Thu, 5 May 2016 10:49:56 -0700 (PDT) Received: by mail-qg0-x22b.google.com with SMTP id w36so43803374qge.3 for ; Thu, 05 May 2016 10:49:56 -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=mIKHbq7bKvizBPSI7ZMQOfc0MvejbtMkZraNOI6WCaw=; b=Sn6oxlhi81BK1hQN7bfr+IhAviFAKf/Fbcf9NmHPC1u0De2h+SmC9V0tFZaEwNXCby XRbqTz5bpgrUmB63lngF5UbLvru5hIDd98AndX03Y8rjC+l2IWU2MKm8BEkwcTH1psAm nHLMHE4HR/Fm1odgUls9uoQhrbZ0IJz59lVRc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mIKHbq7bKvizBPSI7ZMQOfc0MvejbtMkZraNOI6WCaw=; b=ClnBzJrNI2+lWbm0bTwedeWPNygUXNo7gaHAaO8t3103Oc7WSU2Lh6DYmr00qJNBBT vOPL0QBzxh1C5rsreeBEhRgxH+0GccrDEoh1kBA/s7ixQeTVyMJsXKBF4w6jU5no8GJ9 eCDEUzBetGnjRgW8Lsk0+W2O7OB0K8HmlnY1QMlm7EQAGxWLXibNEzNktM1O4KAW/Iir eTGZGYZqcYH3dSV2riaBUOw8B8wrkeTgUGwfO3WOUVMPEZbPJxARPGVrJjgrkCRtT5ss 5ZOQ2LVR0h9wdqmnwuNagXOx8ZYs5P02IOAPSgqLAUgPfNoVIWlugVsM/6GcYiuQjvx8 j8Wg== X-Gm-Message-State: AOPr4FXDdTmwjwxQ0XcRggUUAx3KYsuM3pd2q/m9N8Pyt9RhoKJqJt1KASsMRssyHDyU1puzCppwgljDpVaGfg== X-Received: by 10.140.37.35 with SMTP id q32mr15421246qgq.17.1462470595602; Thu, 05 May 2016 10:49:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.197.132 with HTTP; Thu, 5 May 2016 10:49:16 -0700 (PDT) X-Originating-IP: [72.48.156.244] In-Reply-To: <3e1df3b5-e2bc-3450-297c-596ea6ae88c5@babelmonkeys.de> References: <572A39EC.8070204@stpeter.im> <3e1df3b5-e2bc-3450-297c-596ea6ae88c5@babelmonkeys.de> From: Sam Whited Date: Thu, 5 May 2016 12:49:16 -0500 Message-ID: To: Florian Zeitz Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: precis@ietf.org Subject: Re: [precis] Test Vectors X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 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, 05 May 2016 17:49:58 -0000 On Thu, May 5, 2016 at 12:08 PM, Florian Zeitz wrote: > I presume you meant to link > > or > . Oops, sorry about that, you're correct, of course. > As an aside, I personally think programming language identifiers are > sufficiently covered by UAX # 31 . > I'd expect any I-D in this direction to reference it and/or discuss it's > deficiencies. Thanks, I hadn't read that report. I'm not sure that particular draft is something I'm going to continue with anyways; it was intended to be an improvement on the current situation in Go (and hopefully useful by other languages). If I ever pick it back up I'll make sure to take that report into account. Best, Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com From nobody Thu May 5 23:13:29 2016 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 602C612D4FF for ; Thu, 5 May 2016 23:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.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 B81OB-urvD2X for ; Thu, 5 May 2016 23:13:25 -0700 (PDT) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-hk2apc01on0104.outbound.protection.outlook.com [104.47.124.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BA3312D550 for ; Thu, 5 May 2016 23:13:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EjJSQ8Bd53nqGLZGaI+UYpIylG3oPfGm2GM2LVPeEvM=; b=TJ1A7o6NIbfVO1AJVvdUNqVFiMBTHrce2C1WFOoXW9ySdNo5D3nlfN/OAsZyEpco8ivaIKztLEhAi/Tq6VTVjzQPlVMh3todgvtkBNa/1NjrT3EKLInAefiXVj0vbBkn+iyFbMSHi6fZfkgla58oM+UKj6GOEvYWy2ZfFhqcxFY= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by TY1PR01MB0922.jpnprd01.prod.outlook.com (10.167.156.152) with Microsoft SMTP Server (TLS) id 15.1.492.11; Fri, 6 May 2016 06:13:22 +0000 To: Peter Saint-Andre , Sam Whited References: <20160301221928.17792.35793.idtracker@ietfa.amsl.com> <1C1668EA-1734-4D90-82E6-3894ECB6407C@viagenie.ca> <56D61E27.40000@stpeter.im> <56F96A20.7030509@stpeter.im> <572A5FB7.9000305@stpeter.im> <572A7D23.4080404@stpeter.im> <572B7B92.9050703@stpeter.im> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: Date: Fri, 6 May 2016 15:13:21 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <572B7B92.9050703@stpeter.im> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: KAWPR01CA0003.jpnprd01.prod.outlook.com (10.161.24.13) To TY1PR01MB0922.jpnprd01.prod.outlook.com (10.167.156.152) X-MS-Office365-Filtering-Correlation-Id: 74aa3c14-017b-41c5-ca95-08d375758714 X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0922; 2:pO/jYPOo3L7r77Q/oHl0x1M6HD56tl5zVHvzU34T+VJkgXz07V4B91bgAyKIE81PGE0MitJvIhbkuCt/GToxgPrXL+1wDKBtMFxn0luAPfZaAaoihBsfW0Z4MrX8/dXGLktnWzpLI5RgptWPrnYf81LsXrq0Psgelw44cXFMWPDmEh752JqhejxRy1ypeuZZ; 3:t8GKS4Fp+jq9GfSErqR4blu69dDEZeyCDyxEh9YuClu7wUexi8UM640OL8Irsl13Nz25G8Cy5QTcK989qvH3pNhvJPFivhk3iYfGi6cOD4DbuROlpJkw3lG27oyobzWd; 25:7LUMiCi6Xf+Z912LXJjhAePqhOCcVM0OIQ9DcqemP1SZFiEpLh7+9rVVrCqAhsYdiM0HNwonXFkr9GWfMAdRU9idvANZyt3RzpOGa4dqi9MBZct4W+OkWtJCo+eF+AzqofSB1+NuR3gbVSX4sQYDtX1l9nA05s/JyYu47nWrx5WlfP9qWK8GxGdzHFk8DwZhVkX/T5c0yanRc8YfGbteIt9K9Lbzeu2xHzzdAW62gIHKi77vYFRUysmEdrAnwtlIl+DpzwcbdNYAHmzmn0KS6ql+2NlK5o1FaWkK2b4gMFIpnbGU3xNtFCrvNaHNRixUU0OxeATWYMpQ9sz0uzN9cRL2S8Pm/Pen/M9Zv3FhUuV4ZU1FaybQ80QnVAeX9sBTN03QYOfNVqSzGZ22yrc8yaGmrXhg5E8muSl49LNpER1wqF4tOEWY5DwCXyjbX1vm X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TY1PR01MB0922; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040130)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041072)(6043046)(6042046); SRVR:TY1PR01MB0922; BCL:0; PCL:0; RULEID:; SRVR:TY1PR01MB0922; X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0922; 4:n4W7RVgDqPYEQBGEFe48S8EASHqD++Hv0h4pGZV2tYgIlSTGu4e13KrJz+y5ZPvUSOTMppiZ6ygs7J3YihqFr2/xLUqrVaTngTC/JPdqiA8Kt6+L5mSrAlbRM6B9eZwV57hsQ8bC2xmPs00w/PaYHh8g8DS6iaux6W0APrhjV4frjuQbBRK9fGEpvq3yuK8r4PLVq43BTDC9Wy0H4VSCDlfC/+7KjN/acqUc7hU4+3Y9jLpPG8DQftK7JU4y7WUd45xuL4AU6k1F3oLh8295t0wm0JhZsbz11ncpf2Mun7z67GiygzLudIbFJWhrz71nWKcaYlYbSqL/ZqfdpDUpBrq+kEKf9WjxJYEQ62NV0aLIeb4zm2+9NCFuLVvHg8bv8P10M/2NsjCJ40aLPG0X6bwoMIva6NC14P/BoURHsLs= X-Forefront-PRVS: 09347618C4 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(24454002)(377454003)(33646002)(5008740100001)(2950100001)(47776003)(23676002)(4326007)(5001770100001)(66066001)(65956001)(2906002)(64126003)(77096005)(5004730100002)(76176999)(50986999)(586003)(50466002)(54356999)(31686004)(42186005)(31696002)(189998001)(83506001)(230700001)(74482002)(6116002)(92566002)(86362001)(93886004)(81166005)(3846002)(65826006)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:TY1PR01MB0922; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWTFQUjAxTUIwOTIyOzIzOlBHWHNVOVBKcEhjeFNTazFldFV2Vkt3dytD?= =?utf-8?B?MGZYcTVMcklMRExrbHJ4aFVqVHd5SVFBZVdnTXBDZ1hHaE1TSnE3WnZ1OXVq?= =?utf-8?B?Y3hsaHdJSDFZUDUzb3N5L3JPaWNsa1M1UFdqZHQwRzZyQkxiU0tzTzlzZjdX?= =?utf-8?B?NkZvK0EwNHdwQ09EeFpLUkZIUENTekZZVnl5UWlpeXJNbERYaGdNT1VnbFlt?= =?utf-8?B?R2lBMUNkeE5WQWZ3dHFWL2JDbVJJQXN3a0dlWDViWmxhK20wQzdPL2ErNzZD?= =?utf-8?B?TGIzTkE0MkV6eE4zcWxtQVRiL2ZwOGtMa09xaThQenRETlhTYndHMDcvZW10?= =?utf-8?B?UDNQM1E4bFp3QkcrMUkva0Z0aWdGVks1TFNXaDNZSzdlcERDS01VV2NRL1J2?= =?utf-8?B?ZFhYNmR3aW5NS2NpOXlZWU9nSVBRWnRtSyt2Tm5GRUVDRG1NYkhHQ3Y3TWVK?= =?utf-8?B?N2F0OHNpZWVEZ1VTNTZmZjcwWnZOOURhU3pEUVZEaGtEdEkzTkpsNTlVRnlm?= =?utf-8?B?Y0lDTGlEN2dPbHhOTlRpOEthT0FxektTaUc0VktNVFlqZllyVExjQUtsZkNE?= =?utf-8?B?V08vYU9uWkg4VGZYQnZpZlRlQ2pRaDFTTTJ5MUdEL1NaMS94MjJhMEhZc3dC?= =?utf-8?B?L2wyTEl6Z2ZrMC9pMmhML0UxeFN2K1JPR1VVTXJHN1M3d0Zib1h0emVnbUc5?= =?utf-8?B?cEZrQnhmT2RhL1RZUUc2R01seUZYWVBMMklnbTJ4SkY4TUdUMG9mbzdvM3o4?= =?utf-8?B?SGQ2a2l4cU9VVEZzS09DU1VmRzhLNG0vNExGWVYwY21kbzExV3ZZRWZPeUtt?= =?utf-8?B?Ulk0UERoaGNIa2ZGMmhpaHEvOU1tRmFWbEIzRFQyRnVOVTZGYW9icGJ2U2U1?= =?utf-8?B?YXVESWJ6Q2JTc1loNXhUbHUvakJpVVQwVTZJTlRxZEl6cThHdlpBMW1zbFNL?= =?utf-8?B?OE1lQjl5d2hEYTVLcVd1MUM0RHJWR3RIYWtKZkRTTHRHaVpvK0pPb1NoV0ty?= =?utf-8?B?ZHMwcFR5emkvbURZVG9iTCtQQWNKOFpjRHhiTEFRZjExZm4wd1BVQUNMbWRp?= =?utf-8?B?U3p5b05weFkxKzY5WVA3dWpacXZ5TmRYamdRV0N3bGZwd2IvMFZaTXJYaURE?= =?utf-8?B?ei9yM0RoQTl4RTZ3TEpYTkdhT00zSldHcks5ZDQyM0pubWxpb0grOUE4TW56?= =?utf-8?B?SG1PUHV2K2hpTHBXQmFEOEVmbVg4cHlOUk94OHZiLzkyaDlJYkdEbEJSU3U0?= =?utf-8?B?TVc0NyszbEFoUTFEelo0RmtPYjc2bU1YUlNoaVkwMys0VzRma2Y0amFTOGNj?= =?utf-8?B?dk1aUGI0RGdPVTlOckRxSWdMUTZrY21tOWZQZ2VEc2gyUjg3bXl2cWhabko5?= =?utf-8?Q?vT9JHl8C?= X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0922; 5:q9pjW9CpfdQn3jsjHSbtErUTHZ4ibbcQTdugK8Dx+siH6449rBGCbUS7kRvqfRl4Ay6h1lD0qlaxfSGjoBlXMGopPTRnEturuo/WzOInMxvUOMoRfjsvgyvUQSEICDT7nF7Rld5/6zdPnAoJ1FBbsQ==; 24:puLZyaC3mPPBOm2L2yRC+RsLnVSC8v5+gVcC05FY7zyojhYR+D2+IMx+oatn+hqzOWYLdgHCJwJCQyeJRgWlGQJ97o0fDKqtY7dpfh45hyI=; 7:Ygu0Tw8KERblySrj7JWMWZy1W2G9TobOu/qSK+sulSCaCf2QDb8rB45k88B0cyJAgQsPMCEpJ1Ju/BjoscWGWZ1m8oKlALl42Z1TBKD14yVzuevSHU02uU7+lkI3SxESFMw8/vq24NnYvlUex/J692jDdGHDM95uX5RCvF8k6pp7KIr/VXglFc3RpZoXVcC7 SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 May 2016 06:13:22.6344 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB0922 Archived-At: Cc: precis@ietf.org Subject: Re: [precis] order of operations X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 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, 06 May 2016 06:13:28 -0000 On 2016/05/06 01:57, Peter Saint-Andre wrote: > On 5/4/16 7:47 PM, Sam Whited wrote: >> That makes sense; the trie I use to store the derived properties for all >> of Unicode 8.0.0 is 23 KB in memory (it would be a bit bigger over the >> wire; though there's also room for improvement there). This seems >> reasonable at first glance, however, a similar structure for >> normalization ends up being 53 KB, and the one for width mapping is 11 >> KB; I suppose it begins to add up quickly if you're on a slow connection Just for the record, I can definitely confirm the ballpark range of these figures, based on implementations of mine. Regards, Martin. From nobody Thu May 5 23:54:12 2016 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 6EE3012D7CD for ; Thu, 5 May 2016 23:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.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 6Ud9Yr7uzotZ for ; Thu, 5 May 2016 23:54:08 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0123.outbound.protection.outlook.com [104.47.93.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C49D12D517 for ; Thu, 5 May 2016 23:54:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BA1cbm4yRMmTT0t6CUAm3U6U3ECue0sOJgLKxHZ09NI=; b=FqEZUV7e5wei8z1wMAaSxD51h/hTfxW+KmFKXw3NAVk6ruGApk9ELHFbwrkveAZnJdwGSbn3J6GVLb2hiPDcwQ+9UGgvjttVy6o+o1COPDjfXXJU0zM/ZX5RQ4wfgukZYFCrkvzn23eRpvKcs8BnhzndS6aAk8SQY7OhCDnX6hY= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by TYXPR01MB0928.jpnprd01.prod.outlook.com (10.168.45.23) with Microsoft SMTP Server (TLS) id 15.1.485.9; Fri, 6 May 2016 06:54:02 +0000 To: Peter Saint-Andre , "precis@ietf.org" References: <572A7AF9.3050903@stpeter.im> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: Date: Fri, 6 May 2016 15:54:02 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <572A7AF9.3050903@stpeter.im> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: TY1PR0201CA0020.apcprd02.prod.outlook.com (10.164.90.158) To TYXPR01MB0928.jpnprd01.prod.outlook.com (10.168.45.23) X-MS-Office365-Filtering-Correlation-Id: 689c739a-7ed4-426f-3510-08d3757b35b6 X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0928; 2:Znfjctkd3HneAhz7LGHeltYBGTOzZXKhg+DrI79G2IAE97a4XE8EC3XGiLwz6ktygr1iviairo4gAWp6ssBHH98LWgzHTUxdQFfrovNKq9NgnU5UztnbUz0h/ZSwWdhd96fwW3sDl+ochMZVVmYgYj6QNR8VS4YoiRXzRCnYv9zlSQ3fZ6i3TX06dfEK+IJb; 3:7JgX2rYjalIMYWR4WHtGE5Jgyn9YfsQUYuaYbf8nm2qYb9YYgykX7Lthy09Y1Ey5ukNWgK69yEFBGkFHeQ6ZLR6MUVT+U15Hrh52mmyjyA7zb+n5MmtqqADpGK3PrNXC; 25:xzgxMD7tGYBzCW56SXv8RWSKQqvm12nrzNMhWVNM0B0qeAeBDJqVzAsU/W7uw6uoEqmonUGWANxWMq3arazIMq3ch3bSKmaB88LGYm2rwmQRp5EUVdP5vHsKqkYjawDFZ9d6w+PqPhfUqOofYWkA/k6dOFolb9LsOG7mEZvkcCdOoTluD6VrKWrEAdHCR44WOAPDOjLFlgIXh89+KEL0LUiFqwU/AR9y9krixy3MGdWeVlt3415Gd+dcrhgsLo35jqbsbHjtrGj1yjR1xyxK0yrWrNdwr1epZ7iNjtpz8Txq6AGKWBumZuQqAfD7097LsRQ3y8CpgMfmlDmjZlQGJprig2+T6KdltWdSumWgpVESOJYbcytqKN3MnehZTH8cRTnGRyIkCVkTWHGpT6rCnwNiA/kdK/9q80JZdC8LV+FyQqFHC9f+5f/FAQJmoL50 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TYXPR01MB0928; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040130)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041072)(6042046)(6043046); SRVR:TYXPR01MB0928; BCL:0; PCL:0; RULEID:; SRVR:TYXPR01MB0928; X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0928; 4:si4B9NQM6X4SRZurxZK71qeLzxy87nRKc6OmG+edrvELHBL/JfIladYb9/R6X5fdDn4KvpfAXAwDu3cl78LS7GKYVxuFJ/Stk9btBLtq7GW75bgJ5Hy4c50TnWXSDTAkWZBnjOyRvKBeKXBpZ5cw2qZ3kgCeob5XnS15d0GatWpxAk91RRGo3UtNAjztV6OO6DNY9mj7Eg4bn1C9QTCwmyydtLl/A9HEvif2FMEgGgqY5RrBbBE2vgdjHzXmeKwau+7WV8XNP7C0RQn/+1EvvlepgOYr10DTugxcM2q2H0iBmrUqMEEv0xKJSmaQI83WzTPZKC04rPEcDAsc5p1h7+/IaJ60PtArqJsCHkm1yWOHn0VdUBQMEVGOfQLxr5hgLSJ6aXQfoVJCMaEkAFKKKMBj12J6qird7VrsxbHy9T65F3eJtGWCrpLSStRB04DU X-Forefront-PRVS: 09347618C4 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(24454002)(86362001)(74482002)(6116002)(586003)(5004730100002)(5008740100001)(3846002)(64126003)(23676002)(50986999)(54356999)(42186005)(31696002)(33646002)(31686004)(50466002)(47776003)(2870700001)(66066001)(107886002)(2906002)(2501003)(83506001)(81166005)(77096005)(5001770100001)(92566002)(189998001)(2950100001)(76176999)(4001350100001)(65826006)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:TYXPR01MB0928; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWVhQUjAxTUIwOTI4OzIzOk1tck5kMUl3NzhZU1phUC9JakZnUzZDNWVV?= =?utf-8?B?Wm11dmhyalc0dGJHMmlFZnBFQzYyZnBOekxlWDEydTFMUERMalNIaW1MTFFY?= =?utf-8?B?cmQxVm82aDJNNmRxNldZOUxvcmgwZ3AyNnZ0YjJMQTJlU3Y1UGxRdlhpeFZV?= =?utf-8?B?NktuVWpVRys5QWxpWHJlQzl4NXk5NVdFWXpYZE55T0w4N0ZISEFBYTA5RlZ2?= =?utf-8?B?enZrRWxZTVpVUjdKTjBBTTBLV0lIMWQ0NDI1b0RwRDdRUFVGUmpUUGM0eDNl?= =?utf-8?B?RUZsVG45Z0xZZktxQkJiU2FUTHpqRkwzK1A4L05EQWFMNzJvZnoxL2tlc2dv?= =?utf-8?B?UFdGSldyYjE0NEhJdUVNNjRYeEx5cDZaVk5zQ2xKbUJrK3phZVF2bmNMMmxo?= =?utf-8?B?QTJYMnVBM1htZmRieGtpTlRyTUUzbFBvaURSZU5BOXM3bDd6RG0wQWhyTWYy?= =?utf-8?B?dkVWUURiUk13Q0pkSzhoR21sZnhlaFZOVHpYbXp2YS9KZDJtUWg5QXZ4dnNl?= =?utf-8?B?M2M5N1Y5azFxNkZ1aUVoaytvdFk0dlRod3ArQ0FXb3NZUXdZT2k3cU9uakh6?= =?utf-8?B?Qit5ckRiUmZKaGVHdHRHeDlkY1IvTWg0bWZ3R2I3eE15bDJZY1NKVWpRVTl5?= =?utf-8?B?YkFRYTczVVpkM3l6UDNQQytvNncxM2ZGMFpHZjdyOGVremJrcU9Balo0Yys1?= =?utf-8?B?TDl1VFYyTHpxZklnSzhnSCtqOFNXWGVDTTcwOWIvRVNKMlVRNmhsS3JIU2FN?= =?utf-8?B?QUNnY2VSNEF3dmxGTlAzOEZNYklnQWRFWnN2bUozTjJuWXpzYUY4MGdxQmpL?= =?utf-8?B?NDFUTldOS0VlUDdTN1lLZGJrdHE4enVzQmlqUmNGRlRXZUpadDhFRU1aSUVj?= =?utf-8?B?eHJZY3greHYrQUJNWFRuWVdGcmY3emhaUzByMGlxSEdGV0w1SVFWelJkbE5p?= =?utf-8?B?OUtzTzZGbFk1aFIzc084UjRGbVk1Z1lIM3BGM2Y2ZkJWS0FpcHd3ZUF1ZStY?= =?utf-8?B?bnJ0U24wc3hpSHlVNEtFVXUxTVExWGg4aW5RTDJadmRyTjZnUmp2WVpXOVdi?= =?utf-8?B?ZWJVUlhaRFhlTEh0RUVrZVBPLzgvZ1F1L0RySktGWW9Cdll6dnJnRk84aVY3?= =?utf-8?B?c0hTaG9uNXNLZVF5Mm4zV3I4YXFvNVQzT1V2dWgvbTJUeFlYV1hJUHJVWjlu?= =?utf-8?B?aVJuek91VldxdHQ5RlMwK2RpSGVSNEVNY0FxRm82SVo2WjhSSHIvSkg2YjJl?= =?utf-8?B?ck4rb0xvZVcvM29qTDVOTnphQkwxV0YzYWhDMU8yRVl3TVl6TElmb2J4MmZq?= =?utf-8?B?VjFOSEFqNThhTkhTMUhlSlNqZWdlbGZUM3lJNVl6VFFMeHk5ank2SlhDaXl2?= =?utf-8?Q?uWVbRFKM?= X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0928; 5:ghzx7XNzonHyYVr6X8vonCSMNCP1XV0oviD2BWBlq22Ktl0+DS2FBQy12AWSHXjjg4Q5s8q2j5ThxG+P/ZvLIVLcAs63j5DoeGk4K6JOTDp5RQfuXsyrwXBCGLdqXj8V+9cvDCXwDd/yhtCjG3ekaA==; 24:sKHSNvjirO7pWVZIBGlY29CRxC/fQ7Wve9AB5rIJlEgqwyvtnoXwp8x8KA/i764LRLcVL3aa9QopsF9kj7kJmVeXjGQ5havPgN0eSQOHprk=; 7:7+BZWUl7UDxrT99jz7A1Rrtm5ozDfz4vtKQePDav0mY0hfS2YwHLAXPDqZXXZ18IpvUtDB4jOKMEAgkYpHE7y95J4AoX6mpfUWd03E0wKvNZJ+eKajl1rYy6y0t9WrbLhmmlPiARvYWs9S2F57A9TyBdEI/WboUqGN30ZvItL1H8x8E96BkFgx+PJ+8eY4CK SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 May 2016 06:54:02.9901 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYXPR01MB0928 Archived-At: Subject: Re: [precis] toLower() vs. toCaseFold() X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 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, 06 May 2016 06:54:11 -0000 Hello Peter, On 2016/05/05 07:43, Peter Saint-Andre wrote: > I suggested that we add some text about this to 7564bis. Here is a > proposed paragraph for insertion in §5.2.3 ("Case-Mapping Rule"): > > The Unicode toCaseFold() operation defined by the Unicode Default > Case Folding algorithm is most appropriate when an application needs > to compare two strings. When an application merely wishes to convert > uppercase and titlecase code points to the lowercase equivalents > while preserving lowercase code points, the Unicode toLower() > operation is more appropriate and is less likely to violate the > "Principle of Least Astonishment". Therefore, application developers > are advised to carefully consider whether they truly need to use the > toCaseFold() operation in a given situation, or whether the toLower() > operation would be more appropriate than the toCaseFold() operation. > > Suggestions for improvement are welcome, especially from John. (E.g., we > might want to more explicitly call out comparison vs. other contexts in > the normative text elsewhere in §5.2.3). I think 'compare' should be changed to 'search'. That's the prototypical use case for CaseFold. Also, the language in the "Therefore" sentence is somewhat convoluted. It's unclear which alternative this text prefers. I suggest that if we want to put the two alternatives on an equal footing (i.e. make sure the application designer thinks carefully), then a more parallel sentence structure, avoiding words such as "carefully", "truly", and "would", would be more appropriate. What about: Therefore, application developers are advised to carefully consider whether toCaseFold() or toLower() is more appropriate. Regards, Martin. From nobody Fri May 6 19:39:11 2016 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 04A2412D506 for ; Fri, 6 May 2016 19:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 cNiS5zv99pMI for ; Fri, 6 May 2016 19:39: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 366D512B029 for ; Fri, 6 May 2016 19:39:07 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ays8w-000M9z-Pg; Fri, 06 May 2016 22:38:58 -0400 Date: Fri, 06 May 2016 22:38:53 -0400 From: John C Klensin To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , Peter Saint-Andre , precis@ietf.org Message-ID: In-Reply-To: References: <572A7AF9.3050903@stpeter.im> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [precis] toLower() vs. toCaseFold() X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2016 02:39:09 -0000 --On Friday, May 06, 2016 15:54 +0900 "Martin J. D=C3=BCrst" wrote: > Hello Peter, >=20 > On 2016/05/05 07:43, Peter Saint-Andre wrote: >=20 >> I suggested that we add some text about this to 7564bis. Here >> is a proposed paragraph for insertion in =C2=A75.2.3 >> ("Case-Mapping Rule"): >>=20 >> The Unicode toCaseFold() operation defined by the Unicode >> Default Case Folding algorithm is most appropriate when an >> application needs to compare two strings. When an >> application merely wishes to convert uppercase and >> titlecase code points to the lowercase equivalents while >> preserving lowercase code points, the Unicode toLower() >> operation is more appropriate and is less likely to >> violate the "Principle of Least Astonishment". Therefore, >> application developers are advised to carefully consider >> whether they truly need to use the toCaseFold() operation >> in a given situation, or whether the toLower() operation >> would be more appropriate than the toCaseFold() operation. >>=20 >> Suggestions for improvement are welcome, especially from >> John. (E.g., we might want to more explicitly call out >> comparison vs. other contexts in the normative text elsewhere >> in =C2=A75.2.3). >=20 > I think 'compare' should be changed to 'search'. That's the > prototypical use case for CaseFold. Hmm. If we have to choose, I think I prefer "compare". I just looked at the subsections on "Default Case Folding" and "Default Caseless Matching" in Section 3.13 of TUS 8.0 and it says a lot about comparison and nothing about search. Recommended compromise: Make the relevant sentence fragment read "most appropriate when an application needs to compare two strings such as in search operations." I'd still prefer to denounce toCaseFold completely, especially where identifiers are concerned. It just has far too much potential for being destructive and creating false results (either positive or negative) when the language context is unknown. People/designers/implementers who are not prepared to understand those issues and their implications should really not be using the thing. > Also, the language in the "Therefore" sentence is somewhat > convoluted. It's unclear which alternative this text prefers. > I suggest that if we want to put the two alternatives on an > equal footing (i.e. make sure the application designer thinks > carefully), then a more parallel sentence structure, avoiding > words such as "carefully", "truly", and "would", would be more > appropriate. What about: >=20 > Therefore, application > developers > are advised to carefully consider whether toCaseFold() or > toLower() is more appropriate. For the reasons above, I'm not sure that an even footing is appropriate. I'd rather have the guidance be closer to "use toLowerCase, which your users are likely to understand, unless you need CaseFolding for some particular reason and understand its implications" best, john From nobody Fri May 6 19:40:16 2016 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 1754C12D1DB for ; Fri, 6 May 2016 19:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 Kc8_V6p159Ve for ; Fri, 6 May 2016 19:40:13 -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 8EBE612B029 for ; Fri, 6 May 2016 19:40:13 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1aysA7-000MAC-4C; Fri, 06 May 2016 22:40:11 -0400 Date: Fri, 06 May 2016 22:40:06 -0400 From: John C Klensin To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , Peter Saint-Andre , precis@ietf.org Message-ID: <6F0075DBF071EB43A3F97F73@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Re: [precis] toLower() vs. toCaseFold() X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2016 02:40:15 -0000 (sorry... earlier copy sent from wrong address) --On Friday, May 06, 2016 15:54 +0900 "Martin J. D=C3=BCrst" wrote: > Hello Peter, >=20 > On 2016/05/05 07:43, Peter Saint-Andre wrote: >=20 >> I suggested that we add some text about this to 7564bis. Here >> is a proposed paragraph for insertion in =C2=A75.2.3 >> ("Case-Mapping Rule"): >>=20 >> The Unicode toCaseFold() operation defined by the Unicode >> Default Case Folding algorithm is most appropriate when an >> application needs to compare two strings. When an >> application merely wishes to convert uppercase and >> titlecase code points to the lowercase equivalents while >> preserving lowercase code points, the Unicode toLower() >> operation is more appropriate and is less likely to >> violate the "Principle of Least Astonishment". Therefore, >> application developers are advised to carefully consider >> whether they truly need to use the toCaseFold() operation >> in a given situation, or whether the toLower() operation >> would be more appropriate than the toCaseFold() operation. >>=20 >> Suggestions for improvement are welcome, especially from >> John. (E.g., we might want to more explicitly call out >> comparison vs. other contexts in the normative text elsewhere >> in =C2=A75.2.3). >=20 > I think 'compare' should be changed to 'search'. That's the > prototypical use case for CaseFold. Hmm. If we have to choose, I think I prefer "compare". I just looked at the subsections on "Default Case Folding" and "Default Caseless Matching" in Section 3.13 of TUS 8.0 and it says a lot about comparison and nothing about search. Recommended compromise: Make the relevant sentence fragment read "most appropriate when an application needs to compare two strings such as in search operations." I'd still prefer to denounce toCaseFold completely, especially where identifiers are concerned. It just has far too much potential for being destructive and creating false results (either positive or negative) when the language context is unknown. People/designers/implementers who are not prepared to understand those issues and their implications should really not be using the thing. > Also, the language in the "Therefore" sentence is somewhat > convoluted. It's unclear which alternative this text prefers. > I suggest that if we want to put the two alternatives on an > equal footing (i.e. make sure the application designer thinks > carefully), then a more parallel sentence structure, avoiding > words such as "carefully", "truly", and "would", would be more > appropriate. What about: >=20 > Therefore, application > developers > are advised to carefully consider whether toCaseFold() or > toLower() is more appropriate. For the reasons above, I'm not sure that an even footing is appropriate. I'd rather have the guidance be closer to "use toLowerCase, which your users are likely to understand, unless you need CaseFolding for some particular reason and understand its implications" best, john From nobody Sun May 8 21:17:32 2016 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 F143A12D0CC for ; Sun, 8 May 2016 21:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.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 c6vk-6UUZPkb for ; Sun, 8 May 2016 21:17:28 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0101.outbound.protection.outlook.com [104.47.93.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4720A12B01D for ; Sun, 8 May 2016 21:17:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kQV+v+/8hICTRO845u0siDt718ZRGjfEYdLVDKHnhek=; b=uTyUGtFgctkIvVXfNzgD/aSbU6124i1oFPz1iQx/qjAbMfvHyRyDU8L7Vx3HmeUJHr/b4FLtwLL2maTqgat/hSuAN12h3GGQ68lwnLVsNPqvF7rr6jVcl39xon7JdvCa0ssH6/OPWihxihkRTowTsFRab8czTFX7rNfl+3BuUA0= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by OSXPR01MB0920.jpnprd01.prod.outlook.com (10.167.148.150) with Microsoft SMTP Server (TLS) id 15.1.492.11; Mon, 9 May 2016 04:17:26 +0000 To: John C Klensin , Peter Saint-Andre , References: <6F0075DBF071EB43A3F97F73@JcK-HP8200.jck.com> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <398ad402-5058-05aa-7cf8-3fe4b40e5f17@it.aoyama.ac.jp> Date: Mon, 9 May 2016 13:17:25 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <6F0075DBF071EB43A3F97F73@JcK-HP8200.jck.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: TY1PR01CA0024.jpnprd01.prod.outlook.com (10.161.131.162) To OSXPR01MB0920.jpnprd01.prod.outlook.com (10.167.148.150) X-MS-Office365-Filtering-Correlation-Id: 3e6cf2f5-40d1-4ff6-1c69-08d377c0d3fa X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0920; 2:Lfd81G+1DJ+kxFJhAOROPRiOeETgV4ay3qk67RKzI1cpqWbvtWQgrWYkO9CbnguRl8Mfq5V8U6zC/RMienX1h9kgfhyFibs4Ahxnpro9b/CIE83Tp69ZZUyzPYub3E+LQvjlJWaiLZySjj11LrwGTjM1eg7SNab//gCionAkCGAMYKjLb2fRf0MHjpIvgVRi; 3:S8lU6LOUDlBke07pgQROIpDmsAfbuoLanPWF3T8GpUUr7bzOEmCrB2xeofCiBp/WE7ulNYwlHInoiboOECfi+mOpxwRy+IOcanQcqUI1FloWQOeD7n/fwO1q0nXlCemK; 25:oz5Zkna6JH1uf9pit4eu7IuLSiHaa/kQ3ddGEPt4I5DapwMxuOzITKx4A/46CQuf79/6XdHDlZ8jt/lNW4cigS0RrkQf8J1/5Tgop3AXlvgun4z6EJMzYGgRUhxvsLgCWOzU94efrnblHCKGWSJZedMxzlFcX14dsMDzD334PMDnvv88tSRtw74sU2wqtNch387DGoynJAN1CsRoEQmwutHjpLyLxPq4N5SFJuzAXW/LpCdbcazdow6UuM+ZFsy+BAWIQAXiAfngTjpwyTi2TNlGa0OjRRvynK6U0APqM6K7JlvzwdqjHty2Zyr5xgmeXTgk3t/W2+JUubD9jXLQ3N+1k1aaZ5gUDU0aFAC1UwZpex5h/IA0xjRnoeyycQEtWWxeMbCdiENtR3u93MT7c2JvPnsoolMeuMMLZ/AGJAhmWPNz7HkScLdImwnA+kHF X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OSXPR01MB0920; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040130)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041072)(6043046); SRVR:OSXPR01MB0920; BCL:0; PCL:0; RULEID:; SRVR:OSXPR01MB0920; X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0920; 4:1U7J3RUR+kyVe4MC4l4Q1el5Q+maZtkdfOKoAfkFvF+phqeSHVM7aBPd4in/FswAf3hT1RxfsS3ROrbZXzOaqIAMYKKmbLxFVU1Gopf6nWKIx13EhF4joD274n28jN9mI2qZEwMVwyTjsejHs/NMfKdghShg2ayMY0yZMNt8VbrmmABmFQdkLLce7ECOQBWdf0H9qE+KD6dFyJB5tIZF/L1hVJrqJJf0w0wR3/ouKi4oI7UjaIeOQXiGp8nxYJbFFvNW3iFHqnHeT+P06SB8j9BUI+JFaD9mAKfzAHmP3mLcIO8u5U/GPIWHfuv7vNV778cPjYzrvliLAMsnM5UsAhrABtXo7mWpSEXQ9QUDHX5MffVktwQasL50rB/QOMp46X8gzdx9MkVzRjrwdXHLkjZak5qPOAKD9zsLIa5dVsg= X-Forefront-PRVS: 0937FB07C5 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(24454002)(9170700001)(64126003)(31696002)(42186005)(586003)(2906002)(5004730100002)(77096005)(86362001)(47776003)(31686004)(2870700001)(65956001)(65806001)(81166005)(19580395003)(19580405001)(107886002)(66066001)(50466002)(23676002)(92566002)(54356999)(50986999)(33646002)(76176999)(83506001)(189998001)(2950100001)(74482002)(6116002)(5008740100001)(5001770100001)(65826006)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OSXPR01MB0920; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPU1hQUjAxTUIwOTIwOzIzOlBrVS8wdTJxVitlSG0yR2o0b2tZODc2SW4v?= =?utf-8?B?M0ZLS0d2dlYwdmlIOTM3dnZvd3BNNy8zdjJHcUYwVWJvczk4Wk9KRWxxTXpj?= =?utf-8?B?eGRwTlIxVHhROGFlbkFuakxGRm43SjNIakg4a1dGajhOYTFxZDBDR2lCNVRR?= =?utf-8?B?UWMyU29Ma2hZbDJRaVlVQUN4SEtTdGtKZlhDVEg4SkVpUWhDR3hLN2lsb1hC?= =?utf-8?B?VlYycUtwaEhZa0RURGtYc2Z3Wng4ZEVXdnVyV2xTd2pyVy9ab1l1bVBob3Jt?= =?utf-8?B?ci9BNWl2cFVjcHNmY1BNTWJvdktHRWdZcW84Y2hmZHB6dDNMSEZrY3BlL0Ns?= =?utf-8?B?TVB5NG9MemQ3TXYwRWFtanFqWDEzZ0J6V2srL2Z5V3VpbW5IVHB2Um9TM0pt?= =?utf-8?B?ZTlHN0Rjby9Qai9acEFzekptYzcraEJwb004OUJ3YzE0eVcwM1BNbWpLVlZk?= =?utf-8?B?dEdrSEhVSzBPUjZSSGM4UkVOV2dBeWJpRFlhRkJIRzJ2dXRGU2ZnWEF6bnBy?= =?utf-8?B?ekgzNmc0aUtUaDF4TU05SHh5dEx4a00xQXBETWFCdm5qN0FUcEg5SSs4WHAz?= =?utf-8?B?cGpzdkpjQjFhWWkrLzNTRzNmVjl3N3cwQUJTUVB0RW1NMWJkT0xsQU5NOHVX?= =?utf-8?B?eEhRQlJvNklrSFNsQTBKUW5rZm1qT1d5dC9xMlZIZWUxSWx0elYzTGYvSjh6?= =?utf-8?B?dy9wTDJpenZiaUJjblhlSWZhVWJnYkxYb0xnNFkvYnV0b0NQY0J3VENLRzR6?= =?utf-8?B?ZWFnWU9oWnNDdmovQUhPcW1mZ0dJODBNSWpQRCsrcGJwKzhsaVd0dTNMMGFB?= =?utf-8?B?MWNFUTM1aTVpVnVaRklXclFxZVZkbDFJb3lRZXRrL3FBYWdzQ200ZnpRdjJN?= =?utf-8?B?YTVPS2E0MHZQNEVGR0t1eWFyVm9kV0JlVG9OdDRyNGxTZWRjM0pkMVI4Nzdj?= =?utf-8?B?Zmllc3NCQU5WUjNLTmZjUnMzdm5BN3BraXA0Rlo5d0ZuaFlkczNNaTAwRGN2?= =?utf-8?B?V29FOVV5K0hBcWNrNlBmbE5kVzNWYk5EbEQ4OWJ1Q05mN3hVNnFBRnhpQS9l?= =?utf-8?B?Rk9MWnluODcvbUg4bjN5R3dnYjdxY0diUjN0UkJEZkFiZENUd3Y5bnZrOGE1?= =?utf-8?B?THRaV0pjdWpyNlM3MzlNWWFnRlNoOWNuR1VOMGl1WTU2OFlRaGJ1aGpPV0tK?= =?utf-8?B?Mzltc3UxUE5VU2RVNGFTTmJLYStWTllxNXlmcFBxbmdvTlpZTWloUUxxRFZL?= =?utf-8?B?aVUvRDZteXpnY3k2SFNtbk9IVFpZQnFQRG1UMzAweTJIVm5ubHo1WjBlSHdo?= =?utf-8?B?UlkrSWNLNHNZRFJjM2VhRkllbGNlcTlmVFlLYlllNG9uc0RxZlhma0RKNzVL?= =?utf-8?B?YUl1OEJPM0xiRml4c291VWNuV05qKzQ0YStUQ21La3R6T3EyQnlKTmlSRCtx?= =?utf-8?Q?dZ+t88=3D?= X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0920; 5:LsIXnVi4yFXt7pgxSo4vtO3Try4S8zo4sUloxUMMesKnIBXaeHhObkM+ZWC3JzYFaJFunX07Ic6vMp1WQFYa4pB2GHQhkBOU0anZle2E3vD4vmSI2Fh7tDvmZdffjsJW3Z1XRkfU1ay9lOfnh0bIbw==; 24:hbcMtuwpwujLwZheBWXSmY7Jn0dYpCdBniXrUU4pcy8bcgtXLdr1elJSgfThoDkMYDuwSh/KK70I5h06j8kVu2WH7kC+UpWpBHFyPrMWuOs=; 7:WQyC79ROZF2xyZ92NLS9HZNugDrCKXMZVCvnuKC5C2VwAaZA6SrfU6m0X6nZUJP5df3N3G4QJ3hOuki+C8UDs98Eyff7sSK7/iBRf/OIpJQuY+S9TM1Q7MyQ964+F+ccVVnPTEjjO6b4MIB8AsDDWV2J3S+sQinMnlI5HsH14bFCO7eRLHvqMxkhRYGwmRh9 SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 May 2016 04:17:26.1931 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSXPR01MB0920 Archived-At: Subject: Re: [precis] toLower() vs. toCaseFold() X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 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, 09 May 2016 04:17:31 -0000 On 2016/05/07 11:40, John C Klensin wrote: > --On Friday, May 06, 2016 15:54 +0900 "Martin J. Dürst" > wrote: >> On 2016/05/05 07:43, Peter Saint-Andre wrote: >>> Suggestions for improvement are welcome, especially from >>> John. (E.g., we might want to more explicitly call out >>> comparison vs. other contexts in the normative text elsewhere >>> in §5.2.3). >> >> I think 'compare' should be changed to 'search'. That's the >> prototypical use case for CaseFold. > > Hmm. If we have to choose, I think I prefer "compare". I just > looked at the subsections on "Default Case Folding" and "Default > Caseless Matching" in Section 3.13 of TUS 8.0 and it says a lot > about comparison and nothing about search. Recommended > compromise: Make the relevant sentence fragment read "most > appropriate when an application needs to compare two strings > such as in search operations." Fine by me. > I'd still prefer to denounce toCaseFold completely, especially > where identifiers are concerned. I didn't know which direction we are leaning, but if that's where we are moving, that would be very fine by me, too. > It just has far too much > potential for being destructive and creating false results > (either positive or negative) when the language context is > unknown. People/designers/implementers who are not prepared to > understand those issues and their implications should really not > be using the thing. Agreed. >> Also, the language in the "Therefore" sentence is somewhat >> convoluted. It's unclear which alternative this text prefers. >> I suggest that if we want to put the two alternatives on an >> equal footing (i.e. make sure the application designer thinks >> carefully), then a more parallel sentence structure, avoiding >> words such as "carefully", "truly", and "would", would be more >> appropriate. What about: >> >> Therefore, application >> developers >> are advised to carefully consider whether toCaseFold() or >> toLower() is more appropriate. > > For the reasons above, I'm not sure that an even footing is > appropriate. I'd rather have the guidance be closer to "use > toLowerCase, which your users are likely to understand, unless > you need CaseFolding for some particular reason and understand > its implications" I'm fine with that. I just had difficulties understanding which way the bias in the "Therefore" sentence was going, if any. And my guess is that others may have the same difficulties. Regards, Martin. From nobody Mon May 16 14:53:07 2016 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 8D90312DAD1 for ; Mon, 16 May 2016 14:53:06 -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=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 BX9fM7shLYLs for ; Mon, 16 May 2016 14:53:04 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (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 52A3112D539 for ; Mon, 16 May 2016 14:53:04 -0700 (PDT) Received: by mail-qg0-x235.google.com with SMTP id 90so96585864qgz.1 for ; Mon, 16 May 2016 14:53:04 -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:content-transfer-encoding; bh=Eb7bg5rTPGgF+p3BKs2whBp2JJgajYWsOaFr1XQO8as=; b=pl/7GSZZQmWLp3hea7rdYpvkaFwqTBQldwn1xzk4HsyxB89QZHHmDyLHYFvNiPJNYB aUC7AtIU9fOaTcsKYff9TUfxKVTyyrL6XpcNc4pFRvpRAW6RPgYIuy72XS6k2O2xqYXN IaOLwuPPrxr4jAEEX95Vo5CEDzxr4QI016or4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Eb7bg5rTPGgF+p3BKs2whBp2JJgajYWsOaFr1XQO8as=; b=W31zxVkMiSU2Rf34xxNrBjOgaYRM5qgYgIEVujVSe/KHVhJVlHDM4HF1rqD/DN9Vx6 flVXqDNfZEDi/iUR558+chvMyFY0p2cGATxzADlENSm3DV1fI+idwpEbC47YEjt7zSjJ wpmk5kmVKzQf5yHxgBDS47qpwncqWUSksQpU2crHpiivN3sfWTuR5UgW4gSIaJSAJQuZ I5PV+MTJr8B6URjCliM6cbIwde26luviP7UGnF2JwYEeq84vcBcTwab8HE1aG3OEwWbo xt7PENg/XlatJdhIt7RG6nqoMMy3q5d3QHnxOqvO8wJu2aoB6t8rwh0hUfdWCmd4IwFw uO6g== X-Gm-Message-State: AOPr4FWhBd05hzB/2L6Gg2G54fRkVmx/ElhKQ8Mo+NDds/i8kmgo+AJDK5oP1Q6ZYJ3NNvuGA8ciNsr9xszNiw== X-Received: by 10.140.42.195 with SMTP id c61mr31084058qga.40.1463435583424; Mon, 16 May 2016 14:53:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.146.5 with HTTP; Mon, 16 May 2016 14:52:23 -0700 (PDT) X-Originating-IP: [72.48.156.244] In-Reply-To: <20160505174255.20595.13753.idtracker@ietfa.amsl.com> References: <20160505174255.20595.13753.idtracker@ietfa.amsl.com> From: Sam Whited Date: Mon, 16 May 2016 16:52:23 -0500 Message-ID: To: peter@filament.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: precis@ietf.org Subject: Re: [precis] I-D Action: draft-ietf-precis-7700bis-01.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 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, 16 May 2016 21:53:06 -0000 Hi Peter et al. A few quick notes regarding your draft to replace RFC 7700: * Nit: =C2=A71.1 =C2=B63 uses the term "display name" several times, but th= e document otherwise uses the term "nickname" * =C2=A72.1: "May any instances of non-ASCII space be mapped=E2=80=A6" soun= ds odd, should this just say "Instances of non-ASCII space should be mapped=E2=80= =A6" * =C2=A72.2 Specifies that UTF-8 MUST be used as the encoding; do we really want to limit this to UTF-8 only? Is this for comparison purposes? Then again, 99.99% of the time UTF-8 is what you should be using anyways, so I'm not sure that it matters. * =C2=A72.3: "Normalization Rule" is listed twice for enforcement Best, Sam On Thu, May 5, 2016 at 12:42 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Preparation and Comparison of Internatio= nalized Strings of the IETF. > > Title : Preparation, Enforcement, and Comparison of Int= ernationalized Strings Representing Nicknames > Author : Peter Saint-Andre > Filename : draft-ietf-precis-7700bis-01.txt > Pages : 11 > Date : 2016-05-05 > > Abstract: > This document describes methods for handling Unicode strings > representing memorable, human-friendly names (called "nicknames", > "display names", or "petnames") for people, devices, accounts, > websites, and other entities. This document obsoletes RFC 7700. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-precis-7700bis/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-precis-7700bis-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-precis-7700bis-01 > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis --=20 Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com From nobody Tue May 17 07:43:54 2016 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 2A04F12D6C7 for ; Tue, 17 May 2016 07:43:53 -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=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 E2c1OPMbQ07x for ; Tue, 17 May 2016 07:43:51 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 1CB9512D6C2 for ; Tue, 17 May 2016 07:43:51 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id x7so9621418qkd.3 for ; Tue, 17 May 2016 07:43:51 -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:content-transfer-encoding; bh=kuySvdoPTHw1gvUnCyxYi4TcsW8hj8nmib9sD2Np2tY=; b=gM/k/4Q2qwK7R03oi8X0oqwndUWDx1VGCLku0J+3Vx82EqMI6KM8gEY5S1V8+1/eu3 3E+EKG6nh07CWaWXGvAsFXfBJKmdUnlZ6qFywb1L+2frMmTU+yyjB7I6wdgH7Ez7rP4m qeY8WZXe8bkhPQ+O00xWGtfsqksRaJvBrMQ6I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=kuySvdoPTHw1gvUnCyxYi4TcsW8hj8nmib9sD2Np2tY=; b=D0xOl3Ok/rOBRTleJy/zx09uHWZvl+vv+KRr0dR57IC2kue8jSB7mdMx90GBwSJTio oc12AKTKlw9rdFcganr3qT2QCb1INe88iSAZSzWfuBQic+C52Gx6DljqV6CFj5uiRrtO nsbq6SCgaz1AjLr18JSpYd493jhSIJcZKO0XrCh34oimk8+W/ovTU8ariGt+3kTdnLG4 ylEdRwPccnSRk5Na84fJk+mJK0yIndfu2aKbC1ZCFKtN/p1wVhCiZGXr91trIqbGEonO a61s1QcMzJPbVGdt4RFPf4Oa9CVzanTxPu9GuA0NxJwQfiV+IrwJh1sm+VMAB4Pg5V1j ortQ== X-Gm-Message-State: AOPr4FU8hb2Ai3C/ld5iSdpyksi4pnmgExzF36i5Ip1QxxABve0BcSIoeJ5nYDCCX41za83daRzCkG0izP9U0w== X-Received: by 10.55.221.24 with SMTP id n24mr2009057qki.149.1463496230130; Tue, 17 May 2016 07:43:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.146.5 with HTTP; Tue, 17 May 2016 07:43:10 -0700 (PDT) X-Originating-IP: [72.48.156.244] In-Reply-To: <20160505174244.20612.16872.idtracker@ietfa.amsl.com> References: <20160505174244.20612.16872.idtracker@ietfa.amsl.com> From: Sam Whited Date: Tue, 17 May 2016 09:43:10 -0500 Message-ID: To: peter@filament.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: precis@ietf.org Subject: Re: [precis] I-D Action: draft-ietf-precis-7613bis-01.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 14:43:53 -0000 Hi Peter et al. Here are some notes I took while reading through the 7613 draft last night; a few of them are actual issues, and others are probably just me misunderstanding something: - =C2=A73 defines Usernames, but since I was expecting a PRECIS profile that defined a username it was confusing and I didn't really understand it at first (until I got to =C2=A73.5 which explained the difference between user parts and usernames). I'm not sure if this could be made clearer or not, or if it was just me. - Nit: =C2=A73.2.4 reads "An entity that performs comparison of two strings according to this profile MUST prepare each string as specified in Section 3.2.2 and then enforce the rules specified in Section 3.2.3". Though redundant, it might make sense to modify it to read "and then MUST enforce the rules" as well. Not sure that it matters, but it was unclear to me on first reading (though I figured it out pretty quickly; others probably wouldn't have been tripped up by this). - =C2=A73.3.3 says that the Case-mapping rule should be performed as the third step of Enforcement, but there is no case mapping rule for the profile. This step should probably be removed or clarified (eg. is case mapping optional, or is it required that you don't do it? I'm not clear on how the absense of a rule works in a profile in general). - Table 2 says "A localpart of BLACK CHESS KING". Localpart is an XMPP term and should read "Userpart" in this context - Nit: =C2=A74.2.2 lists the Case mapping rule as "Uppercase and titlecase characters MUST NOT be mapped=E2=80=A6", but other profiles just say there = is no case mapping rule. Similar to the above, if there's a difference (especially within a single document), I think it could use some clarification. Although I'm not sure that it matters, as implementations are likely to just leave off case mapping either way, which I think is the expected behavior in both cases? - =C2=A76.1 references Unicode 7.0, if an update to the RFC is being proposed, this could be changed to read 8.0.0 (or removed if the issue is no longer a problem), or it could be left alone, probably doesn't really matter. - =C2=A76.1 also says "these code points would have been "mapped to nothing" in stringprep, in practice a user would not notice the difference if, upon migration to PRECIS, the code points are removed.". Is this correct? Would this not make the username invalid because the code points aren't allowed in the identifier class, locking them out of their account? I'm probably missing something here. - =C2=A76.2 Another possible place to update a Unicode 7 reference to 8.0.0 Best, Sam On Thu, May 5, 2016 at 12:42 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Preparation and Comparison of Internatio= nalized Strings of the IETF. > > Title : Preparation, Enforcement, and Comparison of Int= ernationalized Strings Representing Usernames and Passwords > Authors : Peter Saint-Andre > Alexey Melnikov > Filename : draft-ietf-precis-7613bis-01.txt > Pages : 25 > Date : 2016-05-05 > > Abstract: > This document describes updated methods for handling Unicode strings > representing usernames and passwords. The previous approach was > known as SASLprep (RFC 4013) and was based on stringprep (RFC 3454). > The methods specified in this document provide a more sustainable > approach to the handling of internationalized usernames and > passwords. The preparation, enforcement, and comparison of > internationalized strings (PRECIS) framework, RFC 7564, obsoletes RFC > 3454, and this document obsoletes RFC 7613. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-precis-7613bis/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-precis-7613bis-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-precis-7613bis-01 > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis --=20 Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com