From nobody Wed Dec 9 10:36:59 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BEB71B2CE6 for ; Wed, 9 Dec 2015 10:36:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 5rvvqqu0DX-g for ; Wed, 9 Dec 2015 10:36:56 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26E2F1B2CDF for ; Wed, 9 Dec 2015 10:36:55 -0800 (PST) Received: from christihudtsmbp.fritz.box ([95.117.223.250]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MQzoI-1ZfgoV2mVy-00UKxd for ; Wed, 09 Dec 2015 19:36:53 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Christian Schudt In-Reply-To: <3A5E5283-7BCC-41DA-A183-6872695D91DC@gmx.de> Date: Wed, 9 Dec 2015 19:36:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <02D6F037-4B2D-487F-88CA-72C7D8F7CA7B@gmx.de> References: <3A5E5283-7BCC-41DA-A183-6872695D91DC@gmx.de> To: precis@ietf.org X-Mailer: Apple Mail (2.3096.5) X-Provags-ID: V03:K0:33Z9JpLE75050Qi6Ph/Ph1+0tnh4RjkLFbq3AgiAO2bXkzf+Rkz gA+NCbC7jGo9GhsUsV8kl3I+rJTNw8oAUE1+P+ZstSC9nRmdY1ah5IgtJX+5YmH59D1kFCS xAWWENcOFN6bkMBWhR5A/hh8r6/QDN4x/jFeVbu9RtOYtkHLgzsBD6I7YzX6N1XRApjmr3C irXbCKvORx43Gemf3rh3Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:uGBfircsT4U=:iqZyNZn8/DBE1cXmmlfXq1 Kj/KJph/eH+AJfPuojstD/jkULqXlKQEG49mdvlKpmhgqfkXkOoBzm6x0I0V9MbfB8DgaCWSv kpOpJmNLfKOvj1tv3ofbdV1x7i4EE0cWOS3S/hF+jJSrfBpdw9/+q/RshIUoa53499dCAMdQx TkHi72gmD9LULDJPqeQ8VZhDOiN3rH9jH70I2S32THxGDOeMLwyp7dgKhHAJSyQSunywr7lQe bF2gjBTYJxd9r4wXfODxMQWcc//bf0+XDVgaeWEoQHJOFW+qVGgNakQEF71E0dD8rGpKYe/Go w4Y20hJS62zWmNC5gL35z7dgGQZgI6CCE+49seT6PYECEUM3+XArTxL4NA4C8Wbu0TLq1k7EG xTTPznRYVm0v7C2nlo6SVdTsGbGsw00EpQypyF1y7BF/gb3ACg20zd3nU0Hw69BGpFuKqFLeC 2iu98GPph4NsR9OaRDe9YK9PYaOVNnfHWO2qpTEwW1g+zlsHXVzINk1nIFqy7zlp5WCkuw4MZ 7Xl66c7bF3/VefbYw83bHDyHPmilL/e81BLoG/aDJozzVyRarjIOwJ2Kkv6EoeVvGBw29yog4 EPUQ5Hoo2YA2f/UCb00EPWlOLgVjypd+Y7f+d9D1arie2hyrN7s139bLRnZPsePuOaOCA5M7o 8Z+QXKPXGcQn0OsNHT1wdaMjwl4nxniV3h4BW/tuojOK9UHpRroiP7dYvPsk17j0xwlm/ciV3 z73Q1UQo84hd3veIxwqIF2ggRxdiNbPQudGPi79utPgMmJvdnoRZvZy7jZ60UW1RHEa8uvnzN q1Bmonc Archived-At: Subject: Re: [precis] U+212B (ANGSTROM SIGN) in Usernames X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 18:36:58 -0000 Anybody has a clue about this? Thanks. > Am 21.11.2015 um 14:12 schrieb Christian Schudt = : >=20 > Hi, >=20 > can you please help answering the following question: >=20 > When doing enforcement of a string of the UsernameCaseMappedProfile as = per RFC 7613 =C2=A7 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). >=20 > However, if I stick to the order rules specified in the Precis Core = Framework (RFC 7564 =C2=A7 7), the string would first be normalized with = NFC (RFC 7613 =C2=A7 4.2.2.4), becoming U+00C5, and then later would = pass the IdentifierClass check. >=20 > If I stick to the rules in RFC 7613 =C2=A7 3.2.2, such a string would = be disallowed. > If I stick to the rules in RFC 7564 =C2=A7 7, it would be allowed. >=20 > What=E2=80=99s correct behavior? >=20 > Preparation (RFC 7613 =C2=A7 3.2.1) has introduced a workaround for = the HasCompat issue, but only for full- and halfwidth characters (which = U+212B is not). >=20 > Generally I don=E2=80=99t understand why RFC 7613 violates the order = of rules (compared to RFC 7564 =C2=A7 7): Doing the preparation = (checking the IdentifierClass) first as opposed to do it after the = normalization. >=20 >=20 > Thanks for your help and comments, > =E2=80=94 Christian From nobody Mon Dec 14 21:07:54 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60C411B2AE9; Mon, 14 Dec 2015 21:07:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham 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 OJh-NCTswCMY; Mon, 14 Dec 2015 21:07:49 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id B7DB31B2AE5; Mon, 14 Dec 2015 21:07:49 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 26773181EAD; Mon, 14 Dec 2015 21:05:27 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20151215050527.26773181EAD@rfc-editor.org> Date: Mon, 14 Dec 2015 21:05:27 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, precis@ietf.org, rfc-editor@rfc-editor.org Subject: [precis] RFC 7700 on Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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, 15 Dec 2015 05:07:51 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7700 Title: Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames Author: P. Saint-Andre Status: Standards Track Stream: IETF Date: December 2015 Mailbox: peter@andyet.com Pages: 11 Characters: 22898 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-precis-nickname-19.txt URL: https://www.rfc-editor.org/info/rfc7700 DOI: http://dx.doi.org/10.17487/RFC7700 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 is a product of the Preparation and Comparison of Internationalized Strings Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Dec 16 12:32:30 2015 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 31D031A89E0; Wed, 16 Dec 2015 12:32:24 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151216203224.9721.14564.idtracker@ietfa.amsl.com> Date: Wed, 16 Dec 2015 12:32:24 -0800 Archived-At: Cc: barryleiba@gmail.com, precis@ietf.org, stpeter@jabber.org, The IESG , draft-ietf-precis-mappings@ietf.org, precis-chairs@ietf.org, rfc-editor@rfc-editor.org Subject: [precis] Document Action: 'Mapping characters for PRECIS classes' to Informational RFC (draft-ietf-precis-mappings-12.txt) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2015 20:32:24 -0000 The IESG has approved the following document: - 'Mapping characters for PRECIS classes' (draft-ietf-precis-mappings-12.txt) as Informational RFC This document is the product of the Preparation and Comparison of Internationalized Strings Working Group. The IESG contact persons are Ben Campbell, Barry Leiba and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-mappings/ Technical Summary This document provides guidelines for supplemental and alternative handling of some Unicode characters in the context of PRECIS (RFC 7564). The supplemental handling covers mapping of protocol-specific delimiters (e.g., "@") and special characters (e.g., mapping of non-ASCII space to ASCII space). The alternative handling covers language-specific mapping of uppercase characters to lowercase characters (e.g., Turkish dotless i) as an alternative to Unicode Default Case Folding, along with one instance of context-specific mapping (Greek final sigma). Review and Consensus Internationalization is full of messy complexity. The topic of case mapping, although it might seem straightforward to English speakers, can be far from clear-cut. Because of the complexities involved, the sense of the PRECIS WG was that it could not provide normative recommendations for case mapping beyond those defined in the Unicode Default Case Folding algorithm. Nevertheless, the working group saw value in providing informational guidance regarding language-, locale-, and context-dependent mappings. This is similar to the relationship between the core Internationalized Domain Names in Applications (IDNA) protocol and the informational guidance provided in RFC 5895. In contrast to the topic of case mapping, the guidelines regarding delimiter mapping and special mapping were uncontroversial and elicited no significant concern among working group participants. Personnel The document shepherd is Peter Saint-Andre. The responsible Area Director is Barry Leiba. From nobody Sun Dec 20 11:32:10 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64D51B2FCC for ; Sun, 20 Dec 2015 11:32:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.212 X-Spam-Level: X-Spam-Status: No, score=-99.212 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham 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 n4h6XjqIzQFT for ; Sun, 20 Dec 2015 11:32:06 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1AD1B2FCB for ; Sun, 20 Dec 2015 11:32:06 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 24380180006; Sun, 20 Dec 2015 11:32:02 -0800 (PST) To: peter@andyet.com, Marc.Blanchet@viagenie.ca, barryleiba@computer.org, Marc.Blanchet@viagenie.ca, alexey.melnikov@isode.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20151220193202.24380180006@rfc-editor.org> Date: Sun, 20 Dec 2015 11:32:02 -0800 (PST) Archived-At: Cc: precis@ietf.org, rfc-editor@rfc-editor.org Subject: [precis] [Technical Errata Reported] RFC7564 (4568) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2015 19:32:08 -0000 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 Mon Dec 21 09:29:38 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CAA1A9126 for ; Mon, 21 Dec 2015 09:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 fVDnktxCHiSJ for ; Mon, 21 Dec 2015 09:29:35 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A8C81A9123 for ; Mon, 21 Dec 2015 09:29:35 -0800 (PST) Received: from christihudtsmbp.fritz.box ([95.117.197.21]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MV6EP-1ZfT1A1nW1-00YSgj; Mon, 21 Dec 2015 18:29:29 +0100 From: Christian Schudt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Dec 2015 18:29:26 +0100 Message-Id: <3012FFC8-1FAD-4C30-8D85-175F4180BC02@gmx.de> To: precis@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) X-Provags-ID: V03:K0:Z4gdPJ3JQrwzhIvGD39hyBXXJxBhrEqn/X0vhT2CuztpEDfL/fG B+ebMcvqOCRXZNC8VZBVqNX8TJ+bjaRiD/MdfxHnYmk/dGNbOgEgKUHUfCWKmuLjl4X1BK4 TRHgVP+nDvAzhg9T5ocjCJXH2CAZSJYDbus+onwtaADDZSgBNmgUy7eBkNN6973RHNCQbk2 F8K8PJLEEzIniBPaA9Eag== X-UI-Out-Filterresults: notjunk:1;V01:K0:LaijBkz5QNo=:D4EpP6/NFuej+RaQwDcgeL 5JKRtYg65W3DeNEmsZ+P9u0Rd7+tEjupuoy4XWH9+GXSJhpo04JJiW6B+9XjOyZ/ujWCfga6H kFZB1xjsf3rvUGrzubscNPLaIke8nMxBSJWmC70VvCDuA0bMch8XeJwkseDhxd574hVyo5YyF SPS4BMCjIK5BsDwaV12x3i7GSc0gWlI50u6SxcqNPkmwDmtfG+RUnQHk7b4dBtAs0AvXooHIX vswSaj+BSnz22rewG980UO7YuTcjFg/0zvXbHHqNZnmpaRNjcsQTmr4agDZtfxiqJLIh3C2As Q5mnRJjEOACG2bCU9ATKO/Fb7DvNTJ4oaWWdpSIWvJSyuSc0d5e1Nvb6YQsEijHGCqnT/ZS41 XTT2Gm6HKa7K1f5CdhWj4yv2QvgRmMrKFx+69KnAA89e1XS7p7GRd2piIt2HSC2JIwifYPfTg dDPaY1rje/ZtfZx84FCTjBqmU1T1C2m6HDGyaKUMvG2PtHN874k+mEs3EIxWzgKQyiLAle1RY uVvfMkuR19BwE3xTgCnZ/yhnpmlUnN6mwTxPM66ZnQrLL4phr2IVPSKWUKUD3IYOjnzkCxOKg S+8eZRpAaPcJv+JZRIUtPi7B2EAYTND1VjI+OCuqz2g5GmUCRWhu/0d9usdiwKkGGUfc/dqNf soUzsyRD5QbVRcPkfoc8/gz3zx6NnZNX52oXZ/uj+zrNYrKav4v7khG8uptieSCysQVNMf2Nq +5EG+tMHbqP14EBRxGiSTLZGDXCfMsfkevUA6jQG7OwxnGawIyDipGyZp1b2tc8ulgGJMPIK7 +1jA6Hh Archived-At: Cc: peter@andyet.com Subject: [precis] Precis Java Implementation X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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, 21 Dec 2015 17:29:37 -0000 Dear all, I=E2=80=99ve been working on an open source Java implementation for the = Precis framework since a few weeks and I'd finally like to share it with = you: https://bitbucket.org/sco0ter/precis It supports the core Precis framework (RFC 7564), as well as the = username and opaque string profiles (RFC 7613) and the recently = published Nickname profile (RFC 7700). If anybody of you find some time and is familiar with coding/Java, I=E2=80= =99d be happy to receive some review and feedback from you, since I am = planning to publish a first version to Maven Central soon. There=E2=80=99s still one outstanding issue, which is the correct order = of rules (RFC 7564 and the profiles specify them differently, as a = consequence an exception is either thrown or not). See my source code = comment here: = https://bitbucket.org/sco0ter/precis/src/ecd82b75f3611dcb37ee0fd8890bfaf02= b5caf9f/src/main/java/rocks/xmpp/precis/PrecisProfile.java?at=3Dmaster&fil= eviewer=3Dfile-view-default#PrecisProfile.java-684 (I also asked about it here in this mailing list) Thanks for feedback. =E2=80=94 Christian= From nobody Mon Dec 21 12:40:25 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865671ACD2A for ; Mon, 21 Dec 2015 12:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.021 X-Spam-Level: X-Spam-Status: No, score=0.021 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=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 dJH4CJXMr1vL for ; Mon, 21 Dec 2015 12:40:23 -0800 (PST) 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 2E6911ACD27 for ; Mon, 21 Dec 2015 12:40:23 -0800 (PST) Received: by mail-qg0-x233.google.com with SMTP id k90so116970979qge.0 for ; Mon, 21 Dec 2015 12:40:23 -0800 (PST) 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-type:content-transfer-encoding; bh=epcLbkbm5mql1xEe/TPZ1R9i/2j0H85lIU2//LubOIA=; b=u8HIO78rPUQjYQBCJiij9BdMhnNVJ5mD28DPKnpA4jvAPD/yOJ+HwdShPzXw6J0rLL TlGNaH0m1N7eyMivIamKZ643R//idEshSYzGknqWbYk9p5XZg0idPzxIyb6wdEoRuZsY CeS/Ylh1QkUQSjaxR4N85JA2o9uM1IFPsag9A= 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-type:content-transfer-encoding; bh=epcLbkbm5mql1xEe/TPZ1R9i/2j0H85lIU2//LubOIA=; b=EOT0w3NLYXdTeDR1dj1cFn2x6ZuhlGBmxyZNAoy1iTuGl7KPOnoHqjOZtmLBomPgoc dO4pDCQUVG8qRoUFaIfD2RThxLnFnHuaoP73zngBI+k5RV4LLc/CIK3p1tFJFrarz0HD aYQ4GoZXAuA26F48KmICIX3nutDw1ZevwZuvRge7w6i4g4fAyDhtrv5F8PKPMD2VC7ZT oDXBt6YwQtyGH9YXTcYuQSLSYd2iD0A1RDolGKhXGRamYvi36WFUoali1gE2+rffJfRd CUpag9CyM7aSXxIYfSS27QwCs7gcTVUUHVpuV0eFSsYKPhuv+cgj6xpFjsP7cWXZQVcd rTsw== X-Gm-Message-State: ALoCoQlEVv5l7ryRYeMx+ukiB5pN+Q0wERr90iKC12g989rgLd132bhf6I4FQ51rLQ9c1MreO3e8f2M0knAjl/VIjdV97SZP9w== X-Received: by 10.140.93.117 with SMTP id c108mr27254610qge.101.1450730422232; Mon, 21 Dec 2015 12:40:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.10.133 with HTTP; Mon, 21 Dec 2015 12:39:42 -0800 (PST) X-Originating-IP: [72.48.156.244] In-Reply-To: <3012FFC8-1FAD-4C30-8D85-175F4180BC02@gmx.de> References: <3012FFC8-1FAD-4C30-8D85-175F4180BC02@gmx.de> From: Sam Whited Date: Mon, 21 Dec 2015 14:39:42 -0600 Message-ID: To: Christian Schudt Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: peter@andyet.com, precis@ietf.org Subject: Re: [precis] Precis Java Implementation X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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, 21 Dec 2015 20:40:24 -0000 Christian: On Mon, Dec 21, 2015 at 11:29 AM, Christian Schudt wrote: > I=E2=80=99ve been working on an open source Java implementation for the P= recis framework since a few weeks and I'd finally like to share it with you= : Awesome; looks good! I'm curious, what made you decide to calculate the derived properties on prepare instead of precomputing them? Have you done any benchmarking of this? I'd love to see the performance difference between this way and pre-computing a big trie or something of derived properties. I'm working on a Go implementation at the moment for the standard library (feedback welcome on the code review: https://go-review.googlesource.com/#/c/17933/, or on Bitbucket: https://bitbucket.org/mellium/golang-x-text/src/HEAD/unicode/precis/) and I did it this way, but maybe it's not worth the larger memory requirements. If you did want to pre-compute the properties, the code generator I wrote for my Go implementation could probably be adapted to output Java instead of Go fairly easily and might save you some time. Best, Sam --=20 Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com From nobody Mon Dec 21 13:05:11 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882F01ACD4F for ; Mon, 21 Dec 2015 13:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 DraJIjeLV22t for ; Mon, 21 Dec 2015 13:05:07 -0800 (PST) Received: from smtp82.iad3a.emailsrvr.com (smtp82.iad3a.emailsrvr.com [173.203.187.82]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B67501ACD47 for ; Mon, 21 Dec 2015 13:05:07 -0800 (PST) Received: from smtp11.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp11.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 65075100347; Mon, 21 Dec 2015 16:05:06 -0500 (EST) X-Auth-ID: fsb@thefsb.org Received: by smtp11.relay.iad3a.emailsrvr.com (Authenticated sender: fsb-AT-thefsb.org) with ESMTPSA id 1DBCA1001FB; Mon, 21 Dec 2015 16:05:06 -0500 (EST) X-Sender-Id: fsb@thefsb.org Received: from [10.0.1.2] (c-73-4-147-142.hsd1.ma.comcast.net [73.4.147.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.5.4); Mon, 21 Dec 2015 16:05:06 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_1CA5E7AA-9CFC-42AB-B6A1-54428B05BF95" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Tom Worster In-Reply-To: <3012FFC8-1FAD-4C30-8D85-175F4180BC02@gmx.de> Date: Mon, 21 Dec 2015 16:05:05 -0500 Message-Id: References: <3012FFC8-1FAD-4C30-8D85-175F4180BC02@gmx.de> To: Christian Schudt X-Mailer: Apple Mail (2.2104) Archived-At: Cc: peter@andyet.com, precis@ietf.org Subject: Re: [precis] Precis Java Implementation X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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, 21 Dec 2015 21:05:09 -0000 --Apple-Mail=_1CA5E7AA-9CFC-42AB-B6A1-54428B05BF95 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 To what extent do you think we could combine our efforts on unit tests? = Standard (or at least shared) test vectors would really help, given how = hard it is for programers to decode the RFC texts. I=E2=80=99m willing to redo my tests (https://github.com/tom--/precis = ) to use some TBD machine-readable test = spec. If others are interested, I=E2=80=99d contribute to authoring the = tests. Tom > On Dec 21, 2015, at 12:29 PM, Christian Schudt = wrote: >=20 > Dear all, >=20 > I=E2=80=99ve been working on an open source Java implementation for = the Precis framework since a few weeks and I'd finally like to share it = with you: >=20 > https://bitbucket.org/sco0ter/precis >=20 > It supports the core Precis framework (RFC 7564), as well as the = username and opaque string profiles (RFC 7613) and the recently = published Nickname profile (RFC 7700). >=20 > If anybody of you find some time and is familiar with coding/Java, = I=E2=80=99d be happy to receive some review and feedback from you, since = I am planning to publish a first version to Maven Central soon. >=20 > There=E2=80=99s still one outstanding issue, which is the correct = order of rules (RFC 7564 and the profiles specify them differently, as a = consequence an exception is either thrown or not). See my source code = comment here: >=20 > = https://bitbucket.org/sco0ter/precis/src/ecd82b75f3611dcb37ee0fd8890bfaf02= b5caf9f/src/main/java/rocks/xmpp/precis/PrecisProfile.java?at=3Dmaster&fil= eviewer=3Dfile-view-default#PrecisProfile.java-684 >=20 > (I also asked about it here in this mailing list) >=20 > Thanks for feedback. >=20 > =E2=80=94 Christian > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis --Apple-Mail=_1CA5E7AA-9CFC-42AB-B6A1-54428B05BF95 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 To what extent do you think we could combine our efforts on = unit tests? Standard (or at least shared) test vectors would really = help, given how hard it is for programers to decode the RFC texts.

I=E2=80=99m willing to = redo my tests (https://github.com/tom--/precis) to use some TBD = machine-readable test spec. If others are interested, I=E2=80=99d = contribute to authoring the tests.

Tom

On Dec 21, 2015, at 12:29 PM, Christian = Schudt <christian.schudt@gmx.de> wrote:

Dear all,

I=E2=80=99ve been working on an open source = Java implementation for the Precis framework since a few weeks and I'd = finally like to share it with you:

https://bitbucket.org/sco0ter/precis

It supports the core Precis framework (RFC 7564), as well as = the username and opaque string profiles (RFC 7613) and the recently = published Nickname profile (RFC 7700).

If = anybody of you find some time and is familiar with coding/Java, I=E2=80=99= d be happy to receive some review and feedback from you, since I am = planning to publish a first version to Maven Central soon.

There=E2=80=99s still one outstanding issue, = which is the correct order of rules (RFC 7564 and the profiles specify = them differently, as a consequence an exception is either thrown or = not). See my source code comment here:

https://bitbucket.org/sco0ter/precis/src/ecd82b75f3611dcb37ee0f= d8890bfaf02b5caf9f/src/main/java/rocks/xmpp/precis/PrecisProfile.java?at=3D= master&fileviewer=3Dfile-view-default#PrecisProfile.java-684

(I also asked about it here in this mailing = list)

Thanks for feedback.

=E2=80=94 Christian
_______________________________________________
precis mailing list
precis@ietf.org
https://www.ietf.org/mailman/listinfo/precis

= --Apple-Mail=_1CA5E7AA-9CFC-42AB-B6A1-54428B05BF95-- From nobody Mon Dec 21 14:08:25 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8103A1ACDCA for ; Mon, 21 Dec 2015 14:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 xMuARxxW-xzP for ; Mon, 21 Dec 2015 14:08:22 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B61571ACDC7 for ; Mon, 21 Dec 2015 14:08:21 -0800 (PST) Received: from christihudtsmbp.fritz.box ([95.117.197.21]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LkOeR-1aj5rt3O5D-00cMOI; Mon, 21 Dec 2015 23:08:18 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Christian Schudt In-Reply-To: Date: Mon, 21 Dec 2015 23:08:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3012FFC8-1FAD-4C30-8D85-175F4180BC02@gmx.de> To: Sam Whited X-Mailer: Apple Mail (2.3096.5) X-Provags-ID: V03:K0:9Rf85zrvf6UOuK97pw07UXnma1SH6o2itYqMkNmRuo1e8uFEGHL rrLOxsi7/LOzo6LgxbcLHG72UUcHY7P0/bXFy6SBBIjq+eB9yTuhA3jAHpL7kqCkXIpSrWh TYA8ZSQXxReeiUlyOREkFKNH6Ubm5Y5TOUNJFNNrVVmmJtQcrVMP+IjoY7f/aJxRXGjhtdN c6O4NbTjvNO8nlbG6AvoA== X-UI-Out-Filterresults: notjunk:1;V01:K0:medsbbpjsLc=:ukd29WVH5xILryKRoWV3E6 Kw8awMdKUeTqXFzELyzdQ6kk1sxmrbuvbxiJLJOpqkovT0TblUdHHzBlqFIomXg9/Yz+/PKAK 61FtAlEwxeGF46Gh6tr5cURp6QOQ9nYeHjqHx3l+zWgSJa6h5KzCJ03r/3X5Zr/hfskapMfWl LiPZIFkaW2UHyM/2qwtq396L/+8hf53XcYEImihlku4UVHn+uKn/Ze28VBfHlWpbpb/CqPi0s angnUtAC6mkV5iq8EV3zSjgblCeKidfzYIt+wfz6BuJxRQHNcPwYcTlN3HnOwa6vTm5oSfmic mdKbXhDnD7in1x0+/l5NGnOQZHVdj5//f2hlN1p7HWhsCunc/8vkvuUbW+xmvWmQMtR/SaeLF txL6EuQyHaQ6jw6bt4927hwVJ5tfjZkgogPynU6FWcEfGdlxP/KVyINM7TvTnCc4CKtFmX6c4 RYEtJ8IpzL4dYP2MpjMg0TVp5+YZOXl8L6wTEcATUOaxcpggwaiCsBIYMarCteYNCwn7KOHb4 9uy7gfo1JPGXjdDFBXfumJJqPN5v3vvGa/lC6ADZcyvcvaNVcrG0DfxClCOfXoJ5UzgIgjh1k k7qgCbbpY9C6bxAUNH0Ge6J4FhmFSY8Dea/GaNVA6NIymgNZfEQTDRepZ8zQgebSH1J4nQ2pi l5hbR0EsAgHtSk5VXwaMMIvLTt1d2fb5HFF1xuQ/fzY1DQgDJd2dOOykXN0irW3UddRUHMIgq BS9ARTaKVxRp4Z19ULnf4r2OXX/k0Onf8A2Hmd8I2p2QXBSzroqcYtVJc8Kgn3PUEIruNSTgI Bwsacgm Archived-At: Cc: precis@ietf.org Subject: Re: [precis] Precis Java Implementation X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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, 21 Dec 2015 22:08:23 -0000 > I'm curious, what made you decide to calculate the derived properties > on prepare instead of precomputing them? Have you done any > benchmarking of this? I'd love to see the performance difference > between this way and pre-computing a big trie or something of derived > properties. Thanks for your review and suggestion! I am not sure what you mean by "pre-computing them=E2=80=9C. Most of = these derived properties (methods) are based on the java.lang.Character = class and are similarly designed as e.g. Character.isDigit(int cp). If you mean having a huge code point table, like in your tables.go file: = I think Java already has such tables internally. What could be improved here, is that Character.getType(cp) could only be = invoked once. I haven=E2=80=99t done any benchmark for this, but I = don=E2=80=99t expect a significant performance benefit. =E2=80=94 Christian= From nobody Mon Dec 21 14:17:48 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7DA1ACD59 for ; Mon, 21 Dec 2015 14:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 pan7Nqs4Hemw for ; Mon, 21 Dec 2015 14:17:46 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 696C01A1BB8 for ; Mon, 21 Dec 2015 14:17:46 -0800 (PST) Received: from christihudtsmbp.fritz.box ([95.117.197.21]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Ma1tv-1ZtC143ZWR-00LpXI; Mon, 21 Dec 2015 23:17:41 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Christian Schudt In-Reply-To: Date: Mon, 21 Dec 2015 23:17:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <698458F4-6E4A-4FA4-9FC7-AA66DA648E91@gmx.de> References: <3012FFC8-1FAD-4C30-8D85-175F4180BC02@gmx.de> To: Tom Worster X-Mailer: Apple Mail (2.3096.5) X-Provags-ID: V03:K0:1B1gv5YUdFqSpT8XPHM8vhlFlIoZfBZpx8S60D96ECQdH71/u1p gNe+Cdu/3MxCCdqriIbra5a3Tyg4U3W99UIVtiLT3UZYlF2TdoUkGEudumx2KFPvBIzHbYN RwDRZVuV4bd6iqrIFUiXz7bNL6HWfDOKEvaK0gJyDUFo/ZF4QD/d0IV76a5xNheIU5A6fkU qXoDPz5Q6E8raYOoUJaUQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:bTxCK9OSGYg=:4+t0nCkTWW+vyZLUufcSWj HotzpjHEjkwJLLzSIuicSDrcySJr2pubrWU5rrcg1o3rWsrCb1loquxyVrBf14LmjMvIWrPc9 0Wp+DrkLAdvGxORsPGoyjn5QyKPAqlU4NZTknviJvXgvBSMf1TCb+iZ8x81Pu6ZufUWLAkali IMgWKlM9NIjMxFryKjJG1pZCm64KWDjmU6/Whe/J/9Qh1iKc8vWO60O+w1seFjws+ClGQcVjh PTbJrg6LT4kPPOoRakVngV8wIZ6n+I+gCiRAXBH/FnYlCG8sCSOE0Fe57rc3ls5OcxMpWSWoC SWwBib2jEljxxwUOauIZCRTitbiZEiN25ZWQ1fBG2cG47loTtYSSR+gqIUDZ3EPpf6rjgPHTl qR3zTTNGW5XIAXIvevZQ2WGqQ3Ss16QDrpazEPlPRj+tqEWwaGC2AKR1ZzZkuyInkZlYvbRx4 c9DG0095zpf411AFljss8ph5miIHHyyxilaQuYq/ONa9wFxGMplcmQ6jmZDkYFnH370C0e3X9 uQpL/Md0dSOhNlF2E+TCO5QR8fWJIjM+4NGawTQPLbw+dzfmBKxBau/jh9WmOUsszK2TT7J7f VrHhd9sTPqQPEFA3xQoe/Lfbu9YxstIH4XDhsFRAYkfZRNVPhRHVoaR4N2qBNIqV/7HruGS2K EynsjgedyYLzAjPfEYC2zYgHDcdtylzNptVPDpA/95mPhKNgQX3NBuDMaktJAEALkbp1t6RaX RXqCdCsoTtZXqCuSPnv+A+fRxSh3pcur+IpUkZVb231uuGRjSJfqvxw9HeimD3qD/xZKUgsxf yUXmmep Archived-At: Cc: precis@ietf.org Subject: Re: [precis] Precis Java Implementation X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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, 21 Dec 2015 22:17:48 -0000 > Am 21.12.2015 um 22:05 schrieb Tom Worster : >=20 > To what extent do you think we could combine our efforts on unit = tests? Standard (or at least shared) test vectors would really help, = given how hard it is for programers to decode the RFC texts. >=20 Well=E2=80=A6 if there=E2=80=99s some XML (or other language-independent = format) defining input and expected output for different Precis = profiles, I think this would be nice. But still not too sure, if it=E2=80=99= s worth the effort. Often I rely on Java internal methods (e.g. for NFC = normalization) and I guess they are already well-tested. Nonetheless, if you have some test vectors, let me know. It surely = increases interoperability. =E2=80=94 Christian= From nobody Mon Dec 21 14:27:21 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4811ACDF0 for ; Mon, 21 Dec 2015 14:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 iyMQd6eetd2d for ; Mon, 21 Dec 2015 14:27:18 -0800 (PST) Received: from smtp90.iad3a.emailsrvr.com (smtp90.iad3a.emailsrvr.com [173.203.187.90]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 073B11ACDF2 for ; Mon, 21 Dec 2015 14:27:18 -0800 (PST) Received: from smtp12.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp12.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 2E44838018D; Mon, 21 Dec 2015 17:27:17 -0500 (EST) X-Auth-ID: fsb@thefsb.org Received: by smtp12.relay.iad3a.emailsrvr.com (Authenticated sender: fsb-AT-thefsb.org) with ESMTPSA id E6CAD3800DA; Mon, 21 Dec 2015 17:27:16 -0500 (EST) X-Sender-Id: fsb@thefsb.org Received: from [10.0.1.2] (c-73-4-147-142.hsd1.ma.comcast.net [73.4.147.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.5.4); Mon, 21 Dec 2015 17:27:17 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Tom Worster In-Reply-To: <698458F4-6E4A-4FA4-9FC7-AA66DA648E91@gmx.de> Date: Mon, 21 Dec 2015 17:27:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <959A6A94-0A8C-4CF4-A5F2-C44F737C699E@thefsb.org> References: <3012FFC8-1FAD-4C30-8D85-175F4180BC02@gmx.de> <698458F4-6E4A-4FA4-9FC7-AA66DA648E91@gmx.de> To: Christian Schudt X-Mailer: Apple Mail (2.2104) Archived-At: Cc: precis@ietf.org Subject: Re: [precis] Precis Java Implementation X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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, 21 Dec 2015 22:27:20 -0000 On Dec 21, 2015, at 5:17 PM, Christian Schudt = wrote: >=20 >=20 >> Am 21.12.2015 um 22:05 schrieb Tom Worster : >>=20 >> To what extent do you think we could combine our efforts on unit = tests? Standard (or at least shared) test vectors would really help, = given how hard it is for programers to decode the RFC texts. >>=20 >=20 > Well=E2=80=A6 if there=E2=80=99s some XML (or other = language-independent format) defining input and expected output for = different Precis profiles, I think this would be nice. But still not too = sure, if it=E2=80=99s worth the effort. Often I rely on Java internal = methods (e.g. for NFC normalization) and I guess they are already = well-tested. I had the idea noticing that your unit tests have hard-coded test ins, = expects and asserts, just like mine do. Alternatively I can copy from = your tests to get better coverage in mine. Tom From nobody Mon Dec 21 14:33:00 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27FEA1ACDFF for ; Mon, 21 Dec 2015 14:32:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=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 MCojStVU1Ibr for ; Mon, 21 Dec 2015 14:32:57 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 4AB381ACE07 for ; Mon, 21 Dec 2015 14:32:50 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id n135so23203753qka.2 for ; Mon, 21 Dec 2015 14:32:50 -0800 (PST) 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-type; bh=gn3KF4K5E4lXIVP/ZiMUk9rMT27bWBzZcQM3dkk+WOk=; b=x316gMpaww04BTPw3iRwQMG5aAk94LOEi3ehaRQ3G77FFY1KG8YVuNb3+y4hnKYazZ wDhRuvFqJh6kZCkg/C+CedvYAGp/Ga8NkqcD7q1W8cCPk1324/lqfZ/jnKHrfOd/fg8b 5DBljZiV4sCGXZWf92p3PwKKjS8gOQMRwNdNY= 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-type; bh=gn3KF4K5E4lXIVP/ZiMUk9rMT27bWBzZcQM3dkk+WOk=; b=AC6NG06b5ARf3MSKFjpV0VsddfzfvV4Bz/uCF2SNorpPP94Ay6H6ThK2GMZEAjZ3Et xogRYewq4QmCY+Kxd6zRx/JW1QunRJhcJtPDQf3LVAPH0dz3wwsTXVoHXP4vxMkmDfJS r4aDgklvrhQd+ofdFuDqtBeTxoQfRy7bARHmWyloZRn6DcCc45VwkQCxcvaL5CLD8HEg x4HVxGJRO7Fvv4DotLUzThFq4BDkuQIJeLAQQ+MoRgiYzN80yLRI/Vu/446hwPpwcKWi Vb0STiXT95H5RZOkclLW463RYEAR1N8aXijjfqU/hI3IgUrLlh3YDYSja4waMokLBQde /RbA== X-Gm-Message-State: ALoCoQmFq8+8u529w4s8aDuW1Zi3+qFPdK5RU//Vcos5JhyVX86vYzKPS+xTLJy8AHAfXDmFkNwVz7SEZ5eYm4gzPrf0HG6qjA== X-Received: by 10.55.78.70 with SMTP id c67mr28013356qkb.37.1450737169497; Mon, 21 Dec 2015 14:32:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.10.133 with HTTP; Mon, 21 Dec 2015 14:32:10 -0800 (PST) X-Originating-IP: [72.48.156.244] In-Reply-To: References: <3012FFC8-1FAD-4C30-8D85-175F4180BC02@gmx.de> From: Sam Whited Date: Mon, 21 Dec 2015 16:32:10 -0600 Message-ID: To: Tom Worster Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: peter@andyet.com, precis@ietf.org Subject: Re: [precis] Precis Java Implementation X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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, 21 Dec 2015 22:32:58 -0000 On Mon, Dec 21, 2015 at 3:05 PM, Tom Worster wrote: > To what extent do you think we could combine our efforts on unit tests? > Standard (or at least shared) test vectors would really help, given how hard > it is for programers to decode the RFC texts. I'd love to help with this; I was considering writing and submitting a suite of test vectors anyways and would love to have buy-in and interoperability with other implementations. Best, Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com From nobody Mon Dec 21 16:51:41 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D881ACEE6 for ; Mon, 21 Dec 2015 16:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=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 Z9d-RCSK0oMG for ; Mon, 21 Dec 2015 16:51:30 -0800 (PST) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (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 20B4C1AC3D2 for ; Mon, 21 Dec 2015 16:51:28 -0800 (PST) Received: by mail-qg0-x229.google.com with SMTP id c96so100344411qgd.3 for ; Mon, 21 Dec 2015 16:51:28 -0800 (PST) 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-type:content-transfer-encoding; bh=pjBAj5D74oVx/7xCkOBpDTlAAiMCpA61VrgzEqEMq9o=; b=YBZ96ACGb6SD7JV8d357toeKVIVHa8woMCaO01SGCYXcIoxlX0m9m3NNZHzE96d97r aRoH35zldu09E05/u/pcrVJTZ9f4T8nhdOngtODBJVxitsfchU4ReC/GfSaKUKN6nY71 y4iLeVI4Du578EZIkfCxJl8tW2cJUkx5JsRKc= 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-type:content-transfer-encoding; bh=pjBAj5D74oVx/7xCkOBpDTlAAiMCpA61VrgzEqEMq9o=; b=Y+BDPhVG/UyKfUhVAesr14zuB4B4qQZohpVCyPqH6dWEMv9McaWmhn0oB1XWVYJRRg sWyKcTrc0ormtlX3lOeKR4pv1XKcojpPen9byMrmccD/IcF2bOvq4Gv91U6svxZrSX+P lYrWhVaFwl+UlWeytR4zR7Yw6pp6Y+cnO4JzTDteJE90tJ5D/+a/U/4V1qJrJ0EkB/U5 zQFpTdVf9UfAfr3Vt6ynOSbzZ8AdbDDkb+dQrGTFOpcad5y+EEC14AntP7eOIp/EjsUS 1Ic3HjNAZh77pNKH3E+EKE+8SXM0O8//zQWkwiQOnRUBfLMMNwr5a/EI+9vYr4FFV1ry 9ODg== X-Gm-Message-State: ALoCoQnbpc+M+fsZb/22RmaP/XLdM/rqufEu+rQKYMADZItIVr4nzxFA/+DGvpYKHaDrtXAuMYVlyfzT0UII8/xlfppT9cyRFQ== X-Received: by 10.140.219.136 with SMTP id p130mr30619580qhb.80.1450745488045; Mon, 21 Dec 2015 16:51:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.10.133 with HTTP; Mon, 21 Dec 2015 16:50:48 -0800 (PST) X-Originating-IP: [172.56.6.38] In-Reply-To: <3012FFC8-1FAD-4C30-8D85-175F4180BC02@gmx.de> References: <3012FFC8-1FAD-4C30-8D85-175F4180BC02@gmx.de> From: Sam Whited Date: Mon, 21 Dec 2015 18:50:48 -0600 Message-ID: To: Christian Schudt Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Peter Saint-Andre , precis@ietf.org Subject: Re: [precis] Precis Java Implementation X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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, 22 Dec 2015 00:51:31 -0000 Another quick note: In your case folding (https://bitbucket.org/sco0ter/precis/src/ecd82b75f3611dcb37ee0fd8890bfaf02= b5caf9f/src/main/java/rocks/xmpp/precis/PrecisProfile.java?at=3Dmaster&file= viewer=3Dfile-view-default#PrecisProfile.java-511), shouldn't the locale be left undefined? Or does it specify that US should be used as the default somewhere? Best, Sam On Mon, Dec 21, 2015 at 11:29 AM, Christian Schudt wrote: > Dear all, > > I=E2=80=99ve been working on an open source Java implementation for the P= recis framework since a few weeks and I'd finally like to share it with you= : > > https://bitbucket.org/sco0ter/precis > > It supports the core Precis framework (RFC 7564), as well as the username= and opaque string profiles (RFC 7613) and the recently published Nickname = profile (RFC 7700). > > If anybody of you find some time and is familiar with coding/Java, I=E2= =80=99d be happy to receive some review and feedback from you, since I am p= lanning to publish a first version to Maven Central soon. > > There=E2=80=99s still one outstanding issue, which is the correct order o= f rules (RFC 7564 and the profiles specify them differently, as a consequen= ce an exception is either thrown or not). See my source code comment here: > > https://bitbucket.org/sco0ter/precis/src/ecd82b75f3611dcb37ee0fd8890bfaf0= 2b5caf9f/src/main/java/rocks/xmpp/precis/PrecisProfile.java?at=3Dmaster&fil= eviewer=3Dfile-view-default#PrecisProfile.java-684 > > (I also asked about it here in this mailing list) > > Thanks for feedback. > > =E2=80=94 Christian --=20 Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com From nobody Mon Dec 21 23:46:39 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D741A6FF5 for ; Mon, 21 Dec 2015 23:46:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 DaOhhtwR_2Af for ; Mon, 21 Dec 2015 23:46:37 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 971101A6FF0 for ; Mon, 21 Dec 2015 23:46:36 -0800 (PST) Received: from christihudtsmbp.fritz.box ([95.117.202.179]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MFz0E-1Zzg0I2aBC-00EspP; Tue, 22 Dec 2015 08:46:28 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Christian Schudt In-Reply-To: Date: Tue, 22 Dec 2015 08:46:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2ED3EC8F-9693-4F9B-B7C6-C90A08A9ED1F@gmx.de> References: <3012FFC8-1FAD-4C30-8D85-175F4180BC02@gmx.de> To: Sam Whited X-Mailer: Apple Mail (2.3096.5) X-Provags-ID: V03:K0:xfaZ31nP+wkmFHK19x5ut0ZLDsPZPO72Y7m5qtOWItyG8kDMzFo TaGlvf68zoSVi+6qFlSSQynKRFiq1Wk8ey0DkrT5yFKgIFGIneKXpCRLWYRTzeM4LPPDG1f hxVjrSfKnMsfvjwg5XipJFd/5Q9sz92RaALpBDoQkDNh1y8XS9w2QZ48SC//0+f0n09tSZe HfIxAPiwmbcPEviP23ONw== X-UI-Out-Filterresults: notjunk:1;V01:K0:kB4UmOBHOeM=:IOMFauEtGMmMRBtg02VnPr RNZMHBQ0wsQ2p714IZMqdHOIeJ7vZQbNdmEWdn4UisWeDvHN/jNfBg4O0P2OuBr/rkk4d5Jzl 8Tr6F+IdbYxvWM7Uo+lMLbtF1rnI2JkbsKoMx3f/m1+LEGKZOGJjeWG71ELFDMrowsSieNfhW dNxhdpIGGA1yIyI44ZXtKHVM3zfJA8MOcQNh6V165Hf9++7nOzh8LGb8fISlDq5sF/5QfoS8T sgzC5O6WtG+4YqO/9F0qMiEmD9sgSYjqc7zMS+/hvKOccKGq6f1VClxBo/F9JN/TFKfclV4A8 0Ln/epQ/mV+kNj5oGpSOOsXBL+Vty3F33MGMHtbuZ+NDwTDbELMyWwSj7gKcwqExEfyBhoKfi hMH+LDC6wMYebaoNwspwknyWIrxbHOZIF9GnHJwmaPFakAaRL9McothfEq/VZucas5IXXukYK UeuStTZzQQaqXE7cXi2x+hwHEU2ftfFEh9PteaURopWRlJtZZ51hdm6NackPwF9SB9ZXvHcGG cSgjaFlyU4CQQsbFxWmDLnJtYVOT/cj+buWyRg8NffEQC3MwNJiwul0D3VTpUDmD1X9Ogr5o2 sZU+/5uu7Bcadn56xiLeF/iMcshR0C59v96hz1mvJswGDBqKZ3NZA8QO6MiudiMxpdIRkMGTS tzbjB8Ipf3n5EqY3Wxkj9c6Q7BStP/YohuF73AykaUL9aFDRqTHf3V276LRWQkmrkw0er/Kct apX6P48NQ+0ONbZfzkqlDnabcQkWe1lMWe/NbPmddQvgwI2eNQszBfGUuqPfWzd3PNp33LmgR EMaKz1b Archived-At: Cc: Peter Saint-Andre , precis@ietf.org Subject: Re: [precis] Precis Java Implementation X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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, 22 Dec 2015 07:46:38 -0000 > Am 22.12.2015 um 01:50 schrieb Sam Whited : >=20 > Another quick note: >=20 > In your case folding > = (https://bitbucket.org/sco0ter/precis/src/ecd82b75f3611dcb37ee0fd8890bfaf0= 2b5caf9f/src/main/java/rocks/xmpp/precis/PrecisProfile.java?at=3Dmaster&fi= leviewer=3Dfile-view-default#PrecisProfile.java-511), > shouldn't the locale be left undefined? Or does it specify that US > should be used as the default somewhere? I followed the recommendation here: = http://www.w3.org/International/wiki/Case_folding#Recommendations_for_Case= _Folding If left undefined, the system=E2=80=99s default locale is used, which = might not be the locale used for the =E2=80=9Ecommon case folding=E2=80=9C= , i.e. the one marked with a =E2=80=9EC=E2=80=9C in = ftp://ftp.unicode.org/Public/UCD/latest/ucd/CaseFolding.txt. Most = prominent example seems to be the special case for the Turkish I. From nobody Tue Dec 22 18:05:23 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A51D11A6F87 for ; Tue, 22 Dec 2015 18:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.921 X-Spam-Level: * X-Spam-Status: No, score=1.921 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_62=0.6, SPF_PASS=-0.001] autolearn=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 13LCYH8s-0Xe for ; Tue, 22 Dec 2015 18:05:20 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::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 2FB5C1A1BDC for ; Tue, 22 Dec 2015 18:05:20 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id t125so155905400qkh.3 for ; Tue, 22 Dec 2015 18:05:20 -0800 (PST) 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-type:content-transfer-encoding; bh=BQeZxZRs4uYJJz5cdJAzGr2zP2zs1tcFPC24ollFJvo=; b=JWwYgD3NlqYKaH4gt29opIJqznujiY8NUqZmuPhhxnkWuuU3pHO6i+kWcxid+4/8jl m0H0ED1F2eL/CVmTFmkKPhZMbCEVDmbQZfE+OTUTFevTjGFL21PBxOoEZJ7anXD2IjG+ EfKo/14WDngmKvJsFZGt5FQ2/FkguwhqyESH4= 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-type:content-transfer-encoding; bh=BQeZxZRs4uYJJz5cdJAzGr2zP2zs1tcFPC24ollFJvo=; b=cSuqrWyNviwS/7hPyPBN8gdSsOGzCmjkXFPemhqIyVhsmB6xgZp/qePvQ+FT4TOKiM WlZy3QGBPVrYc3LF/QYJM5b/nM9/NdlHZ+dPITqpTseyPAkdstwOc3e2bjg5Ev5FBBTG fXY5RqFiMincU8doexGDIu4ehLET9krYLoXzlAU0sdPEyqlD9DX+G9r5x0B/13qt86vb MyO8fPGccrAmaKzNpcTSzjaS4g+1fsJiOsS/9BUC1yfA1NUf/4/WOFOf47j8V4l8d7yM NiXVIbfMEMXn8b0KuW8Kj5R6IU6HZdUdkAwvPbHLuqf2M2i4WTK6slFR8H/w6s/It72w /EXA== X-Gm-Message-State: ALoCoQm+T0iQQTtVQHWaNvLfWb5dQNmPsCaSBGfxDsCIINjs9jczJTpz6vxAD/2SowvOhXIXrYe/iI8ilTUqVIdOmFOrQNNKMw== X-Received: by 10.55.31.95 with SMTP id f92mr1416169qkf.50.1450836319289; Tue, 22 Dec 2015 18:05:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.10.133 with HTTP; Tue, 22 Dec 2015 18:04:39 -0800 (PST) X-Originating-IP: [172.56.6.89] In-Reply-To: References: <3012FFC8-1FAD-4C30-8D85-175F4180BC02@gmx.de> From: Sam Whited Date: Tue, 22 Dec 2015 20:04:39 -0600 Message-ID: To: Christian Schudt Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: precis@ietf.org Subject: Re: [precis] Precis Java Implementation X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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, 23 Dec 2015 02:05:21 -0000 On Mon, Dec 21, 2015 at 4:08 PM, Christian Schudt wrote: > If you mean having a huge code point table, like in your tables.go file: = I think Java already has such tables internally. > What could be improved here, is that Character.getType(cp) could only be = invoked once. I haven=E2=80=99t done any benchmark for this, but I don=E2= =80=99t expect a significant performance benefit. Out of curiosity, I answered my own question here. I'm using Go, which also has lots of Unicode tables in the standard library, so I benchmarked running the algorithm (I modified it slightly from the version in my generator to remove the NFKC step, which is very slow, this way it more closely resembles your algorithm), and looking up a value in the large pre-generated trie. I have no idea where the bottlenecks / optimizations in Java would be, so these results may be meaningless to you, but, at least in Go, the single Trie lookup was much faster: $ go test -bench . -benchmem PASS BenchmarkAsciiLookup-4 300000000 3.85 ns/op 0 B/op 0 allocs/op BenchmarkFullwidthLookup-4 200000000 9.21 ns/op 0 B/op 0 allocs/op BenchmarkAsciiCalculate-4 100000000 17.4 ns/op 0 B/op 0 allocs/op BenchmarkFullwidthCalculate-4 20000000 71.4 ns/op 0 B/op 0 allocs/op ok _/home/sam/Projects/golang-x-text/unicode/precis 7.632s Each test here is looking up or calculating the derived properties for a single character (the ASCII tests are looking up 'u' and the Unicode tests are looking up '=EF=BD=95' [full width] which was chosen very scientifically, I assure you), the second column is the number of tests that were run until the timings reached equilibrium. For the worst case, there's a pretty good speed difference, whether that difference is worth pre-generating the data is another matter, of course =E2=98=BA Best, Sam --=20 Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com From nobody Tue Dec 22 20:58:41 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98D41AC3F5 for ; Tue, 22 Dec 2015 20:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham 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 odSyUKnA_2hk for ; Tue, 22 Dec 2015 20:58:38 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 475D31AC3F2 for ; Tue, 22 Dec 2015 20:58:38 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 9CED018000D; Tue, 22 Dec 2015 20:58:26 -0800 (PST) To: peter@andyet.com, ben@nostrum.com, alissa@cooperw.in, barryleiba@computer.org, Marc.Blanchet@viagenie.ca, alexey.melnikov@isode.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20151223045826.9CED018000D@rfc-editor.org> Date: Tue, 22 Dec 2015 20:58:26 -0800 (PST) Archived-At: Cc: precis@ietf.org, rfc-editor@rfc-editor.org Subject: [precis] [Technical Errata Reported] RFC7700 (4570) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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, 23 Dec 2015 04:58:39 -0000 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 Dec 23 01:16:30 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0CE71ACDFD for ; Wed, 23 Dec 2015 01:16:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 RfrAsKEwPK9y for ; Wed, 23 Dec 2015 01:16:26 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56C751ACDFA for ; Wed, 23 Dec 2015 01:16:25 -0800 (PST) Received: from christihudtsmbp.fritz.box ([95.117.202.179]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MbaS9-1ZvNAJ2byv-00J4AG; Wed, 23 Dec 2015 10:16:22 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Christian Schudt In-Reply-To: Date: Wed, 23 Dec 2015 10:16:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8581502F-058F-4A21-A1A4-454BC0734DE8@gmx.de> References: <3012FFC8-1FAD-4C30-8D85-175F4180BC02@gmx.de> To: Sam Whited X-Mailer: Apple Mail (2.3096.5) X-Provags-ID: V03:K0:OBnlFokzSFttKFOCx9n39UEEPVsZJqMl3+QrwyuOFP8Jf+d4GMg R1lQJuwhiy6Zal9IEYpZFx3kGzrroIkBtk5v34SPCQnegZ2PIV1BXErUkznaL3Svpx0vxZf MK88dKLGvSrUGUUwZhsT7alKZiNQnmwgujfY0uvhDzxVoaTUfA+fmjadXiHWoxj5B+bSPTh jI4mGK+JFlmMBS6pdSk4Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:o7b6XVq+1Co=:O1HrhHriQ/gmvBO0hvGRJ2 49OR5EquwFtcVpH2JFNnUuFvFERmBsn1QiLnkZkA58XiLZje+J5tzmpFE0Rniq/kSNre/SKut Kt+3qBazE5dBvrBqT2KaASysLYHGxjlSYGNaVzh8J8KSsnQCm2SMrTntb4kMg85Ir4cXjreQp wrAbaNsZmWPdvx+Nba8Za5cUmeIgYZGMS/atq4VwmldkVQsDwvbUyHZvgC6KRFt27fdjZ71yA NQq3RclaSFbTyRW+OWgkXLOar/oPSrEtBo46QHV4vjSKgJ2eX2gBvGKVMcB6OLa6OTFm2aXTC mnOJ7yOpLKH02z/8l7LiDDzxiyqbSyioeFIGPQiWyLxrcOPK9L0puMr8gZAzd8mEQWH+sTD12 4reS+XIJ4zUtbKun4NqXBVrQHOmrG7aOHNXjq9hwMvX/WhRh1ZVeCXWc3BDCHTxIIWVHKCnR6 Kj7lwpHvXyrqxtcY++AvTgCf48qXwP/BLkFui2Ii9NwnwkzEB90deBS5UedKjBE9DQ2l3UY2R tFXJjW7nvU3/agc7TfvhMS86mq6/DERzrGVFuiOUzhnged9TFzf/Gb1XS/JLb8XN//1FKpsam S6SjJRghTWokCZygwhYt2qnjUHHCyn1NwpCmQIlUyBWnSlxVoIhwjyXKIMxQHrBvE4/JWq2fe 9TR0hqWGFsH65HNTONSf8ZhTckekiWm1wCNUWj/GIJJdDfOEp5H53uKilV4vbBQt61My/letW WKGTqd6BmrQZMWih/kLjVHoTvh9L3nVADyYAflHJDvbNIZ3CvApEZ3N+JYzwDMOLlPAER57Ow lOfPFOx Archived-At: Cc: precis@ietf.org Subject: Re: [precis] Precis Java Implementation X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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, 23 Dec 2015 09:16:29 -0000 If you are interested, in Java getting the character type (property) is = even a bit slower, but it=E2=80=99s of course machine dependent: java.lang.Character.getType(codepoint) is constantly 39 ns/op on = 300000000 iterations on my machine, no matter if it=E2=80=99s an ascii = or a fullwidth character. (Oracle JDK 8 SE). Java uses huge Unicode arrays internally to lookup the code point, I = doubt that there=E2=80=99s much room for optimization and even if, = probably nobody cares when saving a few nano seconds. =E2=80=94 Christian > Am 23.12.2015 um 03:04 schrieb Sam Whited : >=20 > On Mon, Dec 21, 2015 at 4:08 PM, Christian Schudt > wrote: >> If you mean having a huge code point table, like in your tables.go = file: I think Java already has such tables internally. >> What could be improved here, is that Character.getType(cp) could only = be invoked once. I haven=E2=80=99t done any benchmark for this, but I = don=E2=80=99t expect a significant performance benefit. >=20 > Out of curiosity, I answered my own question here. I'm using Go, which > also has lots of Unicode tables in the standard library, so I > benchmarked running the algorithm (I modified it slightly from the > version in my generator to remove the NFKC step, which is very slow, > this way it more closely resembles your algorithm), and looking up a > value in the large pre-generated trie. I have no idea where the > bottlenecks / optimizations in Java would be, so these results may be > meaningless to you, but, at least in Go, the single Trie lookup was > much faster: >=20 > $ go test -bench . -benchmem > PASS > BenchmarkAsciiLookup-4 300000000 3.85 ns/op > 0 B/op 0 allocs/op > BenchmarkFullwidthLookup-4 200000000 9.21 ns/op > 0 B/op 0 allocs/op > BenchmarkAsciiCalculate-4 100000000 17.4 ns/op > 0 B/op 0 allocs/op > BenchmarkFullwidthCalculate-4 20000000 71.4 ns/op > 0 B/op 0 allocs/op > ok _/home/sam/Projects/golang-x-text/unicode/precis 7.632s >=20 > Each test here is looking up or calculating the derived properties for > a single character (the ASCII tests are looking up 'u' and the Unicode > tests are looking up '=EF=BD=95' [full width] which was chosen very > scientifically, I assure you), the second column is the number of > tests that were run until the timings reached equilibrium. >=20 > For the worst case, there's a pretty good speed difference, whether > that difference is worth pre-generating the data is another matter, of > course =E2=98=BA >=20 > Best, > Sam >=20 >=20 > --=20 > Sam Whited > pub 4096R/54083AE104EA7AD3 > https://blog.samwhited.com From nobody Wed Dec 23 07:03:01 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7365D1A017E for ; Wed, 23 Dec 2015 07:03:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=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 9yxLda4pKs00 for ; Wed, 23 Dec 2015 07:02:59 -0800 (PST) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::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 257CF1A017F for ; Wed, 23 Dec 2015 07:02:59 -0800 (PST) Received: by mail-qg0-x22d.google.com with SMTP id 6so735907qgy.1 for ; Wed, 23 Dec 2015 07:02:59 -0800 (PST) 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-type:content-transfer-encoding; bh=/8sZqEsLXJTIgLkm7VW1XSiqLcu0f3Mdx1DPo8PBBt4=; b=utYe7zt6iBZExmAUt38VEGdwFPefg2/oZ3gefW576bo3oyfdkYv8jD1X6/ZQXHfCYr 2Z+rmdH7K+90kv23oX9NMcmL1PxhuEzhHkPFMjF7POO2DiYSCojYrwEnfFZ0MfKmZ+MZ jU8r410yfbEjdNJSYgAHrBThAhROnXkKvBsUY= 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-type:content-transfer-encoding; bh=/8sZqEsLXJTIgLkm7VW1XSiqLcu0f3Mdx1DPo8PBBt4=; b=b/2D5P6pDQ3lg7ggXQOXYu7oa+ozVUharpy7L90UgLcmAjoIQou7hb3lYvJF45LfAS ccnbQQqxkCb+6lX1EcO095wnqLIZX+1IsCSR8V48a0D9YAFxeUC+ZxJiXdTzyXz04eT7 WCXqqf36QTJ6v1EhTEM6HHV4qe5z/4JyuKYvPQg2gOlkyPVGe5qb1ahmQPMSpnhs4APM Lq0jO+Npa6FoxoTpFdW05SOAGOTmg6SeFIRgfUS3NpsJqnUjaCz4l2/TRDvuLfM7QTJv lp5FRM34RhDyh7PCR6fpbPnauSOY31ZzGSP8CjOOXRusMTgBnSIDtHBWD6tJkU2XamoK vFXQ== X-Gm-Message-State: ALoCoQnyq5q6fCoORk7t8l/X8hjoWDwR64hVlYN23ezPjF7XrioDzid3EOd+4M5kuOZuAgSKKplXWvE01shSapLGhj/8g3u0FQ== X-Received: by 10.140.234.17 with SMTP id f17mr43951375qhc.19.1450882978290; Wed, 23 Dec 2015 07:02:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.10.133 with HTTP; Wed, 23 Dec 2015 07:02:18 -0800 (PST) X-Originating-IP: [72.48.156.244] In-Reply-To: <8581502F-058F-4A21-A1A4-454BC0734DE8@gmx.de> References: <3012FFC8-1FAD-4C30-8D85-175F4180BC02@gmx.de> <8581502F-058F-4A21-A1A4-454BC0734DE8@gmx.de> From: Sam Whited Date: Wed, 23 Dec 2015 09:02:18 -0600 Message-ID: To: Christian Schudt Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: precis@ietf.org Subject: Re: [precis] Precis Java Implementation X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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, 23 Dec 2015 15:03:00 -0000 On Wed, Dec 23, 2015 at 3:16 AM, Christian Schudt wrote: > If you are interested, in Java getting the character type (property) is e= ven a bit slower, but it=E2=80=99s of course machine dependent: > > java.lang.Character.getType(codepoint) is constantly 39 ns/op on 30000000= 0 iterations on my machine, no matter if it=E2=80=99s an ascii or a fullwid= th character. (Oracle JDK 8 SE). > Java uses huge Unicode arrays internally to lookup the code point, I doub= t that there=E2=80=99s much room for optimization and even if, probably nob= ody cares when saving a few nano seconds. Thanks! I actually am really interested; I used to do a lot of work on Conversations (Android XMPP client) and was the one who originally wrote the JID class / stringprep stuff for it. I'm planning on updating it to use your library at some point, and my work roster is rather large (several thousand people) which makes things incredibly slow with the current stringprep implementation; I'm hoping this will be a lot faster! Thanks again for all your hard work on this. Best, Sam --=20 Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com From nobody Wed Dec 23 07:10:34 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B147E1A01C6 for ; Wed, 23 Dec 2015 07:10:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=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 UUJs-3g6mAvZ for ; Wed, 23 Dec 2015 07:10:32 -0800 (PST) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::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 3CA021A01D5 for ; Wed, 23 Dec 2015 07:10:32 -0800 (PST) Received: by mail-qg0-x22a.google.com with SMTP id o11so78630638qge.2 for ; Wed, 23 Dec 2015 07:10:32 -0800 (PST) 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-type; bh=d16xqHlBa6s6g0hsO9XuPPar6A8M6vGedZtcd5Qr7LM=; b=Yzpy4oPlnT/mv3egaXu4GZfwqolRD0UgcLZNImfXf1SuH1t0AuTgsQfOlXguKvCqkf XuVutPixlr8nwXy6hrOF5AL6Tq87ooc1YzAmv7wpqVwsO0JjPw3CJmze0/1gVDawrZDa x5ahdhHDYd1XC0mmQILsEwOjttIFZ9Q0k2TAs= 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-type; bh=d16xqHlBa6s6g0hsO9XuPPar6A8M6vGedZtcd5Qr7LM=; b=QPyyM0G7yT3Spxsw2jzAuja2RiAGgmrWhKrtLOVc07lGeWrdmCLFPKifVrqpfnva+8 NdlFZoyKZy8VzM4lzuySB/cG/fKypQwnxtv+kFL2AcLjwl939LSSAs8sfeTE4tMmvazM fuz3jS1zubWBODczewKCkuHxdizbMB/hfkA4Siy4dnWHBCFbZeGZuunjHo8r3CdGVZBT tJHt6pI4fGntoIJKvhynTaP86YYAgskrJTj8sgaA+jFtpP9zU2+mQxjGL6YcYGTRBLtR eTfFQZrwNWZmngGzeZbGxowwyM63k6Ci6LBrrPxvk2hKAXdPPE0EQGe2flAgNneSbIbS 7gIQ== X-Gm-Message-State: ALoCoQmnOPYLkesKJamywaYqce1Yp+Si+nHOAgDYpi6SydvFU7TutBIP+z+wB7f71WPBQFUd/n4fw+b+M7YKDEyAG+ZJKlIZNA== X-Received: by 10.140.22.212 with SMTP id 78mr40442047qgn.17.1450883431388; Wed, 23 Dec 2015 07:10:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.10.133 with HTTP; Wed, 23 Dec 2015 07:09:51 -0800 (PST) X-Originating-IP: [72.48.156.244] In-Reply-To: <20151223045826.9CED018000D@rfc-editor.org> References: <20151223045826.9CED018000D@rfc-editor.org> From: Sam Whited Date: Wed, 23 Dec 2015 09:09:51 -0600 Message-ID: To: RFC Errata System Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: alissa@cooperw.in, Peter Saint-Andre , precis@ietf.org, barryleiba@computer.org Subject: Re: [precis] [Technical Errata Reported] RFC7700 (4570) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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, 23 Dec 2015 15:10:33 -0000 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), 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). 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 > -- Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com