From alexey.melnikov@isode.com Fri Oct 4 05:58:49 2013 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 B7C5B21F9A50; Fri, 4 Oct 2013 05:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QAgKX+tN9rD; Fri, 4 Oct 2013 05:58:37 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 37D5821F9C6C; Fri, 4 Oct 2013 05:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1380890798; d=isode.com; s=selector; i=@isode.com; bh=sO6LzNF9k6sRDyL4jDgNwqKUCf61u6HAzj/wHolx9js=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=UYCzZpMB59G6fEcqk98DvuVHpZL+LEA93aUnhnNQx4U3SpVhWaRaQ9lygIoXYer0mX/WT/ BuQ4iAsvPOGprUQzaq61CqJ/LNvxxIrKskA+zdqwaQ0lqb4w4B6lgrZ33uLjsirUgcid9Z Zu8r32iFpBWDiueLglFSKlW1jkEK2gY=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 4 Oct 2013 13:46:35 +0100 Message-ID: <524EB8B4.2000509@isode.com> Date: Fri, 04 Oct 2013 13:46:44 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 To: Simon Josefsson References: <51FEEC99.1020901@stpeter.im> <52090F96.30700@stpeter.im> <522E5CAA.5010902@stpeter.im> <5230B3B3.3040805@babelmonkeys.de> <87zjr2pmhs.fsf@latte.josefsson.org> <87txharmne.fsf@latte.josefsson.org> <20130924231746.73c578b7@latte.josefsson.org> In-Reply-To: <20130924231746.73c578b7@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" , Sam Hartman , "precis@ietf.org" Subject: Re: [precis] [kitten] Fwd: Re: I-D Action: draft-ietf-precis-saslprepbis-04.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 12:58:50 -0000 On 24/09/2013 22:17, Simon Josefsson wrote: > You wrote: >>>>>>> "Simon" == Simon Josefsson writes: >> Simon> like HTTP, FTP, SMTP, SSH, etc could be revised. I don't >> Simon> believe any of that will happen, so we'll have to live with >> Simon> case sensitive usernames, and my take is that I18N >> Simon> documents should permit that. >> >> I'm not sure any of the above hase case sensitive usernames. >> They permit usernames to be case sensitive. >> However a lot of implementations treat the username as case >> insensitive. >> >> I do think this is an appropriate issue for an IETF an document, but I >> do think considering the impact on legacy systems is important. >> I don't think we need to require there be no impact, simply understand >> an accept it. > Agreed, but the devil is in the detail. For example, I would say that > any I18N effort that changes how ASCII usernames ([A-Za-z0-9...]) > behave have gone too far down the road that causes damage to legacy > systems. Case folding for usernames in draft-ietf-precis-saslprepbis-04.txt is a SHOULD, so I think you are Ok. I.e. compatibility with a legacy system is a good enough reason to violate the SHOULD. > For passwords, there are also security aspects, since case > folding reduces entropy. draft-ietf-precis-saslprepbis-04.txt recommends against case folding for passwords. > Maybe in some of these details we can find > were we agree and disagree. From nico@cryptonector.com Fri Oct 4 14:16:31 2013 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 877D021F9EA8; Fri, 4 Oct 2013 14:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYsCYWhdBT6Y; Fri, 4 Oct 2013 14:16:26 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF7A21F9C52; Fri, 4 Oct 2013 14:16:23 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 316B76B007F; Fri, 4 Oct 2013 14:16:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=FGTHPMI1Swkub5gi/4ER ACmEZEA=; b=twvv7x67pFfy70TYrm2fO9EQ/D+39ZDW+GQq4x+OYFIgq3dgAaif SIUm2B4j90gwf0AwsB9pcm+jzMK1pjSL2EihbQf6ZLTHCNQtx1Mf5babE2FUOzB9 PnKMoJSss7NH4485X91Lf+DRSnrMLy8JF4D8pY5LY4ajDX8zTmVqxKw= Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id A2F6E6B007E; Fri, 4 Oct 2013 14:16:22 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id m15so4658652wgh.21 for ; Fri, 04 Oct 2013 14:16:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=f1C+vcUSEUlGkJL5+bsDpCcEBuEYJjoGlHoOuxTdQcY=; b=ATyXGPr+FDCqto6/rYX+UfhJqzjWqZmpYBCMXj8gVkpIWaBNaJAB9xTowLARXg1OxW 5lx356oNvLxdSnIot8q0EmgOqb1+Bw412zM7x5oi+/yS83aRMsey5cu0HwtXgPlQd10Z c/NPjD2WGKx/6pFRvud2cUtKWYTwkPFoIuUXmZ+aAK/lBzRSdAZE2kRBKGFdVKMfRZ0X bhl4yID2YKbByepsG9sUi6O0LnLD3MddXnK+HSA2ogIb/luhr4uxZwm6xW7q+QhFN6Vw YFJyGnBj4eBlJGy9KYjhGEkeoBlFJF+LLL2ycP+fFA2dfL395wwX2HjU6DEXVG9C5fsY o5+g== MIME-Version: 1.0 X-Received: by 10.194.242.200 with SMTP id ws8mr15744wjc.60.1380921381178; Fri, 04 Oct 2013 14:16:21 -0700 (PDT) Received: by 10.216.165.5 with HTTP; Fri, 4 Oct 2013 14:16:21 -0700 (PDT) In-Reply-To: <87txharmne.fsf@latte.josefsson.org> References: <51FEEC99.1020901@stpeter.im> <52090F96.30700@stpeter.im> <522E5CAA.5010902@stpeter.im> <5230B3B3.3040805@babelmonkeys.de> <87zjr2pmhs.fsf@latte.josefsson.org> <87txharmne.fsf@latte.josefsson.org> Date: Fri, 4 Oct 2013 16:16:21 -0500 Message-ID: From: Nico Williams To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Sam Hartman , "precis@ietf.org" Subject: Re: [precis] [kitten] Fwd: Re: I-D Action: draft-ietf-precis-saslprepbis-04.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 21:16:31 -0000 On Tue, Sep 24, 2013 at 3:27 PM, Simon Josefsson wrote: > I disagree that an I18N document is the appropriate way to move the > Internet to case-insensitive usernames. > > If case-sensitive usernames is a significant problem, then it should be > possible to publish a BCP recommending against that. Then existing > protocols with case-sensitive usernames like HTTP, FTP, SMTP, SSH, etc > could be revised. I don't believe any of that will happen, so we'll > have to live with case sensitive usernames, and my take is that I18N > documents should permit that. I agree. Also, there's a lot of work to do to get there, particularly enrollment (account creation) time work. We can't merely specify a case-insensitive stringprep profile. Nico -- From ajs@anvilwalrusden.com Fri Oct 4 20:07:56 2013 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 D85AF21F9B9F for ; Fri, 4 Oct 2013 20:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIjQ0nuYlvy3 for ; Fri, 4 Oct 2013 20:07:51 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id C6AF821F9E44 for ; Fri, 4 Oct 2013 20:07:49 -0700 (PDT) Received: from mx1.yitter.info (unknown [64.130.246.86]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 651CC8A031 for ; Sat, 5 Oct 2013 03:07:48 +0000 (UTC) Date: Fri, 4 Oct 2013 23:07:51 -0400 From: Andrew Sullivan To: precis@ietf.org Message-ID: <20131005030751.GB38902@mx1.yitter.info> References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [precis] WGLC: draft-ietf-precis-framework-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 05 Oct 2013 03:07:57 -0000 Dear colleagues, On Wed, Aug 28, 2013 at 03:46:03PM +0900, Yoshiro YONEYA wrote: > The WGLC will end on Wednesday, Sep 11th. On the principle of "better late than never", I at last got to this document. Many apologies for taking so long. First, let me say that this is one of the best drafts I've read in some time. It's in very good shape, I think, and could go as it is. Naturally, however, I cannot help suggesting some gilt to go on that lily. The editors should feel free to ignore any or all of this. There was one largish issue that troubled me. The discussion in 9.5 basically talks about the risks from enormous character repertoires, and I wondered whether people won't start asking for a way to negotiate locale or something similar as a mechanism for narrowing the choices. Certainly, something along these lines has been requested (not to say "vehemently demanded") over and over for IDNA. In IDNA it's completely impractical, owing to caches, the need for compatibility with existing DNS stuff, and so on. It strikes me as pretty impractical here, too, but I thought I'd raise it if only so we can put it down. (I'm also aware that it's pretty late in the game to suggest this. Why it only struck me today I don't know. I have a dim memory of having discussed this once before, but I didn't find anything in the archive.) The paragraph in section 3.1 starting, "Although members of the community discussed the possibility of defining other PRECIS string classes " read oddly to me. As an alternative I can suggest, "Although it might be possible to create an additional class that falls somewhere between IdentifierClass and FreeformClass, it is not clear how useful such a class would be. In any case, because of the ability to subclass FreeformClass, a protocol needing something more particular is always able to create it." I don't really care about this; it was just something that struck me on the way by. The order of operations is laid out in section 3.2, but is really sort of explained in section 3.4.4. It might be nice to put at least a forward pointer in section 3.2 so that someone who knows what an NFKC is won't start spluttering. In section 6.7, I want to make sure we're ok with following IDNA2008's lead on U+19DA, which moved from PVALID to DISALLOWED in Unicode 6.0. In the precis case, it's FREE_PVAL. I think that's fine, but I just want to call attention. I caught one typo in section 9.5: "stings". (I think my giggling over this might have alarmed the passenger next to me today.) Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Fri Oct 4 20:17:50 2013 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 7199B21F9DDE for ; Fri, 4 Oct 2013 20:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5gxGjyV6EZ7 for ; Fri, 4 Oct 2013 20:17:44 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id AA9D521F9E00 for ; Fri, 4 Oct 2013 20:17:44 -0700 (PDT) Received: from mx1.yitter.info (unknown [64.130.246.86]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id CA9678A031 for ; Sat, 5 Oct 2013 03:17:43 +0000 (UTC) Date: Fri, 4 Oct 2013 23:17:46 -0400 From: Andrew Sullivan To: precis@ietf.org Message-ID: <20131005031746.GC38902@mx1.yitter.info> References: <5227A979.7050403@stpeter.im> <4C8248EF-51BD-4736-A930-E2FEE610EC03@kmd.keio.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4C8248EF-51BD-4736-A930-E2FEE610EC03@kmd.keio.ac.jp> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [precis] local case mapping X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 05 Oct 2013 03:17:50 -0000 Dear colleagues, I reviewed draft-ietf-precis-mappings-03 today, at long last. I apologise for being so late. I put together a number of incoherent questions about the case folding stuff, but fortunately I re-read the mailing list archives on this topic before posting a long message. I agree with Peter: I find this section of the document very confusing, and I think it may be wrong. In particular … On Thu, Sep 19, 2013 at 04:39:12PM +0900, Takahiro Nemoto wrote: > Considering the maintenance and preservation of the document, > leaving it the way it is now is not a bad idea. …I am pretty sure it shouldn't be left the way it is. It seems to me that our principle generally needs to be that Unicode is the thing we use, and if Unicode is broken it's Not Our Problem. So we should figure out how to say, "Do the Unicode-y right thing here," and then put that in. I especially don't want to get into specifying special language-specific tables ourselves: we don't have the expertise, I think. I can't think of any better suggested text than what Peter already sent, so I think that's the right direction. In the unlikely event something clearer comes to me in the night, I promise to write it down. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From duerst@it.aoyama.ac.jp Mon Oct 7 03:22:24 2013 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 AE2C621E81F7 for ; Mon, 7 Oct 2013 03:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.29 X-Spam-Level: X-Spam-Status: No, score=-103.29 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIR3NQYcC6KW for ; Mon, 7 Oct 2013 03:22:16 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id B17B021E81EF for ; Mon, 7 Oct 2013 03:22:07 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r97ALvfc030453; Mon, 7 Oct 2013 19:21:58 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 6912_2fe9_4bdf593c_2f3a_11e3_9aa0_001e6722eec2; Mon, 07 Oct 2013 19:21:57 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 07FB2BFF7E; Mon, 7 Oct 2013 19:21:57 +0900 (JST) Message-ID: <52528B3A.7020700@it.aoyama.ac.jp> Date: Mon, 07 Oct 2013 19:21:46 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Andrew Sullivan References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> <20131005030751.GB38902@mx1.yitter.info> In-Reply-To: <20131005030751.GB38902@mx1.yitter.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: precis@ietf.org Subject: Re: [precis] WGLC: draft-ietf-precis-framework-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 07 Oct 2013 10:22:24 -0000 On 2013/10/05 12:07, Andrew Sullivan wrote: > Dear colleagues, > > On Wed, Aug 28, 2013 at 03:46:03PM +0900, Yoshiro YONEYA wrote: >> The WGLC will end on Wednesday, Sep 11th. > > On the principle of "better late than never", I at last got to this > document. Many apologies for taking so long. I was just starting reading the document yesterday, so same applies here. > There was one largish issue that troubled me. The discussion in 9.5 > basically talks about the risks from enormous character repertoires, > and I wondered whether people won't start asking for a way to > negotiate locale or something similar as a mechanism for narrowing the > choices. Certainly, something along these lines has been requested > (not to say "vehemently demanded") over and over for IDNA. In IDNA > it's completely impractical, owing to caches, the need for > compatibility with existing DNS stuff, and so on. It strikes me as > pretty impractical here, too, but I thought I'd raise it if only so we > can put it down. (I'm also aware that it's pretty late in the game to > suggest this. Why it only struck me today I don't know. I have a dim > memory of having discussed this once before, but I didn't find > anything in the archive.) I'm not yet at 9.5, but I definitely agree with Andrew. Let's make sure we put a very big nail through that coffin (or whatever the correct idiom is). > The paragraph in section 3.1 starting, "Although members of the > community discussed the possibility of defining other PRECIS string > classes " read oddly to me. Same here, but for different reasons. The WG is publishing a document with user name and password profiles at (roughly, at least?) the same time as this one. Why are we saying "two is enough" but then doing more? Maybe the user name/password ones aren't classes, or whatever, but a slight rewording would go a long way here to help avoid the impression that the WG is at odds with itself. Something else occurred to me yesterday: Is PRECIS dealing with context-dependent characters (ZERO WIDTH JOINER/ZERO WIDTH NON JOINER,...)? IDNA2008 deals with them, but while a lot of other stuff is carefully noted in the introduction and in 3.1, this is totally missing. Either it should be added in these sections, or it should be added in PRECIS itself. Regards, Martin. From stpeter@stpeter.im Tue Oct 8 12:55:42 2013 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 9271821F9E6D for ; Tue, 8 Oct 2013 12:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YicXm6kyvBR9 for ; Tue, 8 Oct 2013 12:55:35 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1154521F9D69 for ; Tue, 8 Oct 2013 12:55:35 -0700 (PDT) Received: from sjc-vpn5-1390.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7B254414D9; Tue, 8 Oct 2013 14:01:26 -0600 (MDT) Message-ID: <5254632F.6060106@stpeter.im> Date: Tue, 08 Oct 2013 13:55:27 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Andrew Sullivan References: <5227A979.7050403@stpeter.im> <4C8248EF-51BD-4736-A930-E2FEE610EC03@kmd.keio.ac.jp> <20131005031746.GC38902@mx1.yitter.info> In-Reply-To: <20131005031746.GC38902@mx1.yitter.info> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: precis@ietf.org Subject: Re: [precis] local case mapping X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 08 Oct 2013 19:55:42 -0000 Hi Andrew, thanks for helping to move things forward. On 10/4/13 9:17 PM, Andrew Sullivan wrote: > Dear colleagues, > > I reviewed draft-ietf-precis-mappings-03 today, at long last. I > apologise for being so late. No worries. Better that we get it right than that we finish it quickly. Or maybe that's just a convenient excuse. :-) > I put together a number of incoherent questions about the case folding > stuff, but fortunately I re-read the mailing list archives on this > topic before posting a long message. I agree with Peter: I find this > section of the document very confusing, and I think it may be wrong. > In particular … > > On Thu, Sep 19, 2013 at 04:39:12PM +0900, Takahiro Nemoto wrote: > >> Considering the maintenance and preservation of the document, >> leaving it the way it is now is not a bad idea. > > …I am pretty sure it shouldn't be left the way it is. > > It seems to me that our principle generally needs to be that Unicode > is the thing we use, and if Unicode is broken it's Not Our Problem. > So we should figure out how to say, "Do the Unicode-y right thing > here," and then put that in. I especially don't want to get into > specifying special language-specific tables ourselves: we don't have > the expertise, I think. > > I can't think of any better suggested text than what Peter already > sent, so I think that's the right direction. In the unlikely event > something clearer comes to me in the night, I promise to write it > down. I suggested text to clear up the first paragraph. However, my message merely asked the key question, but left it unanswered: what are we trying to accomplish here? As I noted, Appendix B.1 simply matches the Language-Sensitive Mappings from the SpecialCasing.txt file in the Unicode Character Database. If that's *all* we're trying to accomplish, then we could simply say "apply the Language-Sensitive Mappings in SpecialCasing.txt". However, I get the sense that we're actually trying to accomplish more, e.g., applying at least the context-sensitive mapping for Greek final sigma -- in my example, a nickname of "ΦΙΛΟΣ ΜΟΙ" would be case folded to "φιλος μοι" (with a Greek final sigma, which is correct in Greek) and not to "φιλοσ μοι" (with a Greek medial sigma, which is incorrect in Greek). It's also not clear to me if we have a position on full case folding vs. simple case folding (e.g., ẞ = U+1E9E to "ss" instead of "ß" = U+00DF). It seems to me that we might want to suggest a consistent approach here so that we have improved interoperability. So IMHO one approach would be: 1. Apply the language-sensitive mappings from SpecialCasing.txt 2. Apply the context-sensitive (i.e., "language-insensitive") mappings from SpecialCasing.txt I'm still not sure what to do about about full vs. simple case mapping, but I see no strong reason to prefer simple case mapping because I don't see a problem with our algorithm resulting in two characters (e.g., "ss") instead of one. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Tue Oct 8 13:55:23 2013 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 7CB6721F9CA6 for ; Tue, 8 Oct 2013 13:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwCdfZ1YXNKP for ; Tue, 8 Oct 2013 13:55:11 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id ED1D721F9CB5 for ; Tue, 8 Oct 2013 13:55:08 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E9E45414D9; Tue, 8 Oct 2013 15:01:02 -0600 (MDT) Message-ID: <52547128.5070909@stpeter.im> Date: Tue, 08 Oct 2013 14:55:04 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Joseph Yee References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> <20130904162558.7fad8dd5d2304591166dd37a@jprs.co.jp> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: precis@ietf.org Subject: Re: [precis] WGLC: draft-ietf-precis-framework-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 08 Oct 2013 20:55:23 -0000 On 9/11/13 8:06 PM, Joseph Yee wrote: > > On Wed, Sep 4, 2013 at 3:25 AM, Yoshiro YONEYA > > wrote: > > Dear all, > > This is reminder. WG LC will end next week. > Please review the document and give your feedback. > > Regards, > > -- Marc & Yoneya, co-chairs > > On Wed, 28 Aug 2013 15:46:03 +0900 Yoshiro YONEYA > > wrote: > > > Dear all, > > > > This message starts two weeks Working Group Last Call (WGLC) on > > draft-ietf-precis-framework-09.txt (PRECIS Framework: Preparation and > > Comparison of Internationalized Strings in Application Protocols). > > > > Please review the document and send comments to the list > (precis@ietf.org ), > > the co-chairs (precis-chairs@tools.ietf.org > ), or the authors > > (draft-ietf-precis-framework@tools.ietf.org > ) by the end of WGLC. > > > > The WGLC will end on Wednesday, Sep 11th. > > > > > Reviewed the draft, think the approach is good. Just one minor comment. > > Same as Florian, had the 'hmm' reaction when reading about > directionality and application behaviour at Section 3.1. It seems that > the only application behaviour is permitted pattern. It doesn't deal > with visual appearance I believed. Maybe replace 'application > behaviour' with 'permitted patther of the string' (or 'allowed > combination of the string')? Hmm, I see why you and Florian don't like that text. :-) How about this? OLD Directionality: defines application behavior in the presence of code points that have directionality, in particular right-to-left code points as defined in the Unicode database (see [UAX9]). NEW Directionality: defines which strings are to be considered left-to-right (LTR) and right-to-left (RTL), and the allowable sequences of characters in LTR and RTL strings. Peter -- Peter Saint-Andre https://stpeter.im/ From ajs@anvilwalrusden.com Tue Oct 8 14:16:26 2013 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 D567121F8E51 for ; Tue, 8 Oct 2013 14:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gr1cyFJiPcju for ; Tue, 8 Oct 2013 14:16:14 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 6982721F9831 for ; Tue, 8 Oct 2013 14:16:13 -0700 (PDT) Received: from mx1.yitter.info (dhcp-220-111.meetings.nanog.org [199.187.220.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 0BF7D8A031; Tue, 8 Oct 2013 21:16:11 +0000 (UTC) Date: Tue, 8 Oct 2013 17:16:12 -0400 From: Andrew Sullivan To: Peter Saint-Andre Message-ID: <20131008211611.GA45541@mx1.yitter.info> References: <5227A979.7050403@stpeter.im> <4C8248EF-51BD-4736-A930-E2FEE610EC03@kmd.keio.ac.jp> <20131005031746.GC38902@mx1.yitter.info> <5254632F.6060106@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5254632F.6060106@stpeter.im> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: precis@ietf.org Subject: Re: [precis] local case mapping X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 08 Oct 2013 21:16:27 -0000 On Tue, Oct 08, 2013 at 01:55:27PM -0600, Peter Saint-Andre wrote: > merely asked the key question, but left it unanswered: what are we > trying to accomplish here? Yeah, sorry that I wasn't clear. I think the issue may actually be that we can't decide which is needed, and there's a temptation to make this local policy. I think that's a bad idea: we should have one method. Decisions like this are what "the customers" wanted, I think. Therefore, > 1. Apply the language-sensitive mappings from SpecialCasing.txt > 2. Apply the context-sensitive (i.e., "language-insensitive") mappings > from SpecialCasing.txt > > I'm still not sure what to do about about full vs. simple case mapping, > but I see no strong reason to prefer simple case mapping because I don't > see a problem with our algorithm resulting in two characters (e.g., > "ss") instead of one. I think all of these are right (so I think we should say that we don't prefer simple case mapping also). A -- Andrew Sullivan ajs@anvilwalrusden.com From stpeter@stpeter.im Tue Oct 8 15:38:29 2013 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 A580711E8102 for ; Tue, 8 Oct 2013 15:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.894 X-Spam-Level: X-Spam-Status: No, score=-101.894 tagged_above=-999 required=5 tests=[AWL=0.705, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXDnTiOY6yum for ; Tue, 8 Oct 2013 15:38:23 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1814D11E8109 for ; Tue, 8 Oct 2013 15:38:23 -0700 (PDT) Received: from [192.168.1.3] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CB661414D9; Tue, 8 Oct 2013 16:44:18 -0600 (MDT) Message-ID: <52548959.1040306@stpeter.im> Date: Tue, 08 Oct 2013 16:38:17 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Andrew Sullivan References: <5227A979.7050403@stpeter.im> <4C8248EF-51BD-4736-A930-E2FEE610EC03@kmd.keio.ac.jp> <20131005031746.GC38902@mx1.yitter.info> <5254632F.6060106@stpeter.im> <20131008211611.GA45541@mx1.yitter.info> In-Reply-To: <20131008211611.GA45541@mx1.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: precis@ietf.org Subject: Re: [precis] local case mapping X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 08 Oct 2013 22:38:29 -0000 On 10/08/2013 03:16 PM, Andrew Sullivan wrote: > On Tue, Oct 08, 2013 at 01:55:27PM -0600, Peter Saint-Andre wrote: >> merely asked the key question, but left it unanswered: what are we >> trying to accomplish here? > Yeah, sorry that I wasn't clear. I think the issue may actually be > that we can't decide which is needed, and there's a temptation to make > this local policy. I think that's a bad idea: we should have one > method. Decisions like this are what "the customers" wanted, I > think. Agreed. > Therefore, > >> 1. Apply the language-sensitive mappings from SpecialCasing.txt >> 2. Apply the context-sensitive (i.e., "language-insensitive") mappings >> from SpecialCasing.txt >> >> I'm still not sure what to do about about full vs. simple case mapping, >> but I see no strong reason to prefer simple case mapping because I don't >> see a problem with our algorithm resulting in two characters (e.g., >> "ss") instead of one. > I think all of these are right (so I think we should say that we don't > prefer simple case mapping also). > > A > Well it's a bit mealy-mouthed for us to say we don't prefer simple case mapping. Better, I think, to say "apply full case mapping". Peter From ajs@anvilwalrusden.com Tue Oct 8 15:45:29 2013 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 32B9F21F92B8 for ; Tue, 8 Oct 2013 15:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYv6j+hFc4QY for ; Tue, 8 Oct 2013 15:45:23 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 026B721F92C2 for ; Tue, 8 Oct 2013 15:44:51 -0700 (PDT) Received: from mx1.yitter.info (dhcp-220-111.meetings.nanog.org [199.187.220.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 95D958A031; Tue, 8 Oct 2013 22:44:50 +0000 (UTC) Date: Tue, 8 Oct 2013 18:44:53 -0400 From: Andrew Sullivan To: Peter Saint-Andre Message-ID: <20131008224453.GG46045@mx1.yitter.info> References: <5227A979.7050403@stpeter.im> <4C8248EF-51BD-4736-A930-E2FEE610EC03@kmd.keio.ac.jp> <20131005031746.GC38902@mx1.yitter.info> <5254632F.6060106@stpeter.im> <20131008211611.GA45541@mx1.yitter.info> <52548959.1040306@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52548959.1040306@stpeter.im> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: precis@ietf.org Subject: Re: [precis] local case mapping X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 08 Oct 2013 22:45:29 -0000 On Tue, Oct 08, 2013 at 04:38:17PM -0600, Peter Saint-Andre wrote: > case mapping. Better, I think, to say "apply full case mapping". Sure, yes. A -- Andrew Sullivan ajs@anvilwalrusden.com From stpeter@stpeter.im Tue Oct 8 16:05:57 2013 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 E8F6721E80AE for ; Tue, 8 Oct 2013 16:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.862 X-Spam-Level: X-Spam-Status: No, score=-101.862 tagged_above=-999 required=5 tests=[AWL=0.437, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7LSYgcVMjxI for ; Tue, 8 Oct 2013 16:05:31 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BC44E21F8235 for ; Tue, 8 Oct 2013 16:03:59 -0700 (PDT) Received: from [192.168.1.3] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9C59241366; Tue, 8 Oct 2013 17:09:54 -0600 (MDT) Message-ID: <52548F5C.80302@stpeter.im> Date: Tue, 08 Oct 2013 17:03:56 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= , Andrew Sullivan References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> <20131005030751.GB38902@mx1.yitter.info> <52528B3A.7020700@it.aoyama.ac.jp> In-Reply-To: <52528B3A.7020700@it.aoyama.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: precis@ietf.org Subject: Re: [precis] WGLC: draft-ietf-precis-framework-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 08 Oct 2013 23:05:58 -0000 On 10/07/2013 04:21 AM, "Martin J. Dürst" wrote: > On 2013/10/05 12:07, Andrew Sullivan wrote: >> Dear colleagues, >> >> On Wed, Aug 28, 2013 at 03:46:03PM +0900, Yoshiro YONEYA wrote: >>> The WGLC will end on Wednesday, Sep 11th. >> >> On the principle of "better late than never", I at last got to this >> document. Many apologies for taking so long. > > I was just starting reading the document yesterday, so same applies here. > > >> There was one largish issue that troubled me. The discussion in 9.5 >> basically talks about the risks from enormous character repertoires, >> and I wondered whether people won't start asking for a way to >> negotiate locale or something similar as a mechanism for narrowing the >> choices. Certainly, something along these lines has been requested >> (not to say "vehemently demanded") over and over for IDNA. In IDNA >> it's completely impractical, owing to caches, the need for >> compatibility with existing DNS stuff, and so on. It strikes me as >> pretty impractical here, too, but I thought I'd raise it if only so we >> can put it down. (I'm also aware that it's pretty late in the game to >> suggest this. Why it only struck me today I don't know. I have a dim >> memory of having discussed this once before, but I didn't find >> anything in the archive.) > > I'm not yet at 9.5, but I definitely agree with Andrew. Let's make > sure we put a very big nail through that coffin (or whatever the > correct idiom is). > > >> The paragraph in section 3.1 starting, "Although members of the >> community discussed the possibility of defining other PRECIS string >> classes " read oddly to me. > > Same here, but for different reasons. The WG is publishing a document > with user name and password profiles at (roughly, at least?) the same > time as this one. Why are we saying "two is enough" but then doing > more? Maybe the user name/password ones aren't classes, or whatever, > but a slight rewording would go a long way here to help avoid the > impression that the WG is at odds with itself. That raises the question of whether our layering of classes and subclasses and profiles is really all that helpful. During the NEWPREP BoF, we had fairly strong agreement that we wanted to define a very limited number of classes (say, two or three) that could be re-used by application protocols. At the least, I think we need to more clearly describe the relationship between classes and profiles. I'll look at the existing text and propose better text on the list. > Something else occurred to me yesterday: Is PRECIS dealing with > context-dependent characters (ZERO WIDTH JOINER/ZERO WIDTH NON > JOINER,...)? IDNA2008 deals with them, but while a lot of other stuff > is carefully noted in the introduction and in 3.1, this is totally > missing. Either it should be added in these sections, or it should be > added in PRECIS itself. PRECIS simply re-uses the CONTEXTJ and CONTEXTO rules from IDNA. This mentioned in various sections of the precis-framework spec (just search for "contextj" within the document), but is not specifically called out early in the spec. Would that be useful? Peter From stpeter@stpeter.im Tue Oct 8 19:00:11 2013 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 C263E21F8531 for ; Tue, 8 Oct 2013 19:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.924 X-Spam-Level: X-Spam-Status: No, score=-101.924 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3l9mRwieS2lt for ; Tue, 8 Oct 2013 19:00:05 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A5FF121F9AE2 for ; Tue, 8 Oct 2013 18:59:59 -0700 (PDT) Received: from [192.168.1.3] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C33CE414CD; Tue, 8 Oct 2013 20:05:55 -0600 (MDT) Message-ID: <5254B89D.9060801@stpeter.im> Date: Tue, 08 Oct 2013 19:59:57 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= , Andrew Sullivan References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> <20131005030751.GB38902@mx1.yitter.info> <52528B3A.7020700@it.aoyama.ac.jp> <52548F5C.80302@stpeter.im> In-Reply-To: <52548F5C.80302@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: precis@ietf.org Subject: Re: [precis] WGLC: draft-ietf-precis-framework-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2013 02:00:11 -0000 On 10/08/2013 05:03 PM, Peter Saint-Andre wrote: > On 10/07/2013 04:21 AM, "Martin J. Dürst" wrote: >> On 2013/10/05 12:07, Andrew Sullivan wrote: >> >>> The paragraph in section 3.1 starting, "Although members of the >>> community discussed the possibility of defining other PRECIS string >>> classes " read oddly to me. >> >> Same here, but for different reasons. The WG is publishing a document >> with user name and password profiles at (roughly, at least?) the same >> time as this one. Why are we saying "two is enough" but then doing >> more? Maybe the user name/password ones aren't classes, or whatever, >> but a slight rewording would go a long way here to help avoid the >> impression that the WG is at odds with itself. > > That raises the question of whether our layering of classes and > subclasses and profiles is really all that helpful. During the NEWPREP > BoF, we had fairly strong agreement that we wanted to define a very > limited number of classes (say, two or three) that could be re-used by > application protocols. At the least, I think we need to more clearly > describe the relationship between classes and profiles. I'll look at > the existing text and propose better text on the list. OK, I've thought about this further. Currently we distinguish between classes, subclasses, and usages (although we often use the word "profiles" instead of "usages" because that seems to feel more natural). I think we can remove a layer here by defining classes and profiles, thus deleting subclasses. Right now, the only difference between a subclass and a usage is that a subclass can restrict the range of allowable codepoints beyond the range for a given class, whereas a usage doesn't restrict the codepoints but does define the rules for width mapping, additional mappings, case mapping, normalization, and directionality. This might be a distinction without a difference. So far we have defined the following usages (where * indicates that the usage restricts the range of codepoints): usernames passwords nicknames localparts * resourceparts I suggest that we can simplify matters by using the current naming scheme for subclasses and applying it to profile names: UsernameIdentifierClass (i.e., the Username profile of the IdentifierClass) PasswordFreeformClass NicknameFreeformClass LocalpartIdentifierClass ResourcepartFreeformClass This way, each profile has a name, which might make it easier for future protocols to re-use what we've defined so far. Peter From stpeter@stpeter.im Tue Oct 8 19:36:50 2013 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 806E021E80BB for ; Tue, 8 Oct 2013 19:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.173 X-Spam-Level: X-Spam-Status: No, score=-102.173 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crwfGA0TVSNo for ; Tue, 8 Oct 2013 19:36:44 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEC221F995A for ; Tue, 8 Oct 2013 19:36:44 -0700 (PDT) Received: from [192.168.1.3] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CD048414CD; Tue, 8 Oct 2013 20:42:28 -0600 (MDT) Message-ID: <5254C12F.90708@stpeter.im> Date: Tue, 08 Oct 2013 20:36:31 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Andrew Sullivan , precis@ietf.org References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> <20131005030751.GB38902@mx1.yitter.info> In-Reply-To: <20131005030751.GB38902@mx1.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [precis] WGLC: draft-ietf-precis-framework-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2013 02:36:50 -0000 On 10/04/2013 09:07 PM, Andrew Sullivan wrote: > Dear colleagues, > > On Wed, Aug 28, 2013 at 03:46:03PM +0900, Yoshiro YONEYA wrote: >> The WGLC will end on Wednesday, Sep 11th. > On the principle of "better late than never", I at last got to this > document. Many apologies for taking so long. > > First, let me say that this is one of the best drafts I've read in > some time. It's in very good shape, I think, and could go as it is. > Naturally, however, I cannot help suggesting some gilt to go on that > lily. The editors should feel free to ignore any or all of this. Thanks, Andrew. As an editor, one gets so close to the document that it's hard to tell what's good and what's not. > There was one largish issue that troubled me. The discussion in 9.5 > basically talks about the risks from enormous character repertoires, > and I wondered whether people won't start asking for a way to > negotiate locale or something similar as a mechanism for narrowing the > choices. Certainly, something along these lines has been requested > (not to say "vehemently demanded") over and over for IDNA. In IDNA > it's completely impractical, owing to caches, the need for > compatibility with existing DNS stuff, and so on. It strikes me as > pretty impractical here, too, but I thought I'd raise it if only so we > can put it down. (I'm also aware that it's pretty late in the game to > suggest this. Why it only struck me today I don't know. I have a dim > memory of having discussed this once before, but I didn't find > anything in the archive.) I take it you're suggesting that we add a bit explaining that PRECIS does *not* include a way to specify the locale for purposes of restricting the range of codepoints that are allowed in a given profile? > The paragraph in section 3.1 starting, "Although members of the > community discussed the possibility of defining other PRECIS string > classes " read oddly to me. As an alternative I can suggest, > "Although it might be possible to create an additional class that > falls somewhere between IdentifierClass and FreeformClass, it is not > clear how useful such a class would be. In any case, because of the > ability to subclass FreeformClass, a protocol needing something more > particular is always able to create it." I don't really care about > this; it was just something that struck me on the way by. OK, I will try to find better wording, or just reuse what you've sent. > The order of operations is laid out in section 3.2, but is really sort > of explained in section 3.4.4. It might be nice to put at least a > forward pointer in section 3.2 so that someone who knows what an NFKC > is won't start spluttering. Will do. > > In section 6.7, I want to make sure we're ok with following IDNA2008's > lead on U+19DA, which moved from PVALID to DISALLOWED in Unicode 6.0. > In the precis case, it's FREE_PVAL. I think that's fine, but I just > want to call attention. Given that we're defining PRECIS in terms of Unicode 6.2, it seems that it might be more appropriate to make it DISALLOWED. But I don't have a strong feeling about that. > > I caught one typo in section 9.5: "stings". (I think my giggling over > this might have alarmed the passenger next to me today.) > I'm happy that we were able to provide a bit of entertainment. :-) Peter From stpeter@stpeter.im Tue Oct 8 20:20:48 2013 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 34F2E11E8123 for ; Tue, 8 Oct 2013 20:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.211 X-Spam-Level: X-Spam-Status: No, score=-102.211 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Hl3pSdKk61d for ; Tue, 8 Oct 2013 20:20:43 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id F1ED511E8122 for ; Tue, 8 Oct 2013 20:20:39 -0700 (PDT) Received: from [192.168.1.3] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 178A0414CD; Tue, 8 Oct 2013 21:26:36 -0600 (MDT) Message-ID: <5254CB86.40706@stpeter.im> Date: Tue, 08 Oct 2013 21:20:38 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Florian Zeitz , precis@ietf.org References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> <522FD033.3070001@babelmonkeys.de> In-Reply-To: <522FD033.3070001@babelmonkeys.de> Content-Type: multipart/alternative; boundary="------------060404010701050007030104" Subject: Re: [precis] WGLC: draft-ietf-precis-framework-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2013 03:20:48 -0000 This is a multi-part message in MIME format. --------------060404010701050007030104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Florian, thanks for the review! Comments inline. On 09/10/2013 08:06 PM, Florian Zeitz wrote: > Am 28.08.2013 08:46, schrieb Yoshiro YONEYA: >> Dear all, >> >> This message starts two weeks Working Group Last Call (WGLC) on >> draft-ietf-precis-framework-09.txt (PRECIS Framework: Preparation and >> Comparison of Internationalized Strings in Application Protocols). >> >> Please review the document and send comments to the list (precis@ietf.org), >> the co-chairs (precis-chairs@tools.ietf.org), or the authors >> (draft-ietf-precis-framework@tools.ietf.org) by the end of WGLC. >> >> The WGLC will end on Wednesday, Sep 11th. >> > I've reviewed this draft, and generally think it takes a sensible approach. > However, I do have one major grief about it, as well as some smaller > comments. > > The major thing that bothers me about this draft is that string classes > IMHO conflate to separate concepts. On the one hand they specify valid > and disallowed codepoints. On the other hand they specify (or rather, > let the application protocol specify) mappings and normalization. > The problem I have with this is, that it makes it unclear which strings > are valid in a certain class. You are correct. Validity really applies at the level of a profile, not a class. > > E.g. consider an applications protocol that specifies FreeformClass > mixed with NFKC. This means characters, which have a compatibility > equivalent are valid in the sense that they are FREE_PVAL, but are > invalid in the normalization form. It is unclear to me, whether a string > containing characters with a compatibility equivalent would be contained > in the FreeformClass, or more precisely, this specialization thereof. > > Similar considerations are true for e.g. mixing case mapping with > IdentifierClass. Uppercase characters are PVALID/ID_PVAL, but shouldn't > be present after mapping. > > I would prefer it if we specified classes solely in terms of valid and > disallowed codepoints and directionality requirements. When you suggest that we specify a class in terms of codepoints, are you suggesting that go back to something like the stringprep model, in which a class or profile defines a lookup table? > We would then have separate text saying that an application protocol > MUST also specify which mappings and normalization to apply, what entity > needs to apply them (e.g. only the server), and when they need to be > applied (e.g. when comparing strings, before storing them, before > display to a user). Both StringPrep-bis and 6122bis already have text to > this effect. It seems sensible to me to generally require application > protocols to specify the "who", and "when" beyond the "what". E.g. it is > often sensible to display identifiers with their case as entered, but > compare them after case folding. The current text might suggest that > mappings have to be applied to user input immediately. I agree that all good application protocols that use PRECIS need to specify the enforcement rules, as we already do for SASL and XMPP. I am less sure that the PRECIS framework needs to legislate that. > > The following are smaller comments ordered by section: > > Section 3.1: > This section talks about "safety" of strings, without ever defining what > that means in this context. The term "very safe" used to describe the > IdentifierClass also strangely reminds me of statements about "absolute > security". Maybe there is a way to generally word this better? I'll think about better wording and suggest something on the list. > > The sentence "Directionality: defines application behavior in the > presence of code points that have directionality" seems a bit off to me. > It is very different from the explanation given later in Section 4.1. > From my understanding this is about the allowed combinations of > characters with directionality, and not about "application beahvior" in > their presence. It could be about both, but I have not seen a draft talk > about anything but allowed combinations (i.e. the Bidi Rule) yet. See other messages in this thread. > > Section 3.3.3 and 3.4.3: > While "unassigned codepoints are unassigned" is a nice tautology, I'm > not sure what this means in terms of their treatment. In general I feel > like more explanation is needed about unassigned codepoints and their > (possible) handling. Good point. I'll propose text. > > Section 3.3.6: > I think it would be sensible to suggest using the Unicode Default Case > Folding algorithm, if case mapping is to be applied. That seems reasonable. > > Section 5: > I feel like this lacks a normative statement about contextual rules. > E.g. "A character with the derived property value CONTEXTJ or CONTEXTO > (CONTEXTUAL RULE REQUIRED) MUST NOT be used unless an appropriate > rule has been established and the context of the character is > As mentioned, we just point to IDNA2008 here, but I think you and Martin are right that we need provide some more detals here. For example, RFC 5891 says: ### The Unicode string MUST NOT contain any characters whose validity is context-dependent, unless the validity is positively confirmed by a contextual rule. To check this, each code point identified as CONTEXTJ or CONTEXTO in the Tables document [RFC5892 ] MUST have a non-null rule. If such a code point is missing a rule, the label is invalid. If the rule exists but the result of applying the rule is negative or inconclusive, the proposed label is invalid. ### IMHO your text is more to the point. Peter --------------060404010701050007030104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Florian, thanks for the review! Comments inline.

On 09/10/2013 08:06 PM, Florian Zeitz wrote:
Am 28.08.2013 08:46, schrieb Yoshiro YONEYA:

Dear all,

This message starts two weeks Working Group Last Call (WGLC) on 
draft-ietf-precis-framework-09.txt (PRECIS Framework: Preparation and 
Comparison of Internationalized Strings in Application Protocols).

Please review the document and send comments to the list (precis@ietf.org), 
the co-chairs (precis-chairs@tools.ietf.org), or the authors 
(draft-ietf-precis-framework@tools.ietf.org) by the end of WGLC.

The WGLC will end on Wednesday, Sep 11th.


I've reviewed this draft, and generally think it takes a sensible approach.
However, I do have one major grief about it, as well as some smaller
comments.

The major thing that bothers me about this draft is that string classes
IMHO conflate to separate concepts. On the one hand they specify valid
and disallowed codepoints. On the other hand they specify (or rather,
let the application protocol specify) mappings and normalization.
The problem I have with this is, that it makes it unclear which strings
are valid in a certain class.

You are correct. Validity really applies at the level of a profile, not a class.

E.g. consider an applications protocol that specifies FreeformClass
mixed with NFKC. This means characters, which have a compatibility
equivalent are valid in the sense that they are FREE_PVAL, but are
invalid in the normalization form. It is unclear to me, whether a string
containing characters with a compatibility equivalent would be contained
in the FreeformClass, or more precisely, this specialization thereof.

Similar considerations are true for e.g. mixing case mapping with
IdentifierClass. Uppercase characters are PVALID/ID_PVAL, but shouldn't
be present after mapping.

I would prefer it if we specified classes solely in terms of valid and
disallowed codepoints and directionality requirements.
When you suggest that we specify a class in terms of codepoints, are you suggesting that go back to something like the stringprep model, in which a class or profile defines a lookup table?
We would then have separate text saying that an application protocol
MUST also specify which mappings and normalization to apply, what entity
needs to apply them (e.g. only the server), and when they need to be
applied (e.g. when comparing strings, before storing them, before
display to a user). Both StringPrep-bis and 6122bis already have text to
this effect. It seems sensible to me to generally require application
protocols to specify the "who", and "when" beyond the "what". E.g. it is
often sensible to display identifiers with their case as entered, but
compare them after case folding. The current text might suggest that
mappings have to be applied to user input immediately.
I agree that all good application protocols that use PRECIS need to specify the enforcement rules, as we already do for SASL and XMPP. I am less sure that the PRECIS framework needs to legislate that.

The following are smaller comments ordered by section:

Section 3.1:
This section talks about "safety" of strings, without ever defining what
that means in this context. The term "very safe" used to describe the
IdentifierClass also strangely reminds me of statements about "absolute
security". Maybe there is a way to generally word this better?

I'll think about better wording and suggest something on the list.

The sentence "Directionality:  defines application behavior in the
presence of code points that have directionality" seems a bit off to me.
It is very different from the explanation given later in Section 4.1.
>From my understanding this is about the allowed combinations of
characters with directionality, and not about "application beahvior" in
their presence. It could be about both, but I have not seen a draft talk
about anything but allowed combinations (i.e. the Bidi Rule) yet.

See other messages in this thread.

Section 3.3.3 and 3.4.3:
While "unassigned codepoints are unassigned" is a nice tautology, I'm
not sure what this means in terms of their treatment. In general I feel
like more explanation is needed about unassigned codepoints and their
(possible) handling.
Good point. I'll propose text.

Section 3.3.6:
I think it would be sensible to suggest using the Unicode Default Case
Folding algorithm, if case mapping is to be applied.
That seems reasonable.

Section 5:
I feel like this lacks a normative statement about contextual rules.
E.g. "A character with the derived property value CONTEXTJ or CONTEXTO
   (CONTEXTUAL RULE REQUIRED) MUST NOT be used unless an appropriate
   rule has been established and the context of the character is
As mentioned, we just point to IDNA2008 here, but I think you and Martin are right that we need provide some more detals here. For example, RFC 5891 says:

###

The Unicode string MUST NOT contain any characters whose validity is context-dependent, unless the validity is positively confirmed by a contextual rule. To check this, each code point identified as CONTEXTJ or CONTEXTO in the Tables document [RFC5892] MUST have a non-null rule. If such a code point is missing a rule, the label is invalid. If the rule exists but the result of applying the rule is negative or inconclusive, the proposed label is invalid.

###

IMHO your text is more to the point.

Peter


--------------060404010701050007030104-- From ajs@anvilwalrusden.com Tue Oct 8 21:24:13 2013 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 3DA4421E80C1 for ; Tue, 8 Oct 2013 21:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6Hz-QH1lzOB for ; Tue, 8 Oct 2013 21:24:07 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 7762911E812B for ; Tue, 8 Oct 2013 21:24:06 -0700 (PDT) Received: from mx1.yitter.info (wsip-70-186-133-98.ph.ph.cox.net [70.186.133.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 442308A031 for ; Wed, 9 Oct 2013 04:24:05 +0000 (UTC) Date: Wed, 9 Oct 2013 00:23:58 -0400 From: Andrew Sullivan To: precis@ietf.org Message-ID: <20131009042358.GB47597@mx1.yitter.info> References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> <20131005030751.GB38902@mx1.yitter.info> <5254C12F.90708@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5254C12F.90708@stpeter.im> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [precis] WGLC: draft-ietf-precis-framework-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2013 04:24:13 -0000 On Tue, Oct 08, 2013 at 08:36:31PM -0600, Peter Saint-Andre wrote: > I take it you're suggesting that we add a bit explaining that PRECIS > does *not* include a way to specify the locale for purposes of > restricting the range of codepoints that are allowed in a given > profile? Because I'm not as clever as you, it hadn't occurred to me to suggest that exactly. But that might well be another way to cope with the topic: "Yeah, we know you want this. If you really want it, you need a special-purpose internationalization framework, and not a general-purpose one." The more I think about it, the more I think that's true. The user's linguistic environment has so many tightly-bound implications for an application that if you really need to know about it, your application needs to get dirty. (Come to think of it, this is another nice way of explaining the IDN problem around this sort of request too. Thanks!) > >clear how useful such a class would be. In any case, because of the > >ability to subclass FreeformClass, a protocol needing something more > >particular is always able to create it." I don't really care about > >this; it was just something that struck me on the way by. > OK, I will try to find better wording, or just reuse what you've sent. It could be that, with your other proposal (in another thread) about getting rid of subclassing and making it all use profiles, this point will find a more natural expression. > >In section 6.7, I want to make sure we're ok with following IDNA2008's > >lead on U+19DA, which moved from PVALID to DISALLOWED in Unicode 6.0. > >In the precis case, it's FREE_PVAL. I think that's fine, but I just > >want to call attention. > Given that we're defining PRECIS in terms of Unicode 6.2, it seems > that it might be more appropriate to make it DISALLOWED. But I don't > have a strong feeling about that. Well, this was exactly my point. If we do that, we really _are_ clearly treating at least one character differently than IDNA does. In that case, we need to open the description in the text to point out the difference. Given the plain fact that U+19DA is so obscure as to be practically irrelevant, I don't want to make a big deal. But I guess being picky about the details in this case allows us to see where the seams are, and that's probably a good thing for the WG to pay attention to. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From duerst@it.aoyama.ac.jp Wed Oct 9 02:03:09 2013 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 E574721E8125 for ; Wed, 9 Oct 2013 02:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.457 X-Spam-Level: X-Spam-Status: No, score=-101.457 tagged_above=-999 required=5 tests=[AWL=-1.667, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B25egZZtoVXc for ; Wed, 9 Oct 2013 02:03:03 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 45FAC21E80BC for ; Wed, 9 Oct 2013 02:03:02 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id r9992uXO016748; Wed, 9 Oct 2013 18:02:56 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 4024_022b_9690ce24_30c1_11e3_ac73_001e6722eec2; Wed, 09 Oct 2013 18:02:56 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 9C4B3BF4CC; Wed, 9 Oct 2013 18:02:55 +0900 (JST) Message-ID: <52551BB3.4080407@it.aoyama.ac.jp> Date: Wed, 09 Oct 2013 18:02:43 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Peter Saint-Andre References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> <20130904162558.7fad8dd5d2304591166dd37a@jprs.co.jp> <52547128.5070909@stpeter.im> In-Reply-To: <52547128.5070909@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: precis@ietf.org Subject: Re: [precis] WGLC: draft-ietf-precis-framework-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2013 09:03:10 -0000 On 2013/10/09 5:55, Peter Saint-Andre wrote: > On 9/11/13 8:06 PM, Joseph Yee wrote: >> Reviewed the draft, think the approach is good. Just one minor comment. >> >> Same as Florian, had the 'hmm' reaction when reading about >> directionality and application behaviour at Section 3.1. It seems that >> the only application behaviour is permitted pattern. It doesn't deal >> with visual appearance I believed. Maybe replace 'application >> behaviour' with 'permitted patther of the string' (or 'allowed >> combination of the string')? > > Hmm, I see why you and Florian don't like that text. :-) > > How about this? > > OLD > Directionality: defines application behavior in the presence of code > points that have directionality, in particular right-to-left code > points as defined in the Unicode database (see [UAX9]). > > NEW > Directionality: defines which strings are to be considered > left-to-right (LTR) and right-to-left (RTL), and the allowable > sequences of characters in LTR and RTL strings. That may be an improvement, but it's missing the fact that LTR and RTL strings are the only two alternatives allowed. Also, it would be good to somewhere say that there is currently no widely accepted and implemented solution for the display of constructs with mixed pieces (e.g. domain names with LTR and RTL components (labels), because the problem is inherently extremely hard. Regards, Martin. From duerst@it.aoyama.ac.jp Wed Oct 9 02:12:54 2013 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 8DA4921E8133 for ; Wed, 9 Oct 2013 02:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.219 X-Spam-Level: X-Spam-Status: No, score=-101.219 tagged_above=-999 required=5 tests=[AWL=-1.429, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5PIZvS5mB5C for ; Wed, 9 Oct 2013 02:12:49 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1CE21E810A for ; Wed, 9 Oct 2013 02:12:44 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id r999Cijd023743; Wed, 9 Oct 2013 18:12:44 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 4027_a68e_f4da45a4_30c2_11e3_8fd8_001e6722eec2; Wed, 09 Oct 2013 18:12:43 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 4CF82BF4CC; Wed, 9 Oct 2013 18:12:43 +0900 (JST) Message-ID: <52551DFE.8000608@it.aoyama.ac.jp> Date: Wed, 09 Oct 2013 18:12:30 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Peter Saint-Andre References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> <20130904162558.7fad8dd5d2304591166dd37a@jprs.co.jp> <52547128.5070909@stpeter.im> <52551BB3.4080407@it.aoyama.ac.jp> In-Reply-To: <52551BB3.4080407@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: precis@ietf.org Subject: Re: [precis] WGLC: draft-ietf-precis-framework-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2013 09:12:54 -0000 On 2013/10/09 18:02, "Martin J. D=C3=BCrst" wrote: > On 2013/10/09 5:55, Peter Saint-Andre wrote: >> On 9/11/13 8:06 PM, Joseph Yee wrote: > >>> Reviewed the draft, think the approach is good. Just one minor commen= t. >>> >>> Same as Florian, had the 'hmm' reaction when reading about >>> directionality and application behaviour at Section 3.1. It seems tha= t >>> the only application behaviour is permitted pattern. It doesn't deal >>> with visual appearance I believed. Maybe replace 'application >>> behaviour' with 'permitted patther of the string' (or 'allowed >>> combination of the string')? >> >> Hmm, I see why you and Florian don't like that text. :-) >> >> How about this? >> >> OLD >> Directionality: defines application behavior in the presence of code >> points that have directionality, in particular right-to-left code >> points as defined in the Unicode database (see [UAX9]). >> >> NEW >> Directionality: defines which strings are to be considered >> left-to-right (LTR) and right-to-left (RTL), and the allowable >> sequences of characters in LTR and RTL strings. > > That may be an improvement, but it's missing the fact that LTR and RTL > strings are the only two alternatives allowed. > > Also, it would be good to somewhere say that there is currently no > widely accepted and implemented solution for the display of constructs > with mixed pieces (e.g. domain names with LTR and RTL components > (labels), because the problem is inherently extremely hard. In addition, in the introduction, there is a paragraph: 5. Leave various mapping operations (e.g., case preservation or lowercasing, Unicode normalization, mapping of certain characters to other characters or to nothing, handling of full-width and half-width characters, handling of right-to-left characters) as the responsibility of application protocols, as was done for IDNA2008 through an IDNA-specific mapping document [RFC5895]. where "handling of right-to-left characters" is described as a mapping=20 operation. That doesn't make sense to me, I think it should be moved out=20 to a separate point. Regards, Martin. > Regards, Martin. > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis > From duerst@it.aoyama.ac.jp Wed Oct 9 02:26:21 2013 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 0DE5311E8174 for ; Wed, 9 Oct 2013 02:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.04 X-Spam-Level: X-Spam-Status: No, score=-103.04 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pgq5er865Ym3 for ; Wed, 9 Oct 2013 02:26:13 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 63ACC11E8178 for ; Wed, 9 Oct 2013 02:24:49 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r999Ohp2006063; Wed, 9 Oct 2013 18:24:43 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 4024_10d1_a15df112_30c4_11e3_ac73_001e6722eec2; Wed, 09 Oct 2013 18:24:42 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 3A55BBF4CC; Wed, 9 Oct 2013 18:24:42 +0900 (JST) Message-ID: <525520CD.5070008@it.aoyama.ac.jp> Date: Wed, 09 Oct 2013 18:24:29 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Peter Saint-Andre References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> <20131005030751.GB38902@mx1.yitter.info> <52528B3A.7020700@it.aoyama.ac.jp> <52548F5C.80302@stpeter.im> <5254B89D.9060801@stpeter.im> In-Reply-To: <5254B89D.9060801@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: precis@ietf.org Subject: Re: [precis] WGLC: draft-ietf-precis-framework-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2013 09:26:21 -0000 On 2013/10/09 10:59, Peter Saint-Andre wrote: > On 10/08/2013 05:03 PM, Peter Saint-Andre wrote: >> On 10/07/2013 04:21 AM, "Martin J. D=C3=BCrst" wrote: >>> On 2013/10/05 12:07, Andrew Sullivan wrote: >>> >>>> The paragraph in section 3.1 starting, "Although members of the >>>> community discussed the possibility of defining other PRECIS string >>>> classes " read oddly to me. >>> >>> Same here, but for different reasons. The WG is publishing a document >>> with user name and password profiles at (roughly, at least?) the same >>> time as this one. Why are we saying "two is enough" but then doing >>> more? Maybe the user name/password ones aren't classes, or whatever, >>> but a slight rewording would go a long way here to help avoid the >>> impression that the WG is at odds with itself. >> >> That raises the question of whether our layering of classes and >> subclasses and profiles is really all that helpful. During the NEWPREP >> BoF, we had fairly strong agreement that we wanted to define a very >> limited number of classes (say, two or three) that could be re-used by >> application protocols. At the least, I think we need to more clearly >> describe the relationship between classes and profiles. I'll look at >> the existing text and propose better text on the list. > OK, I've thought about this further. Me to. I haven't thought about how to organize the hierarchy much, but I=20 have realized that at least it should be better documented. That starts with the Abstract! It says: A specification that reuses this framework can either directly use the PRECIS string classes or subclass the PRECIS string classes as needed. "the PRECIS string classes" implies that these have been mentioned=20 before, but that didn't happen. I suggest something like: This document defines several PRECIS string classes. Other=20 specifications can either directly use such string classes or can=20 subclass a string class defined here. (please note the change from "reuse" to "use", this document doesn't use=20 the classes, so there's no need for "re"). The abstract could then also talk about profiles (or whatever we end up=20 if the changes below are adopted). While we are at it, please shorten the abstract (one way to do this is=20 to move historical/motivational stuff to the Intro or some other place=20 like an appendix because it won't be very relevant anymore in a few=20 years' time), or at least split it up into more than one paragraph. Also, please explain the hierarchy (class-subclass-profile or whatever)=20 in a bit more detail in the introduction, with pointers to examples that=20 the WG is publishing in parallel. Regards, Martin. > Currently we distinguish between classes, subclasses, and usages > (although we often use the word "profiles" instead of "usages" because > that seems to feel more natural). I think we can remove a layer here by > defining classes and profiles, thus deleting subclasses. Right now, the > only difference between a subclass and a usage is that a subclass can > restrict the range of allowable codepoints beyond the range for a given > class, whereas a usage doesn't restrict the codepoints but does define > the rules for width mapping, additional mappings, case mapping, > normalization, and directionality. This might be a distinction without = a > difference. > > So far we have defined the following usages (where * indicates that the > usage restricts the range of codepoints): > > usernames > passwords > nicknames > localparts * > resourceparts > > I suggest that we can simplify matters by using the current naming > scheme for subclasses and applying it to profile names: > > UsernameIdentifierClass (i.e., the Username profile of the IdentifierCl= ass) > PasswordFreeformClass > NicknameFreeformClass > LocalpartIdentifierClass > ResourcepartFreeformClass > > This way, each profile has a name, which might make it easier for futur= e > protocols to re-use what we've defined so far. > > Peter > > > > From stpeter@stpeter.im Wed Oct 9 05:34:50 2013 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 C33DB21F9C3A for ; Wed, 9 Oct 2013 05:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHHqknj4-aPl for ; Wed, 9 Oct 2013 05:34:45 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BCA9821F9B7E for ; Wed, 9 Oct 2013 05:34:45 -0700 (PDT) Received: from ergon.local (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E8811414CD; Wed, 9 Oct 2013 06:40:42 -0600 (MDT) Message-ID: <52554D5A.7060300@stpeter.im> Date: Wed, 09 Oct 2013 06:34:34 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> <20130904162558.7fad8dd5d2304591166dd37a@jprs.co.jp> <52547128.5070909@stpeter.im> <52551BB3.4080407@it.aoyama.ac.jp> <52551DFE.8000608@it.aoyama.ac.jp> In-Reply-To: <52551DFE.8000608@it.aoyama.ac.jp> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: precis@ietf.org Subject: Re: [precis] WGLC: draft-ietf-precis-framework-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2013 12:34:50 -0000 On 10/9/13 3:12 AM, "Martin J. Dürst" wrote: > On 2013/10/09 18:02, "Martin J. Dürst" wrote: >> On 2013/10/09 5:55, Peter Saint-Andre wrote: >>> On 9/11/13 8:06 PM, Joseph Yee wrote: >> >>>> Reviewed the draft, think the approach is good. Just one minor comment. >>>> >>>> Same as Florian, had the 'hmm' reaction when reading about >>>> directionality and application behaviour at Section 3.1. It seems that >>>> the only application behaviour is permitted pattern. It doesn't deal >>>> with visual appearance I believed. Maybe replace 'application >>>> behaviour' with 'permitted patther of the string' (or 'allowed >>>> combination of the string')? >>> >>> Hmm, I see why you and Florian don't like that text. :-) >>> >>> How about this? >>> >>> OLD >>> Directionality: defines application behavior in the presence of code >>> points that have directionality, in particular right-to-left code >>> points as defined in the Unicode database (see [UAX9]). >>> >>> NEW >>> Directionality: defines which strings are to be considered >>> left-to-right (LTR) and right-to-left (RTL), and the allowable >>> sequences of characters in LTR and RTL strings. >> >> That may be an improvement, but it's missing the fact that LTR and RTL >> strings are the only two alternatives allowed. >> >> Also, it would be good to somewhere say that there is currently no >> widely accepted and implemented solution for the display of constructs >> with mixed pieces (e.g. domain names with LTR and RTL components >> (labels), because the problem is inherently extremely hard. > > In addition, in the introduction, there is a paragraph: > > 5. Leave various mapping operations (e.g., case preservation or > lowercasing, Unicode normalization, mapping of certain characters > to other characters or to nothing, handling of full-width and > half-width characters, handling of right-to-left characters) as > the responsibility of application protocols, as was done for > IDNA2008 through an IDNA-specific mapping document [RFC5895]. > > where "handling of right-to-left characters" is described as a mapping > operation. That doesn't make sense to me, I think it should be moved out > to a separate point. I think we can change "mapping operations" to "character-related operations". Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Oct 9 05:37:16 2013 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 B262021F9C3A for ; Wed, 9 Oct 2013 05:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auTXfGT16W8f for ; Wed, 9 Oct 2013 05:37:11 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3839F21F9C7B for ; Wed, 9 Oct 2013 05:37:11 -0700 (PDT) Received: from ergon.local (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1AD12414CD; Wed, 9 Oct 2013 06:43:09 -0600 (MDT) Message-ID: <52554DEA.40203@stpeter.im> Date: Wed, 09 Oct 2013 06:36:58 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> <20130904162558.7fad8dd5d2304591166dd37a@jprs.co.jp> <52547128.5070909@stpeter.im> <52551BB3.4080407@it.aoyama.ac.jp> In-Reply-To: <52551BB3.4080407@it.aoyama.ac.jp> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: precis@ietf.org Subject: Re: [precis] WGLC: draft-ietf-precis-framework-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2013 12:37:16 -0000 On 10/9/13 3:02 AM, "Martin J. Dürst" wrote: > On 2013/10/09 5:55, Peter Saint-Andre wrote: >> On 9/11/13 8:06 PM, Joseph Yee wrote: > >>> Reviewed the draft, think the approach is good. Just one minor comment. >>> >>> Same as Florian, had the 'hmm' reaction when reading about >>> directionality and application behaviour at Section 3.1. It seems that >>> the only application behaviour is permitted pattern. It doesn't deal >>> with visual appearance I believed. Maybe replace 'application >>> behaviour' with 'permitted patther of the string' (or 'allowed >>> combination of the string')? >> >> Hmm, I see why you and Florian don't like that text. :-) >> >> How about this? >> >> OLD >> Directionality: defines application behavior in the presence of code >> points that have directionality, in particular right-to-left code >> points as defined in the Unicode database (see [UAX9]). >> >> NEW >> Directionality: defines which strings are to be considered >> left-to-right (LTR) and right-to-left (RTL), and the allowable >> sequences of characters in LTR and RTL strings. > > That may be an improvement, but it's missing the fact that LTR and RTL > strings are the only two alternatives allowed. I think that's a good thing. We're not allowing mixed-direction strings. > Also, it would be good to somewhere say that there is currently no > widely accepted and implemented solution for the display of constructs > with mixed pieces (e.g. domain names with LTR and RTL components > (labels), because the problem is inherently extremely hard. Yes, which is why we don't allow those. Let's add a note about that. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Oct 9 05:39:45 2013 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 7733921F9D15 for ; Wed, 9 Oct 2013 05:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uaPXI5OfSWL for ; Wed, 9 Oct 2013 05:39:39 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 83DDD21F9A78 for ; Wed, 9 Oct 2013 05:39:38 -0700 (PDT) Received: from ergon.local (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E55B8414CD; Wed, 9 Oct 2013 06:45:33 -0600 (MDT) Message-ID: <52554E86.8050303@stpeter.im> Date: Wed, 09 Oct 2013 06:39:34 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> <20131005030751.GB38902@mx1.yitter.info> <52528B3A.7020700@it.aoyama.ac.jp> <52548F5C.80302@stpeter.im> <5254B89D.9060801@stpeter.im> <525520CD.5070008@it.aoyama.ac.jp> In-Reply-To: <525520CD.5070008@it.aoyama.ac.jp> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: precis@ietf.org Subject: Re: [precis] WGLC: draft-ietf-precis-framework-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2013 12:39:45 -0000 Martin, I agree with all of your points. On 10/9/13 3:24 AM, "Martin J. Dürst" wrote: > On 2013/10/09 10:59, Peter Saint-Andre wrote: >> On 10/08/2013 05:03 PM, Peter Saint-Andre wrote: >>> On 10/07/2013 04:21 AM, "Martin J. Dürst" wrote: >>>> On 2013/10/05 12:07, Andrew Sullivan wrote: >>>> >>>>> The paragraph in section 3.1 starting, "Although members of the >>>>> community discussed the possibility of defining other PRECIS string >>>>> classes " read oddly to me. >>>> >>>> Same here, but for different reasons. The WG is publishing a document >>>> with user name and password profiles at (roughly, at least?) the same >>>> time as this one. Why are we saying "two is enough" but then doing >>>> more? Maybe the user name/password ones aren't classes, or whatever, >>>> but a slight rewording would go a long way here to help avoid the >>>> impression that the WG is at odds with itself. >>> >>> That raises the question of whether our layering of classes and >>> subclasses and profiles is really all that helpful. During the NEWPREP >>> BoF, we had fairly strong agreement that we wanted to define a very >>> limited number of classes (say, two or three) that could be re-used by >>> application protocols. At the least, I think we need to more clearly >>> describe the relationship between classes and profiles. I'll look at >>> the existing text and propose better text on the list. >> OK, I've thought about this further. > > Me to. I haven't thought about how to organize the hierarchy much, but I > have realized that at least it should be better documented. > > That starts with the Abstract! It says: > A > specification that reuses this framework can either directly use the > PRECIS string classes or subclass the PRECIS string classes as > needed. > > "the PRECIS string classes" implies that these have been mentioned > before, but that didn't happen. I suggest something like: > > This document defines several PRECIS string classes. Other > specifications can either directly use such string classes or can > subclass a string class defined here. > > (please note the change from "reuse" to "use", this document doesn't use > the classes, so there's no need for "re"). > > The abstract could then also talk about profiles (or whatever we end up > if the changes below are adopted). > > While we are at it, please shorten the abstract (one way to do this is > to move historical/motivational stuff to the Intro or some other place > like an appendix because it won't be very relevant anymore in a few > years' time), or at least split it up into more than one paragraph. > > Also, please explain the hierarchy (class-subclass-profile or whatever) > in a bit more detail in the introduction, with pointers to examples that > the WG is publishing in parallel. > > Regards, Martin. > > >> Currently we distinguish between classes, subclasses, and usages >> (although we often use the word "profiles" instead of "usages" because >> that seems to feel more natural). I think we can remove a layer here by >> defining classes and profiles, thus deleting subclasses. Right now, the >> only difference between a subclass and a usage is that a subclass can >> restrict the range of allowable codepoints beyond the range for a given >> class, whereas a usage doesn't restrict the codepoints but does define >> the rules for width mapping, additional mappings, case mapping, >> normalization, and directionality. This might be a distinction without a >> difference. >> >> So far we have defined the following usages (where * indicates that the >> usage restricts the range of codepoints): >> >> usernames >> passwords >> nicknames >> localparts * >> resourceparts >> >> I suggest that we can simplify matters by using the current naming >> scheme for subclasses and applying it to profile names: >> >> UsernameIdentifierClass (i.e., the Username profile of the >> IdentifierClass) >> PasswordFreeformClass >> NicknameFreeformClass >> LocalpartIdentifierClass >> ResourcepartFreeformClass >> >> This way, each profile has a name, which might make it easier for future >> protocols to re-use what we've defined so far. >> >> Peter >> From stpeter@stpeter.im Wed Oct 9 05:45:32 2013 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 CDFCA21F9BB5 for ; Wed, 9 Oct 2013 05:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rO9+d4LSxfyo for ; Wed, 9 Oct 2013 05:45:27 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9096911E80E0 for ; Wed, 9 Oct 2013 05:45:26 -0700 (PDT) Received: from ergon.local (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AD346414CD; Wed, 9 Oct 2013 06:51:22 -0600 (MDT) Message-ID: <52554FE3.70504@stpeter.im> Date: Wed, 09 Oct 2013 06:45:23 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Andrew Sullivan References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> <20131005030751.GB38902@mx1.yitter.info> <5254C12F.90708@stpeter.im> <20131009042358.GB47597@mx1.yitter.info> In-Reply-To: <20131009042358.GB47597@mx1.yitter.info> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: precis@ietf.org Subject: Re: [precis] WGLC: draft-ietf-precis-framework-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2013 12:45:32 -0000 On 10/8/13 10:23 PM, Andrew Sullivan wrote: > On Tue, Oct 08, 2013 at 08:36:31PM -0600, Peter Saint-Andre wrote: >> I take it you're suggesting that we add a bit explaining that PRECIS >> does *not* include a way to specify the locale for purposes of >> restricting the range of codepoints that are allowed in a given >> profile? > > Because I'm not as clever as you, it hadn't occurred to me to suggest > that exactly. But that might well be another way to cope with the > topic: "Yeah, we know you want this. If you really want it, you need > a special-purpose internationalization framework, and not a > general-purpose one." The more I think about it, the more I think > that's true. The user's linguistic environment has so many > tightly-bound implications for an application that if you really need > to know about it, your application needs to get dirty. (Come to think > of it, this is another nice way of explaining the IDN problem around > this sort of request too. Thanks!) Something along those lines sounds good. >>> clear how useful such a class would be. In any case, because of the >>> ability to subclass FreeformClass, a protocol needing something more >>> particular is always able to create it." I don't really care about >>> this; it was just something that struck me on the way by. >> OK, I will try to find better wording, or just reuse what you've sent. > > It could be that, with your other proposal (in another thread) about > getting rid of subclassing and making it all use profiles, this point > will find a more natural expression. Perchance. :-) >>> In section 6.7, I want to make sure we're ok with following IDNA2008's >>> lead on U+19DA, which moved from PVALID to DISALLOWED in Unicode 6.0. >>> In the precis case, it's FREE_PVAL. I think that's fine, but I just >>> want to call attention. >> Given that we're defining PRECIS in terms of Unicode 6.2, it seems >> that it might be more appropriate to make it DISALLOWED. But I don't >> have a strong feeling about that. > > Well, this was exactly my point. If we do that, we really _are_ > clearly treating at least one character differently than IDNA does. > In that case, we need to open the description in the text to point out > the difference. Given the plain fact that U+19DA is so obscure as to > be practically irrelevant, I don't want to make a big deal. But I > guess being picky about the details in this case allows us to see > where the seams are, and that's probably a good thing for the WG to > pay attention to. It seems to me best not to special-case this character. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Oct 9 14:05:27 2013 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 5170321E81D9 for ; Wed, 9 Oct 2013 14:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-HrnRSfydhj for ; Wed, 9 Oct 2013 14:05:12 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2969521E81D3 for ; Wed, 9 Oct 2013 14:05:02 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.235]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C8AF0414CD; Wed, 9 Oct 2013 15:11:00 -0600 (MDT) Message-ID: <5255C4FC.4060705@stpeter.im> Date: Wed, 09 Oct 2013 15:05:00 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Andrew Sullivan References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> <20131005030751.GB38902@mx1.yitter.info> <5254C12F.90708@stpeter.im> <20131009042358.GB47597@mx1.yitter.info> <52554FE3.70504@stpeter.im> In-Reply-To: <52554FE3.70504@stpeter.im> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: precis@ietf.org Subject: Re: [precis] WGLC: draft-ietf-precis-framework-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2013 21:05:27 -0000 On 10/9/13 6:45 AM, Peter Saint-Andre wrote: > On 10/8/13 10:23 PM, Andrew Sullivan wrote: >> On Tue, Oct 08, 2013 at 08:36:31PM -0600, Peter Saint-Andre wrote: >>> I take it you're suggesting that we add a bit explaining that PRECIS >>> does *not* include a way to specify the locale for purposes of >>> restricting the range of codepoints that are allowed in a given >>> profile? >> >> Because I'm not as clever as you, it hadn't occurred to me to suggest >> that exactly. But that might well be another way to cope with the >> topic: "Yeah, we know you want this. If you really want it, you need >> a special-purpose internationalization framework, and not a >> general-purpose one." The more I think about it, the more I think >> that's true. The user's linguistic environment has so many >> tightly-bound implications for an application that if you really need >> to know about it, your application needs to get dirty. (Come to think >> of it, this is another nice way of explaining the IDN problem around >> this sort of request too. Thanks!) > > Something along those lines sounds good. Here is proposed text (for the end of section 9.5): The challenges inherent in supporting the full range of Unicode code points has in the past led some to hope for a way to programmatically negotiate more restrictive ranges based on locale, script, or other relevant factors. As a general-purpose internationalization technology, the PRECIS framework does not include such a negotiation mechanism. Applications requiring a tighter binding to the user's linguistic environment might need to develop extensions to the PRECIS framework, or special-purpose internationalization technologies. Peter -- Peter Saint-Andre https://stpeter.im/ From ajs@anvilwalrusden.com Wed Oct 9 14:54:42 2013 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 1B82221E81D5 for ; Wed, 9 Oct 2013 14:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74znGtRbAaHi for ; Wed, 9 Oct 2013 14:54:36 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 9D36921E81D2 for ; Wed, 9 Oct 2013 14:54:32 -0700 (PDT) Received: from mx1.yitter.info (dhcp-220-111.meetings.nanog.org [199.187.220.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 01CD08A031; Wed, 9 Oct 2013 21:54:31 +0000 (UTC) Date: Wed, 9 Oct 2013 17:54:32 -0400 From: Andrew Sullivan To: Peter Saint-Andre Message-ID: <20131009215432.GE50418@mx1.yitter.info> References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> <20131005030751.GB38902@mx1.yitter.info> <5254C12F.90708@stpeter.im> <20131009042358.GB47597@mx1.yitter.info> <52554FE3.70504@stpeter.im> <5255C4FC.4060705@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5255C4FC.4060705@stpeter.im> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: precis@ietf.org Subject: Re: [precis] WGLC: draft-ietf-precis-framework-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2013 21:54:42 -0000 On Wed, Oct 09, 2013 at 03:05:00PM -0600, Peter Saint-Andre wrote: > > Here is proposed text (for the end of section 9.5): [elided] Looks good to me. Thanks. A -- Andrew Sullivan ajs@anvilwalrusden.com From duerst@it.aoyama.ac.jp Wed Oct 9 18:20:31 2013 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 1B2A021F9C89 for ; Wed, 9 Oct 2013 18:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.123 X-Spam-Level: X-Spam-Status: No, score=-103.123 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZ8XiBkiC12I for ; Wed, 9 Oct 2013 18:20:24 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 2C99C21F9C7A for ; Wed, 9 Oct 2013 18:20:23 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r9A1KLXA027509; Thu, 10 Oct 2013 10:20:21 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 29c9_5054_21a724bc_314a_11e3_895c_001e6722eec2; Thu, 10 Oct 2013 10:20:20 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id DA20ABFBBA; Thu, 10 Oct 2013 10:20:20 +0900 (JST) Message-ID: <525600C7.1020703@it.aoyama.ac.jp> Date: Thu, 10 Oct 2013 10:20:07 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Peter Saint-Andre References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> <20130904162558.7fad8dd5d2304591166dd37a@jprs.co.jp> <52547128.5070909@stpeter.im> <52551BB3.4080407@it.aoyama.ac.jp> <52551DFE.8000608@it.aoyama.ac.jp> <52554D5A.7060300@stpeter.im> In-Reply-To: <52554D5A.7060300@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: precis@ietf.org Subject: Re: [precis] WGLC: draft-ietf-precis-framework-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 10 Oct 2013 01:20:31 -0000 On 2013/10/09 21:34, Peter Saint-Andre wrote: > On 10/9/13 3:12 AM, "Martin J. D=C3=BCrst" wrote: >> In addition, in the introduction, there is a paragraph: >> >> 5. Leave various mapping operations (e.g., case preservation or >> lowercasing, Unicode normalization, mapping of certain charact= ers >> to other characters or to nothing, handling of full-width and >> half-width characters, handling of right-to-left characters) a= s >> the responsibility of application protocols, as was done for >> IDNA2008 through an IDNA-specific mapping document [RFC5895]. >> >> where "handling of right-to-left characters" is described as a mapping >> operation. That doesn't make sense to me, I think it should be moved o= ut >> to a separate point. > > > I think we can change "mapping operations" to "character-related > operations". Well, that wouldn't be wrong, but it would be extremely generic. There's=20 nothing in the document that isn't about characters, or is there? I think something like 5. Leave various mapping operations (e.g., case preservation or lowercasing, Unicode normalization, mapping of certain characters to other characters or to nothing, handling of full-width and half-width characters) and the handling of right-to-left characters as the responsibility of application protocols, as was done for IDNA2008 through an IDNA-specific mapping document [RFC5895]. Would be at least slightly better. Regards, Martin. From stpeter@stpeter.im Wed Oct 9 18:36:35 2013 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 9765C21E824F for ; Wed, 9 Oct 2013 18:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.094 X-Spam-Level: X-Spam-Status: No, score=-102.094 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMqRc6mKNlOx for ; Wed, 9 Oct 2013 18:36:30 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C285621F9EF0 for ; Wed, 9 Oct 2013 18:36:27 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AEAFD414CD; Wed, 9 Oct 2013 19:42:26 -0600 (MDT) Message-ID: <52560499.5000508@stpeter.im> Date: Wed, 09 Oct 2013 19:36:25 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> <20130904162558.7fad8dd5d2304591166dd37a@jprs.co.jp> <52547128.5070909@stpeter.im> <52551BB3.4080407@it.aoyama.ac.jp> <52551DFE.8000608@it.aoyama.ac.jp> <52554D5A.7060300@stpeter.im> <525600C7.1020703@it.aoyama.ac.jp> In-Reply-To: <525600C7.1020703@it.aoyama.ac.jp> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: precis@ietf.org Subject: Re: [precis] WGLC: draft-ietf-precis-framework-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 10 Oct 2013 01:36:35 -0000 On 10/9/13 7:20 PM, "Martin J. Dürst" wrote: > On 2013/10/09 21:34, Peter Saint-Andre wrote: >> On 10/9/13 3:12 AM, "Martin J. Dürst" wrote: > >>> In addition, in the introduction, there is a paragraph: >>> >>> 5. Leave various mapping operations (e.g., case preservation or >>> lowercasing, Unicode normalization, mapping of certain >>> characters >>> to other characters or to nothing, handling of full-width and >>> half-width characters, handling of right-to-left characters) as >>> the responsibility of application protocols, as was done for >>> IDNA2008 through an IDNA-specific mapping document [RFC5895]. >>> >>> where "handling of right-to-left characters" is described as a mapping >>> operation. That doesn't make sense to me, I think it should be moved out >>> to a separate point. >> >> >> I think we can change "mapping operations" to "character-related >> operations". > > Well, that wouldn't be wrong, but it would be extremely generic. There's > nothing in the document that isn't about characters, or is there? > > I think something like > > 5. Leave various mapping operations (e.g., case preservation or > lowercasing, Unicode normalization, mapping of certain characters > to other characters or to nothing, handling of full-width and > half-width characters) and the handling of right-to-left characters > as the responsibility of application protocols, as was done for > IDNA2008 through an IDNA-specific mapping document [RFC5895]. > > Would be at least slightly better. Sure, that works for me. Peter -- Peter Saint-Andre https://stpeter.im/ From duerst@it.aoyama.ac.jp Wed Oct 9 18:43:42 2013 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 6931C21E8261 for ; Wed, 9 Oct 2013 18:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.19 X-Spam-Level: X-Spam-Status: No, score=-103.19 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNSTrFmKUo3s for ; Wed, 9 Oct 2013 18:43:19 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDAF21E825E for ; Wed, 9 Oct 2013 18:43:16 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r9A1h9SI013889; Thu, 10 Oct 2013 10:43:09 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 29cc_1362_50fb7cd8_314d_11e3_be8f_001e6722eec2; Thu, 10 Oct 2013 10:43:08 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id BB894BFBBA; Thu, 10 Oct 2013 10:43:08 +0900 (JST) Message-ID: <5256061F.1090108@it.aoyama.ac.jp> Date: Thu, 10 Oct 2013 10:42:55 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Peter Saint-Andre References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> <20131005030751.GB38902@mx1.yitter.info> <5254C12F.90708@stpeter.im> <20131009042358.GB47597@mx1.yitter.info> <52554FE3.70504@stpeter.im> <5255C4FC.4060705@stpeter.im> In-Reply-To: <5255C4FC.4060705@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: precis@ietf.org Subject: Re: [precis] WGLC: draft-ietf-precis-framework-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 10 Oct 2013 01:43:42 -0000 On 2013/10/10 6:05, Peter Saint-Andre wrote: > Here is proposed text (for the end of section 9.5): > > The challenges inherent in supporting the full range of Unicode code > points has in the past led some to hope for a way to programmatically > negotiate more restrictive ranges based on locale, script, or other > relevant factors. As a general-purpose internationalization > technology, the PRECIS framework does not include such a negotiation > mechanism. Mostly fine up to here, except that in this area, not only negotiation mechanisms, but also augmenting the identifiers themselves with language/locale information are regularly wished for. Using a specific example, that chat[English] and chat[French] would be two separate identifiers. We should also clearly warn against this. > Applications requiring a tighter binding to the user's > linguistic environment might need to develop extensions to the PRECIS > framework, or special-purpose internationalization technologies. I don't like this, because it essentially says "we don't do this, but you may well want to do it". It's something that makes a lot of sense e.g. in a content management system. But it does not make sense, and we shouldn't give the impression that it does, in the context of identifiers and similar stuff (even the PRECIS "FreeformClass" is about identifiers, not about content. Regards, Martin. From stpeter@stpeter.im Wed Oct 9 19:16:31 2013 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 A902021E80BA for ; Wed, 9 Oct 2013 19:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.11 X-Spam-Level: X-Spam-Status: No, score=-102.11 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOnvclOmpIJZ for ; Wed, 9 Oct 2013 19:16:26 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 98EE821E8264 for ; Wed, 9 Oct 2013 19:16:21 -0700 (PDT) Received: from [192.168.1.3] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 057B6414CD; Wed, 9 Oct 2013 20:22:19 -0600 (MDT) Message-ID: <52560DF2.2020508@stpeter.im> Date: Wed, 09 Oct 2013 20:16:18 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> <20131005030751.GB38902@mx1.yitter.info> <5254C12F.90708@stpeter.im> <20131009042358.GB47597@mx1.yitter.info> <52554FE3.70504@stpeter.im> <5255C4FC.4060705@stpeter.im> <5256061F.1090108@it.aoyama.ac.jp> In-Reply-To: <5256061F.1090108@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: precis@ietf.org Subject: Re: [precis] WGLC: draft-ietf-precis-framework-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 10 Oct 2013 02:16:31 -0000 On 10/09/2013 07:42 PM, "Martin J. Dürst" wrote: > On 2013/10/10 6:05, Peter Saint-Andre wrote: > >> Here is proposed text (for the end of section 9.5): >> >> The challenges inherent in supporting the full range of Unicode code >> points has in the past led some to hope for a way to >> programmatically >> negotiate more restrictive ranges based on locale, script, or other >> relevant factors. As a general-purpose internationalization >> technology, the PRECIS framework does not include such a negotiation >> mechanism. > > Mostly fine up to here, except that in this area, not only negotiation > mechanisms, but also augmenting the identifiers themselves with > language/locale information are regularly wished for. Using a specific > example, that chat[English] and chat[French] would be two separate > identifiers. We should also clearly warn against this. > > >> Applications requiring a tighter binding to the user's >> linguistic environment might need to develop extensions to the >> PRECIS >> framework, or special-purpose internationalization technologies. > > I don't like this, because it essentially says "we don't do this, but > you may well want to do it". It's something that makes a lot of sense > e.g. in a content management system. But it does not make sense, and > we shouldn't give the impression that it does, in the context of > identifiers and similar stuff (even the PRECIS "FreeformClass" is > about identifiers, not about content. You make several good points. How about this? The challenges inherent in supporting the full range of Unicode code points have in the past led some to hope for a way to programmatically negotiate more restrictive ranges based on locale, script, or other relevant factors, to tag the locale associated with a particular string, etc. As a general-purpose internationalization technology, the PRECIS framework does not include such mechanisms. Peter From stpeter@stpeter.im Thu Oct 10 16:36:10 2013 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 C89A011E817E for ; Thu, 10 Oct 2013 16:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.273 X-Spam-Level: X-Spam-Status: No, score=-102.273 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zlr8-30c8qKC for ; Thu, 10 Oct 2013 16:36:05 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BE3E111E8177 for ; Thu, 10 Oct 2013 16:36:05 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id EFD654100F; Thu, 10 Oct 2013 17:42:06 -0600 (MDT) Message-ID: <525739E3.8030201@stpeter.im> Date: Thu, 10 Oct 2013 17:36:03 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Andrew Sullivan References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> <20131005030751.GB38902@mx1.yitter.info> <5254C12F.90708@stpeter.im> <20131009042358.GB47597@mx1.yitter.info> In-Reply-To: <20131009042358.GB47597@mx1.yitter.info> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: precis@ietf.org Subject: Re: [precis] WGLC: draft-ietf-precis-framework-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 10 Oct 2013 23:36:10 -0000 On 10/8/13 10:23 PM, Andrew Sullivan wrote: >>> clear how useful such a class would be. In any case, because of the >>> ability to subclass FreeformClass, a protocol needing something more >>> particular is always able to create it." I don't really care about >>> this; it was just something that struck me on the way by. >> OK, I will try to find better wording, or just reuse what you've sent. > > It could be that, with your other proposal (in another thread) about > getting rid of subclassing and making it all use profiles, this point > will find a more natural expression. How's this? Future specifications might define additional PRECIS string classes (e.g., a class that falls somewhere between the IdentifierClass and the FreeformClass). At this time, it is not clear how useful such a class would be. In any case, because application developers are able to define profiles of PRECIS string classes, a protocol needing a construct between the IdentiferClass and the FreeformClass could of course define a restricted profile of the FreeformClass if needed. Peter -- Peter Saint-Andre https://stpeter.im/ From ajs@anvilwalrusden.com Thu Oct 10 16:40:58 2013 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 30AD311E818D for ; Thu, 10 Oct 2013 16:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EJw+a6bBsVM for ; Thu, 10 Oct 2013 16:40:52 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 4725411E818A for ; Thu, 10 Oct 2013 16:40:52 -0700 (PDT) Received: from mx1.yitter.info (dhcp-220-111.meetings.nanog.org [199.187.220.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id C0E0B8A031; Thu, 10 Oct 2013 23:40:50 +0000 (UTC) Date: Thu, 10 Oct 2013 19:40:53 -0400 From: Andrew Sullivan To: Peter Saint-Andre Message-ID: <20131010234053.GI52599@mx1.yitter.info> References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> <20131005030751.GB38902@mx1.yitter.info> <5254C12F.90708@stpeter.im> <20131009042358.GB47597@mx1.yitter.info> <525739E3.8030201@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <525739E3.8030201@stpeter.im> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: precis@ietf.org Subject: Re: [precis] WGLC: draft-ietf-precis-framework-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 10 Oct 2013 23:40:58 -0000 On Thu, Oct 10, 2013 at 05:36:03PM -0600, Peter Saint-Andre wrote: > How's this? [elided] WFM. A -- Andrew Sullivan ajs@anvilwalrusden.com From florob@babelmonkeys.de Fri Oct 11 18:40:08 2013 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 568F711E81B7 for ; Fri, 11 Oct 2013 18:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2oFcqfZ0qIfz for ; Fri, 11 Oct 2013 18:40:07 -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 2E98E11E8158 for ; Fri, 11 Oct 2013 18:40:04 -0700 (PDT) Received: from xdsl-87-79-139-227.netcologne.de ([87.79.139.227] helo=[192.168.0.131]) by babelmonkeys.de with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1VUoDP-00042h-UK; Sat, 12 Oct 2013 03:42:00 +0200 Message-ID: <5258A86C.7080708@babelmonkeys.de> Date: Sat, 12 Oct 2013 03:39:56 +0200 From: Florian Zeitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Peter Saint-Andre , precis@ietf.org References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> <522FD033.3070001@babelmonkeys.de> <5254CB86.40706@stpeter.im> In-Reply-To: <5254CB86.40706@stpeter.im> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [precis] WGLC: draft-ietf-precis-framework-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 12 Oct 2013 01:40:08 -0000 On 09.10.2013 05:20, Peter Saint-Andre wrote: > Hi Florian, thanks for the review! Comments inline. > > On 09/10/2013 08:06 PM, Florian Zeitz wrote: >> The major thing that bothers me about this draft is that string classes >> IMHO conflate to separate concepts. On the one hand they specify valid >> and disallowed codepoints. On the other hand they specify (or rather, >> let the application protocol specify) mappings and normalization. >> The problem I have with this is, that it makes it unclear which strings >> are valid in a certain class. > > You are correct. Validity really applies at the level of a profile, not > a class. >> >> E.g. consider an applications protocol that specifies FreeformClass >> mixed with NFKC. This means characters, which have a compatibility >> equivalent are valid in the sense that they are FREE_PVAL, but are >> invalid in the normalization form. It is unclear to me, whether a string >> containing characters with a compatibility equivalent would be contained >> in the FreeformClass, or more precisely, this specialization thereof. >> >> Similar considerations are true for e.g. mixing case mapping with >> IdentifierClass. Uppercase characters are PVALID/ID_PVAL, but shouldn't >> be present after mapping. >> >> I would prefer it if we specified classes solely in terms of valid and >> disallowed codepoints and directionality requirements. > When you suggest that we specify a class in terms of codepoints, are you > suggesting that go back to something like the stringprep model, in which > a class or profile defines a lookup table? Well, yes and no. We certainly want the rule/category based algorithm in order to have Unicode version agility, and I'm not suggesting we get rid of it. I'm also not suggesting we drop the rules about having some codepoints only valid in a certain context. I do however think it may be more sensible to say a string is within a PRECIS class iff all its characters are PVALID, CONTEXTO, or CONTEXTJ for this class, and a contextual rule is fulfilled, if required. This may even already be the intent, but as I said a profile can easily be defined such, that a string matches this criteria, but can never be produced after the specified normalization and all mappings were applied. At any rate I think we need clearer text about the intention here, answering the question: "When is a string allowed by a profile?". I personally can not really tell from the draft right now. >> We would then have separate text saying that an application protocol >> MUST also specify which mappings and normalization to apply, what entity >> needs to apply them (e.g. only the server), and when they need to be >> applied (e.g. when comparing strings, before storing them, before >> display to a user). Both StringPrep-bis and 6122bis already have text to >> this effect. It seems sensible to me to generally require application >> protocols to specify the "who", and "when" beyond the "what". E.g. it is >> often sensible to display identifiers with their case as entered, but >> compare them after case folding. The current text might suggest that >> mappings have to be applied to user input immediately. > I agree that all good application protocols that use PRECIS need to > specify the enforcement rules, as we already do for SASL and XMPP. I am > less sure that the PRECIS framework needs to legislate that. I think not legislating this only gives people a great way to shoot themselves in the foot. I could be convinced otherwise though. >> [...] I think we have agreement (or separate threads) about all other points. Florian From stpeter@stpeter.im Fri Oct 11 19:33:36 2013 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 85D9F11E81E2 for ; Fri, 11 Oct 2013 19:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.295 X-Spam-Level: X-Spam-Status: No, score=-102.295 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SBV1qO-3eJQ for ; Fri, 11 Oct 2013 19:33:30 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 898E711E8158 for ; Fri, 11 Oct 2013 19:33:30 -0700 (PDT) Received: from [192.168.1.3] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2B11D40FA9; Fri, 11 Oct 2013 20:39:36 -0600 (MDT) Message-ID: <5258B4F8.4030601@stpeter.im> Date: Fri, 11 Oct 2013 20:33:28 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Florian Zeitz , precis@ietf.org References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> <522FD033.3070001@babelmonkeys.de> <5254CB86.40706@stpeter.im> <5258A86C.7080708@babelmonkeys.de> In-Reply-To: <5258A86C.7080708@babelmonkeys.de> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [precis] WGLC: draft-ietf-precis-framework-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 12 Oct 2013 02:33:36 -0000 Heh, I was just now addressing your feedback in my working copy of the spec. -) On 10/11/2013 07:39 PM, Florian Zeitz wrote: > On 09.10.2013 05:20, Peter Saint-Andre wrote: >> Hi Florian, thanks for the review! Comments inline. >> >> On 09/10/2013 08:06 PM, Florian Zeitz wrote: >>> The major thing that bothers me about this draft is that string classes >>> IMHO conflate to separate concepts. On the one hand they specify valid >>> and disallowed codepoints. On the other hand they specify (or rather, >>> let the application protocol specify) mappings and normalization. >>> The problem I have with this is, that it makes it unclear which strings >>> are valid in a certain class. >> >> You are correct. Validity really applies at the level of a profile, not >> a class. >>> >>> E.g. consider an applications protocol that specifies FreeformClass >>> mixed with NFKC. This means characters, which have a compatibility >>> equivalent are valid in the sense that they are FREE_PVAL, but are >>> invalid in the normalization form. It is unclear to me, whether a string >>> containing characters with a compatibility equivalent would be contained >>> in the FreeformClass, or more precisely, this specialization thereof. >>> >>> Similar considerations are true for e.g. mixing case mapping with >>> IdentifierClass. Uppercase characters are PVALID/ID_PVAL, but shouldn't >>> be present after mapping. >>> >>> I would prefer it if we specified classes solely in terms of valid and >>> disallowed codepoints and directionality requirements. >> When you suggest that we specify a class in terms of codepoints, are you >> suggesting that go back to something like the stringprep model, in which >> a class or profile defines a lookup table? > Well, yes and no. We certainly want the rule/category based algorithm in > order to have Unicode version agility, and I'm not suggesting we get rid > of it. I'm also not suggesting we drop the rules about having some > codepoints only valid in a certain context. > I do however think it may be more sensible to say a string is within a > PRECIS class iff all its characters are PVALID, CONTEXTO, or CONTEXTJ > for this class, and a contextual rule is fulfilled, if required. The way I see it, it doesn't make much sense to talk about a string matching a class. In practice within an application protocol, a string will be checked against the full set of rules as defined by a profile. A string class provides a kind of "substrate", if you will, but it doesn't define things in enough detail to perform string matching. > This may even already be the intent, but as I said a profile can easily > be defined such, that a string matches this criteria, but can never be > produced after the specified normalization and all mappings were applied. > At any rate I think we need clearer text about the intention here, > answering the question: "When is a string allowed by a profile?". I > personally can not really tell from the draft right now. In part, I don't think it is the responsibility of this specification to answer that question, other than to make it clear that you need to check a string against the full set of rules defined by a profile. I do think it would be helpful to provide some examples, although I think they probably belong in the various specs that define the profiles (so far that would be nickname, saslprepbis, and 6122bis). >>> We would then have separate text saying that an application protocol >>> MUST also specify which mappings and normalization to apply, what entity >>> needs to apply them (e.g. only the server), and when they need to be >>> applied (e.g. when comparing strings, before storing them, before >>> display to a user). Both StringPrep-bis and 6122bis already have text to >>> this effect. It seems sensible to me to generally require application >>> protocols to specify the "who", and "when" beyond the "what". E.g. it is >>> often sensible to display identifiers with their case as entered, but >>> compare them after case folding. The current text might suggest that >>> mappings have to be applied to user input immediately. >> I agree that all good application protocols that use PRECIS need to >> specify the enforcement rules, as we already do for SASL and XMPP. I am >> less sure that the PRECIS framework needs to legislate that. > I think not legislating this only gives people a great way to shoot > themselves in the foot. I could be convinced otherwise though. Yes, we are trying to prevent such "foot guns". I don't think we can get very specific (e.g., some technologies that use PRECIS might not have a client-server architecture). I'll see about proposing some text here... >>> [...] > I think we have agreement (or separate threads) about all other points. Great, thanks. Peter From florob@babelmonkeys.de Sat Oct 12 04:26:07 2013 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 1726B21E8163 for ; Sat, 12 Oct 2013 04:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xG+t0swLEFWi for ; Sat, 12 Oct 2013 04:26:01 -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 CE26021F9AE2 for ; Sat, 12 Oct 2013 04:25:59 -0700 (PDT) Received: from xdsl-87-79-85-187.netcologne.de ([87.79.85.187] helo=[192.168.0.131]) by babelmonkeys.de with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1VUxMS-0004JX-3t; Sat, 12 Oct 2013 13:27:56 +0200 Message-ID: <525931C0.6090600@babelmonkeys.de> Date: Sat, 12 Oct 2013 13:25:52 +0200 From: Florian Zeitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Peter Saint-Andre , precis@ietf.org References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> <522FD033.3070001@babelmonkeys.de> <5254CB86.40706@stpeter.im> <5258A86C.7080708@babelmonkeys.de> <5258B4F8.4030601@stpeter.im> In-Reply-To: <5258B4F8.4030601@stpeter.im> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [precis] WGLC: draft-ietf-precis-framework-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 12 Oct 2013 11:26:07 -0000 On 12.10.2013 04:33, Peter Saint-Andre wrote: > Heh, I was just now addressing your feedback in my working copy of the > spec. -) > > On 10/11/2013 07:39 PM, Florian Zeitz wrote: >> On 09.10.2013 05:20, Peter Saint-Andre wrote: >>> Hi Florian, thanks for the review! Comments inline. >>> >>> On 09/10/2013 08:06 PM, Florian Zeitz wrote: >>>> The major thing that bothers me about this draft is that string classes >>>> IMHO conflate to separate concepts. On the one hand they specify valid >>>> and disallowed codepoints. On the other hand they specify (or rather, >>>> let the application protocol specify) mappings and normalization. >>>> The problem I have with this is, that it makes it unclear which strings >>>> are valid in a certain class. >>> >>> You are correct. Validity really applies at the level of a profile, not >>> a class. >>>> >>>> E.g. consider an applications protocol that specifies FreeformClass >>>> mixed with NFKC. This means characters, which have a compatibility >>>> equivalent are valid in the sense that they are FREE_PVAL, but are >>>> invalid in the normalization form. It is unclear to me, whether a string >>>> containing characters with a compatibility equivalent would be contained >>>> in the FreeformClass, or more precisely, this specialization thereof. >>>> >>>> Similar considerations are true for e.g. mixing case mapping with >>>> IdentifierClass. Uppercase characters are PVALID/ID_PVAL, but shouldn't >>>> be present after mapping. >>>> >>>> I would prefer it if we specified classes solely in terms of valid and >>>> disallowed codepoints and directionality requirements. >>> When you suggest that we specify a class in terms of codepoints, are you >>> suggesting that go back to something like the stringprep model, in which >>> a class or profile defines a lookup table? >> Well, yes and no. We certainly want the rule/category based algorithm in >> order to have Unicode version agility, and I'm not suggesting we get rid >> of it. I'm also not suggesting we drop the rules about having some >> codepoints only valid in a certain context. >> I do however think it may be more sensible to say a string is within a >> PRECIS class iff all its characters are PVALID, CONTEXTO, or CONTEXTJ >> for this class, and a contextual rule is fulfilled, if required. > > The way I see it, it doesn't make much sense to talk about a string > matching a class. In practice within an application protocol, a string > will be checked against the full set of rules as defined by a profile. A > string class provides a kind of "substrate", if you will, but it doesn't > define things in enough detail to perform string matching. > What I'm trying to avoid here is a certain ambiguity I think we have now. To give an example: Text we have in 6122bis now says «MUST consist only of Unicode code points that conform to the "FreeformClass" base string class». For arguments sake lets pretend it also specified NFKC. Does "U+1D7D0 MATHEMATICAL BOLD DIGIT TWO" conform to "FreeformClass" in this case? It's either "Yes, that is clearly FREE_PVAL", or "No, that must be normalized to U+0032 DIGIT TWO", depending on your reading. >> This may even already be the intent, but as I said a profile can easily >> be defined such, that a string matches this criteria, but can never be >> produced after the specified normalization and all mappings were applied. >> At any rate I think we need clearer text about the intention here, >> answering the question: "When is a string allowed by a profile?". I >> personally can not really tell from the draft right now. > > In part, I don't think it is the responsibility of this specification to > answer that question, other than to make it clear that you need to check > a string against the full set of rules defined by a profile. I do think > it would be helpful to provide some examples, although I think they > probably belong in the various specs that define the profiles (so far > that would be nickname, saslprepbis, and 6122bis). > I think I agree. And I think that is why I suggested leaving normalizations and mappings out of the classes. We want to tell people that they have to normalize, and we want them to think about mappings. But the exact order of those operations, who needs to perform them, what is valid in protocol slots, etc. is their business. And what that means in particular (to me) is that a profile would tell you after which of the steps a string needs to be PVALID under a certain class. E.g. for SASLPrepbis you would (as I understand it) split up the simple username into its parts, perform normalization and all mappings except case mapping, and then check whether the userparts are PVALID/ID_PVAL. Case mappings would then be performed whenever the SASL mechanism tells you to. If everyone is required to specify such rules (usually less complex ones I'd hope) I don't see the benefit of formally including normalization and mappings in the definition of a class (in particular if that definition pretty much is "that's up to you"). This would also allow making this text generic, and not repeating it for IdentifierClass and FreeformClass. >>>> We would then have separate text saying that an application protocol >>>> MUST also specify which mappings and normalization to apply, what entity >>>> needs to apply them (e.g. only the server), and when they need to be >>>> applied (e.g. when comparing strings, before storing them, before >>>> display to a user). Both StringPrep-bis and 6122bis already have text to >>>> this effect. It seems sensible to me to generally require application >>>> protocols to specify the "who", and "when" beyond the "what". E.g. it is >>>> often sensible to display identifiers with their case as entered, but >>>> compare them after case folding. The current text might suggest that >>>> mappings have to be applied to user input immediately. >>> I agree that all good application protocols that use PRECIS need to >>> specify the enforcement rules, as we already do for SASL and XMPP. I am >>> less sure that the PRECIS framework needs to legislate that. >> I think not legislating this only gives people a great way to shoot >> themselves in the foot. I could be convinced otherwise though. > > Yes, we are trying to prevent such "foot guns". I don't think we can get > very specific (e.g., some technologies that use PRECIS might not have a > client-server architecture). I'll see about proposing some text here... > I don't think we have to be too specific here. Basically we want to get people thinking. They must answer the questions "Which entity has to perform which steps?" and "At what point in the protocol flow is this required?" I don't think that restricts the text to client-server architectures as such. Florian From stpeter@stpeter.im Mon Oct 14 08:36:58 2013 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 A4AF211E81E2 for ; Mon, 14 Oct 2013 08:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8n7LeblBcCX for ; Mon, 14 Oct 2013 08:36:45 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B7E8611E81A1 for ; Mon, 14 Oct 2013 08:36:28 -0700 (PDT) Received: from ergon.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id EA50240FA9; Mon, 14 Oct 2013 09:42:33 -0600 (MDT) Message-ID: <525C0F72.1050002@stpeter.im> Date: Mon, 14 Oct 2013 09:36:18 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Florian Zeitz References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> <522FD033.3070001@babelmonkeys.de> <5254CB86.40706@stpeter.im> <5258A86C.7080708@babelmonkeys.de> <5258B4F8.4030601@stpeter.im> <525931C0.6090600@babelmonkeys.de> In-Reply-To: <525931C0.6090600@babelmonkeys.de> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: precis@ietf.org Subject: Re: [precis] WGLC: draft-ietf-precis-framework-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 14 Oct 2013 15:36:58 -0000 On 10/12/13 5:25 AM, Florian Zeitz wrote: > On 12.10.2013 04:33, Peter Saint-Andre wrote: >> >> On 10/11/2013 07:39 PM, Florian Zeitz wrote: >>> On 09.10.2013 05:20, Peter Saint-Andre wrote: >>>> Hi Florian, thanks for the review! Comments inline. >>>> >>>> On 09/10/2013 08:06 PM, Florian Zeitz wrote: >>>>> The major thing that bothers me about this draft is that string classes >>>>> IMHO conflate to separate concepts. On the one hand they specify valid >>>>> and disallowed codepoints. On the other hand they specify (or rather, >>>>> let the application protocol specify) mappings and normalization. >>>>> The problem I have with this is, that it makes it unclear which strings >>>>> are valid in a certain class. >>>> >>>> You are correct. Validity really applies at the level of a profile, not >>>> a class. >>>>> >>>>> E.g. consider an applications protocol that specifies FreeformClass >>>>> mixed with NFKC. This means characters, which have a compatibility >>>>> equivalent are valid in the sense that they are FREE_PVAL, but are >>>>> invalid in the normalization form. It is unclear to me, whether a string >>>>> containing characters with a compatibility equivalent would be contained >>>>> in the FreeformClass, or more precisely, this specialization thereof. >>>>> >>>>> Similar considerations are true for e.g. mixing case mapping with >>>>> IdentifierClass. Uppercase characters are PVALID/ID_PVAL, but shouldn't >>>>> be present after mapping. >>>>> >>>>> I would prefer it if we specified classes solely in terms of valid and >>>>> disallowed codepoints and directionality requirements. >>>> When you suggest that we specify a class in terms of codepoints, are you >>>> suggesting that go back to something like the stringprep model, in which >>>> a class or profile defines a lookup table? >>> Well, yes and no. We certainly want the rule/category based algorithm in >>> order to have Unicode version agility, and I'm not suggesting we get rid >>> of it. I'm also not suggesting we drop the rules about having some >>> codepoints only valid in a certain context. >>> I do however think it may be more sensible to say a string is within a >>> PRECIS class iff all its characters are PVALID, CONTEXTO, or CONTEXTJ >>> for this class, and a contextual rule is fulfilled, if required. >> >> The way I see it, it doesn't make much sense to talk about a string >> matching a class. In practice within an application protocol, a string >> will be checked against the full set of rules as defined by a profile. A >> string class provides a kind of "substrate", if you will, but it doesn't >> define things in enough detail to perform string matching. >> > What I'm trying to avoid here is a certain ambiguity I think we have > now. To give an example: Text we have in 6122bis now says «MUST consist > only of Unicode code points that conform to the "FreeformClass" base > string class». Ah, I see your point. I think we'll need to adjust the text in all of the documents that use the framework. So for instance, currently we say: A resourcepart MUST consist only of Unicode code points that conform to the "FreeformClass" base string class defined in [I-D.ietf-precis-framework]. (Note that there is no XMPP-specific subclass for resourceparts.) The normalization and mapping rules for the resourcepart of a JID are as follows, where the operations specified MUST be completed in the order shown: 1. Fullwidth and halfwidth characters MAY be mapped to their decomposition equivalents. [etc.] I think we'll need to change that to say something like this: A resourcepart MUST consist only of Unicode code points that conform to the "JIDresourceFreeformClass" profile, which is defined as follows: 1. The base string class is the "FreeformClass" class specified in [I-D.ietf-precis-framework] 2. Fullwidth and halfwidth characters MAY be mapped to their decomposition equivalents. That is, the base string class can immediately limit the characters that you even consider. For the "JIDlocalIdentifierClass" profile (or whatever we call it), if a character is disallowed by the IdentifierClass then you don't need to consider it further, but if it's allowed then you need to complete further processing (such as the relevant mapping operations). > For arguments sake lets pretend it also specified NFKC. > Does "U+1D7D0 MATHEMATICAL BOLD DIGIT TWO" conform to "FreeformClass" in > this case? > > It's either "Yes, that is clearly FREE_PVAL", or "No, that must be > normalized to U+0032 DIGIT TWO", depending on your reading. Here again I think conformance applies only at the level of the profile. The base string classes just limit the universe of characters you need to consider. >>> This may even already be the intent, but as I said a profile can easily >>> be defined such, that a string matches this criteria, but can never be >>> produced after the specified normalization and all mappings were applied. >>> At any rate I think we need clearer text about the intention here, >>> answering the question: "When is a string allowed by a profile?". I >>> personally can not really tell from the draft right now. >> >> In part, I don't think it is the responsibility of this specification to >> answer that question, other than to make it clear that you need to check >> a string against the full set of rules defined by a profile. I do think >> it would be helpful to provide some examples, although I think they >> probably belong in the various specs that define the profiles (so far >> that would be nickname, saslprepbis, and 6122bis). >> > I think I agree. And I think that is why I suggested leaving > normalizations and mappings out of the classes. We want to tell people > that they have to normalize, and we want them to think about mappings. > But the exact order of those operations, who needs to perform them, what > is valid in protocol slots, etc. is their business. > > And what that means in particular (to me) is that a profile would tell > you after which of the steps a string needs to be PVALID under a certain > class. s/class/profile/ (IMHO) > E.g. for SASLPrepbis you would (as I understand it) split up the > simple username into its parts, perform normalization and all mappings > except case mapping, and then check whether the userparts are > PVALID/ID_PVAL. Case mappings would then be performed whenever the SASL > mechanism tells you to. > > If everyone is required to specify such rules (usually less complex ones > I'd hope) I don't see the benefit of formally including normalization > and mappings in the definition of a class (in particular if that > definition pretty much is "that's up to you"). > This would also allow making this text generic, and not repeating it for > IdentifierClass and FreeformClass. I'm sorry, I've lost track of exactly what "this text" refers to here. >>>>> We would then have separate text saying that an application protocol >>>>> MUST also specify which mappings and normalization to apply, what entity >>>>> needs to apply them (e.g. only the server), and when they need to be >>>>> applied (e.g. when comparing strings, before storing them, before >>>>> display to a user). Both StringPrep-bis and 6122bis already have text to >>>>> this effect. It seems sensible to me to generally require application >>>>> protocols to specify the "who", and "when" beyond the "what". E.g. it is >>>>> often sensible to display identifiers with their case as entered, but >>>>> compare them after case folding. The current text might suggest that >>>>> mappings have to be applied to user input immediately. >>>> I agree that all good application protocols that use PRECIS need to >>>> specify the enforcement rules, as we already do for SASL and XMPP. I am >>>> less sure that the PRECIS framework needs to legislate that. >>> I think not legislating this only gives people a great way to shoot >>> themselves in the foot. I could be convinced otherwise though. >> >> Yes, we are trying to prevent such "foot guns". I don't think we can get >> very specific (e.g., some technologies that use PRECIS might not have a >> client-server architecture). I'll see about proposing some text here... >> > I don't think we have to be too specific here. Basically we want to get > people thinking. They must answer the questions "Which entity has to > perform which steps?" and "At what point in the protocol flow is this > required?" I don't think that restricts the text to client-server > architectures as such. True. Let me see if I can find a good place for that text, because I agree with you that we really do want to get people thinking about those topics. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Mon Oct 14 11:10:42 2013 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 0FC5B11E818E; Mon, 14 Oct 2013 11:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.188 X-Spam-Level: X-Spam-Status: No, score=-102.188 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82kl6aGnjlY2; Mon, 14 Oct 2013 11:10:37 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id F3B8C21F9A19; Mon, 14 Oct 2013 11:10:36 -0700 (PDT) Received: from sjc-vpn2-1003.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AD13340FA9; Mon, 14 Oct 2013 12:16:50 -0600 (MDT) Message-ID: <525C339A.20407@stpeter.im> Date: Mon, 14 Oct 2013 12:10:34 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Alexey Melnikov References: <51FEEC99.1020901@stpeter.im> <52090F96.30700@stpeter.im> <522E5CAA.5010902@stpeter.im> <5230B3B3.3040805@babelmonkeys.de> <87zjr2pmhs.fsf@latte.josefsson.org> <87txharmne.fsf@latte.josefsson.org> <20130924231746.73c578b7@latte.josefsson.org> <524EB8B4.2000509@isode.com> In-Reply-To: <524EB8B4.2000509@isode.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" , Sam Hartman , "precis@ietf.org" Subject: Re: [precis] [kitten] Fwd: Re: I-D Action: draft-ietf-precis-saslprepbis-04.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 14 Oct 2013 18:10:42 -0000 On 10/4/13 6:46 AM, Alexey Melnikov wrote: > On 24/09/2013 22:17, Simon Josefsson wrote: >> You wrote: >>>>>>>> "Simon" == Simon Josefsson writes: >>> Simon> like HTTP, FTP, SMTP, SSH, etc could be revised. I don't >>> Simon> believe any of that will happen, so we'll have to live with >>> Simon> case sensitive usernames, and my take is that I18N >>> Simon> documents should permit that. >>> >>> I'm not sure any of the above hase case sensitive usernames. >>> They permit usernames to be case sensitive. >>> However a lot of implementations treat the username as case >>> insensitive. >>> >>> I do think this is an appropriate issue for an IETF an document, but I >>> do think considering the impact on legacy systems is important. >>> I don't think we need to require there be no impact, simply understand >>> an accept it. >> Agreed, but the devil is in the detail. For example, I would say that >> any I18N effort that changes how ASCII usernames ([A-Za-z0-9...]) >> behave have gone too far down the road that causes damage to legacy >> systems. > Case folding for usernames in draft-ietf-precis-saslprepbis-04.txt is a > SHOULD, so I think you are Ok. I.e. compatibility with a legacy system > is a good enough reason to violate the SHOULD. Correct. Here is proposed text for Section 4 on usernames. I've provided proposed text for the entire section so that folks on both the PRECIS and KITTEN lists have the complete context. Please review this proposed text and provide comments. ### 4. Usernames 4.1. Definition This document specifies that a username is a string of Unicode code points [UNICODE], encoded using UTF-8 [RFC3629], and structured either as an ordered sequence of "userparts" (where the complete username can consist of a single userpart or a space-separated sequence of userparts) or as a userpart@domainpart (where the domainpart is an IP literal, an IPv4 address, or a fully-qualified domain name). The syntax for a username is defined as follows using the Augmented Backus-Naur Form (ABNF) [RFC5234]. username = userpart [1*(1*SP userpart)] / userpart '@' domainpart userpart = 1*(idpoint) ; ; an "idpoint" is a UTF-8 encoded Unicode code point ; that conforms to the PRECIS "IdentifierClass" ; domainpart = IP-literal / IPv4address / ifqdn ; ; the "IPv4address" and "IP-literal" rules are ; defined in RFC 3986, and the first-match-wins ; (a.k.a. "greedy") algorithm described in RFC 3986 ; applies ; ; reuse of the IP-literal rule from RFC 3986 implies ; that IPv6 addresses are enclosed in square brackets ; (i.e., beginning with '[' and ending with ']') ; ifqdn = 1*1023(domainpoint) ; ; a "domainpoint" is a UTF-8 encoded Unicode code ; point that conforms to RFC 5890 ; All code points and blocks not explicitly allowed in the PRECIS IdentifierClass are disallowed; this includes private use characters, surrogate code points, and the other code points and blocks that were defined as "Prohibited Output" in [RFC4013]. In addition, common constructions such as "user@example.com" are allowed as usernames under this specification, as they were under [RFC4013]. 4.2. Preparation Each userpart of a username MUST conform to the "UsernameIdentifierClass" profile of the PRECIS IdentifierClass, which is defined as follows: 1. The base string class is the "IdentifierClass" specified in [I-D.ietf-precis-framework]. 2. Fullwidth and halfwidth characters MUST be mapped to their decomposition equivalents. 3. So-called additional mappings MAY be applied, such as those defined in [I-D.ietf-precis-mappings]. 4. Uppercase and titlecase characters might be mapped to their lowercase equivalents (see Section 4.2.1 below). 5. Unicode Normalization Form C (NFC) MUST be applied to all characters. With regard to directionality, the "Bidi Rule" provided in [RFC5893] applies. A username MUST NOT be zero bytes in length. This rule is to be enforced after any normalization and mapping of code points. In protocols that provide usernames as input to a cryptographic algorithm such as a hash function, the client will need to perform proper preparation of the username before applying the algorithm. 4.2.1. Case Mapping Case mapping is a matter for the application protocol, protocol implementation, or end deployment. In general, this document suggests that it is preferable to perform case mapping, since not doing so can lead to false positives during authentication and authorization (as described in [RFC6943]) and can result in confusion among end users given the prevalence of case mapping in many existing protocols and applications. However, there can be good reasons to not perform case mapping, such as backward compatibility with deployed infrastructure. In particular: o SASL mechanisms that directly re-use this profile MUST specify whether and when case mapping is to be applied to authentication identifiers. SASL mechanisms SHOULD delay any case mapping to the last possible moment, such as when doing a lookup by username, username comparisons, or generating a cryptographic salt from a username. In keeping with RFC4422, SASL mechanisms are not to apply this or any other profile to authorization identifiers. o Application protocols that use SASL (such as IMAP [RFC3501] and XMPP [RFC6120]) and that directly re-use this profile MUST specify whether case mapping is to be applied to authorization identifiers. Such "SASL application protocols" SHOULD delay any case mapping of authorization identifiers to the last possible moment, which happens to necessarily be on the server side. In keeping with RFC4422, SASL application protocols are not to apply this or any other profile to authentication identifiers. o Application protocols that do not use SASL (such as HTTP authentication with the Basic and Digest schemes [RFC2617]) MUST specify whether and when case mapping is to be applied to authentication identifiers and authorization identifiers. Such "non-SASL application protocols" SHOULD delay any case mapping to the last possible moment, such as when doing a lookup by username, username comparisons, or generating a cryptographic salt from a username. If the specification for a SASL mechanism, SASL application protocol, or non-SASL application protocol specifies the handling of case mapping for strings that conform to the UsernameIdentifierClass, it MUST clearly describe whether case mapping is required, recommended, or optional at the level of the protocol itself, implementations thereof, or service deployments. ### Peter -- Peter Saint-Andre https://stpeter.im/ From florob@babelmonkeys.de Tue Oct 15 03:16:51 2013 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 9533911E8175 for ; Tue, 15 Oct 2013 03:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dy9Jv15JOU8A for ; Tue, 15 Oct 2013 03:16:50 -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 3290211E817D for ; Tue, 15 Oct 2013 03:16:45 -0700 (PDT) Received: from [134.130.62.162] by babelmonkeys.de with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1VW1i7-0006tx-1l; Tue, 15 Oct 2013 12:18:44 +0200 Message-ID: <525D1608.3050309@babelmonkeys.de> Date: Tue, 15 Oct 2013 12:16:40 +0200 From: Florian Zeitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> <522FD033.3070001@babelmonkeys.de> <5254CB86.40706@stpeter.im> <5258A86C.7080708@babelmonkeys.de> <5258B4F8.4030601@stpeter.im> <525931C0.6090600@babelmonkeys.de> <525C0F72.1050002@stpeter.im> In-Reply-To: <525C0F72.1050002@stpeter.im> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: precis@ietf.org Subject: Re: [precis] WGLC: draft-ietf-precis-framework-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2013 10:16:51 -0000 Am 14.10.2013 17:36, schrieb Peter Saint-Andre: > On 10/12/13 5:25 AM, Florian Zeitz wrote: >> On 12.10.2013 04:33, Peter Saint-Andre wrote: >>> On 10/11/2013 07:39 PM, Florian Zeitz wrote: >>>> On 09.10.2013 05:20, Peter Saint-Andre wrote: >> What I'm trying to avoid here is a certain ambiguity I think we have >> now. To give an example: Text we have in 6122bis now says «MUST consist >> only of Unicode code points that conform to the "FreeformClass" base >> string class». > > Ah, I see your point. I think we'll need to adjust the text in all of > the documents that use the framework. > > So for instance, currently we say: > > A resourcepart MUST consist only of Unicode code points that conform > to the "FreeformClass" base string class defined in > [I-D.ietf-precis-framework]. (Note that there is no XMPP-specific > subclass for resourceparts.) > > The normalization and mapping rules for the resourcepart of a JID are > as follows, where the operations specified MUST be completed in the > order shown: > > 1. Fullwidth and halfwidth characters MAY be mapped to their > decomposition equivalents. > > [etc.] > > I think we'll need to change that to say something like this: > > A resourcepart MUST consist only of Unicode code points that conform > to the "JIDresourceFreeformClass" profile, which is defined as > follows: > > 1. The base string class is the "FreeformClass" class specified in > [I-D.ietf-precis-framework] > > 2. Fullwidth and halfwidth characters MAY be mapped to their > decomposition equivalents. > > That is, the base string class can immediately limit the characters that > you even consider. For the "JIDlocalIdentifierClass" profile (or > whatever we call it), if a character is disallowed by the > IdentifierClass then you don't need to consider it further, but if it's > allowed then you need to complete further processing (such as the > relevant mapping operations). > I'm not sure that is the right approach, see below. It also occurs to me that the framework draft currently calls this "Usage" instead of "Profile", or is that yet another concept? >> For arguments sake lets pretend it also specified NFKC. >> Does "U+1D7D0 MATHEMATICAL BOLD DIGIT TWO" conform to "FreeformClass" in >> this case? >> >> It's either "Yes, that is clearly FREE_PVAL", or "No, that must be >> normalized to U+0032 DIGIT TWO", depending on your reading. > > Here again I think conformance applies only at the level of the profile. > The base string classes just limit the universe of characters you need > to consider. > >>>> This may even already be the intent, but as I said a profile can easily >>>> be defined such, that a string matches this criteria, but can never be >>>> produced after the specified normalization and all mappings were applied. >>>> At any rate I think we need clearer text about the intention here, >>>> answering the question: "When is a string allowed by a profile?". I >>>> personally can not really tell from the draft right now. >>> >>> In part, I don't think it is the responsibility of this specification to >>> answer that question, other than to make it clear that you need to check >>> a string against the full set of rules defined by a profile. I do think >>> it would be helpful to provide some examples, although I think they >>> probably belong in the various specs that define the profiles (so far >>> that would be nickname, saslprepbis, and 6122bis). >>> >> I think I agree. And I think that is why I suggested leaving >> normalizations and mappings out of the classes. We want to tell people >> that they have to normalize, and we want them to think about mappings. >> But the exact order of those operations, who needs to perform them, what >> is valid in protocol slots, etc. is their business. >> >> And what that means in particular (to me) is that a profile would tell >> you after which of the steps a string needs to be PVALID under a certain >> class. > > s/class/profile/ (IMHO) > I think that might be where we are talking cross purposes. My understanding is, that we have an algorithm that will tell us whether a codepoint is PVALID, according to the set of codepoints a class allows. Profiles have no influence on this decision. I.e. nothing that determines whether a codepoint is PVALID may be (re)defined by a profile. This always requires a subclass. >> E.g. for SASLPrepbis you would (as I understand it) split up the >> simple username into its parts, perform normalization and all mappings >> except case mapping, and then check whether the userparts are >> PVALID/ID_PVAL. Case mappings would then be performed whenever the SASL >> mechanism tells you to. >> >> If everyone is required to specify such rules (usually less complex ones >> I'd hope) I don't see the benefit of formally including normalization >> and mappings in the definition of a class (in particular if that >> definition pretty much is "that's up to you"). >> This would also allow making this text generic, and not repeating it for >> IdentifierClass and FreeformClass. > > I'm sorry, I've lost track of exactly what "this text" refers to here. > I think I had this much clearer in my head then I managed to express it, sorry. Let me try again: What we have right now are classes. These do two things: a) Limit the character set b) Specify a set of properties usages need to define Specifically a) encompasses Valid, Disallowed, and Unassigned, while b) encompasses Width Mapping, Additional Mappings, Case Mapping, Normalization, and Directionality Note that the text describing b) is almost completely identical for IdentifierClass and FreeformClass. This is what "this text" was refering to. My suggestion is to restrict classes to include only the a) properties. We would still say that a usage needs to specify everything in b) though. The main benefit I see in this is that classes become self-contained. Saying that a string has to conform to a class becomes a much more self-explanatory statement. The usage would however need to further define at which point in time this conformance is necessary. E.g. if normalization is done server side, clients may already need to produce strings conforming to the class. But when clients perform normalization checking whether a string is in a class after normalization might reduce user surprise. Regards, Florian From stpeter@stpeter.im Tue Oct 15 05:45:33 2013 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 8D16F11E81E0 for ; Tue, 15 Oct 2013 05:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.331 X-Spam-Level: X-Spam-Status: No, score=-102.331 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yKO0JDSa8xP for ; Tue, 15 Oct 2013 05:45:24 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E27D321F9D56 for ; Tue, 15 Oct 2013 05:45:20 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 125BD40FA9; Tue, 15 Oct 2013 06:51:31 -0600 (MDT) Message-ID: <525D38DC.7010504@stpeter.im> Date: Tue, 15 Oct 2013 06:45:16 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Florian Zeitz References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> <522FD033.3070001@babelmonkeys.de> <5254CB86.40706@stpeter.im> <5258A86C.7080708@babelmonkeys.de> <5258B4F8.4030601@stpeter.im> <525931C0.6090600@babelmonkeys.de> <525C0F72.1050002@stpeter.im> <525D1608.3050309@babelmonkeys.de> In-Reply-To: <525D1608.3050309@babelmonkeys.de> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: precis@ietf.org Subject: Re: [precis] WGLC: draft-ietf-precis-framework-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2013 12:45:33 -0000 On 10/15/13 4:16 AM, Florian Zeitz wrote: > Am 14.10.2013 17:36, schrieb Peter Saint-Andre: >> On 10/12/13 5:25 AM, Florian Zeitz wrote: >>> On 12.10.2013 04:33, Peter Saint-Andre wrote: >>>> On 10/11/2013 07:39 PM, Florian Zeitz wrote: >>>>> On 09.10.2013 05:20, Peter Saint-Andre wrote: >>> What I'm trying to avoid here is a certain ambiguity I think we have >>> now. To give an example: Text we have in 6122bis now says «MUST consist >>> only of Unicode code points that conform to the "FreeformClass" base >>> string class». >> >> Ah, I see your point. I think we'll need to adjust the text in all of >> the documents that use the framework. >> >> So for instance, currently we say: >> >> A resourcepart MUST consist only of Unicode code points that conform >> to the "FreeformClass" base string class defined in >> [I-D.ietf-precis-framework]. (Note that there is no XMPP-specific >> subclass for resourceparts.) >> >> The normalization and mapping rules for the resourcepart of a JID are >> as follows, where the operations specified MUST be completed in the >> order shown: >> >> 1. Fullwidth and halfwidth characters MAY be mapped to their >> decomposition equivalents. >> >> [etc.] >> >> I think we'll need to change that to say something like this: >> >> A resourcepart MUST consist only of Unicode code points that conform >> to the "JIDresourceFreeformClass" profile, which is defined as >> follows: >> >> 1. The base string class is the "FreeformClass" class specified in >> [I-D.ietf-precis-framework] >> >> 2. Fullwidth and halfwidth characters MAY be mapped to their >> decomposition equivalents. >> >> That is, the base string class can immediately limit the characters that >> you even consider. For the "JIDlocalIdentifierClass" profile (or >> whatever we call it), if a character is disallowed by the >> IdentifierClass then you don't need to consider it further, but if it's >> allowed then you need to complete further processing (such as the >> relevant mapping operations). >> > I'm not sure that is the right approach, see below. > It also occurs to me that the framework draft currently calls this > "Usage" instead of "Profile", or is that yet another concept? Based on other last call feedback (see exchanges with Martin), I've provisionally replaced the concepts of subclasses and usages with the concept of a profile. This has (IMHO) simplified matters. >>> For arguments sake lets pretend it also specified NFKC. >>> Does "U+1D7D0 MATHEMATICAL BOLD DIGIT TWO" conform to "FreeformClass" in >>> this case? >>> >>> It's either "Yes, that is clearly FREE_PVAL", or "No, that must be >>> normalized to U+0032 DIGIT TWO", depending on your reading. >> >> Here again I think conformance applies only at the level of the profile. >> The base string classes just limit the universe of characters you need >> to consider. >> >>>>> This may even already be the intent, but as I said a profile can easily >>>>> be defined such, that a string matches this criteria, but can never be >>>>> produced after the specified normalization and all mappings were applied. >>>>> At any rate I think we need clearer text about the intention here, >>>>> answering the question: "When is a string allowed by a profile?". I >>>>> personally can not really tell from the draft right now. >>>> >>>> In part, I don't think it is the responsibility of this specification to >>>> answer that question, other than to make it clear that you need to check >>>> a string against the full set of rules defined by a profile. I do think >>>> it would be helpful to provide some examples, although I think they >>>> probably belong in the various specs that define the profiles (so far >>>> that would be nickname, saslprepbis, and 6122bis). >>>> >>> I think I agree. And I think that is why I suggested leaving >>> normalizations and mappings out of the classes. We want to tell people >>> that they have to normalize, and we want them to think about mappings. >>> But the exact order of those operations, who needs to perform them, what >>> is valid in protocol slots, etc. is their business. >>> >>> And what that means in particular (to me) is that a profile would tell >>> you after which of the steps a string needs to be PVALID under a certain >>> class. >> >> s/class/profile/ (IMHO) >> > I think that might be where we are talking cross purposes. > My understanding is, that we have an algorithm that will tell us whether > a codepoint is PVALID, according to the set of codepoints a class > allows. Profiles have no influence on this decision. I.e. nothing that > determines whether a codepoint is PVALID may be (re)defined by a > profile. This always requires a subclass. It all depends on what you mean by the "P" in PVALID. In practice, my feeling is that you want to know if a given codepoint is allowed in, say, the localpart of an XMPP address. The base class isn't always going to answer that question for you. >>> E.g. for SASLPrepbis you would (as I understand it) split up the >>> simple username into its parts, perform normalization and all mappings >>> except case mapping, and then check whether the userparts are >>> PVALID/ID_PVAL. Case mappings would then be performed whenever the SASL >>> mechanism tells you to. >>> >>> If everyone is required to specify such rules (usually less complex ones >>> I'd hope) I don't see the benefit of formally including normalization >>> and mappings in the definition of a class (in particular if that >>> definition pretty much is "that's up to you"). >>> This would also allow making this text generic, and not repeating it for >>> IdentifierClass and FreeformClass. >> >> I'm sorry, I've lost track of exactly what "this text" refers to here. >> > I think I had this much clearer in my head then I managed to express it, > sorry. Let me try again: > What we have right now are classes. These do two things: > a) Limit the character set > b) Specify a set of properties usages need to define s/usages/profiles/ yes (if we accept the simplification that Martin and I worked out). > Specifically a) encompasses Valid, Disallowed, and Unassigned, while > b) encompasses Width Mapping, Additional Mappings, Case Mapping, > Normalization, and Directionality > > Note that the text describing b) is almost completely identical for > IdentifierClass and FreeformClass. This is what "this text" was refering to. Thanks for the clarification. > My suggestion is to restrict classes to include only the a) properties. > We would still say that a usage needs to specify everything in b) though. I'm confused again, because that's what I *thought* we were doing all along. However, if that wasn't clear to you then we need to improve the text. > The main benefit I see in this is that classes become self-contained. > Saying that a string has to conform to a class becomes a much more > self-explanatory statement. The usage would however need to further > define at which point in time this conformance is necessary. > E.g. if normalization is done server side, clients may already need to > produce strings conforming to the class. But when clients perform > normalization checking whether a string is in a class after > normalization might reduce user surprise. Indeed. Peter -- Peter Saint-Andre https://stpeter.im/ From florob@babelmonkeys.de Tue Oct 15 06:32:48 2013 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 3A24011E81DB for ; Tue, 15 Oct 2013 06:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wk9yOjyWztas for ; Tue, 15 Oct 2013 06:32:47 -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 D226611E81E6 for ; Tue, 15 Oct 2013 06:32:43 -0700 (PDT) Received: from [134.130.62.162] by babelmonkeys.de with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1VW4lm-0006xQ-UL; Tue, 15 Oct 2013 15:34:42 +0200 Message-ID: <525D43F8.6030300@babelmonkeys.de> Date: Tue, 15 Oct 2013 15:32:40 +0200 From: Florian Zeitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> <522FD033.3070001@babelmonkeys.de> <5254CB86.40706@stpeter.im> <5258A86C.7080708@babelmonkeys.de> <5258B4F8.4030601@stpeter.im> <525931C0.6090600@babelmonkeys.de> <525C0F72.1050002@stpeter.im> <525D1608.3050309@babelmonkeys.de> <525D38DC.7010504@stpeter.im> In-Reply-To: <525D38DC.7010504@stpeter.im> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: precis@ietf.org Subject: Re: [precis] WGLC: draft-ietf-precis-framework-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2013 13:32:48 -0000 Am 15.10.2013 14:45, schrieb Peter Saint-Andre: > On 10/15/13 4:16 AM, Florian Zeitz wrote: >> Am 14.10.2013 17:36, schrieb Peter Saint-Andre: >>> On 10/12/13 5:25 AM, Florian Zeitz wrote: >>>> On 12.10.2013 04:33, Peter Saint-Andre wrote: >>>>> On 10/11/2013 07:39 PM, Florian Zeitz wrote: >>>>>> On 09.10.2013 05:20, Peter Saint-Andre wrote: >>>> What I'm trying to avoid here is a certain ambiguity I think we have >>>> now. To give an example: Text we have in 6122bis now says «MUST consist >>>> only of Unicode code points that conform to the "FreeformClass" base >>>> string class». >>> >>> Ah, I see your point. I think we'll need to adjust the text in all of >>> the documents that use the framework. >>> >>> So for instance, currently we say: >>> >>> A resourcepart MUST consist only of Unicode code points that conform >>> to the "FreeformClass" base string class defined in >>> [I-D.ietf-precis-framework]. (Note that there is no XMPP-specific >>> subclass for resourceparts.) >>> >>> The normalization and mapping rules for the resourcepart of a JID are >>> as follows, where the operations specified MUST be completed in the >>> order shown: >>> >>> 1. Fullwidth and halfwidth characters MAY be mapped to their >>> decomposition equivalents. >>> >>> [etc.] >>> >>> I think we'll need to change that to say something like this: >>> >>> A resourcepart MUST consist only of Unicode code points that conform >>> to the "JIDresourceFreeformClass" profile, which is defined as >>> follows: >>> >>> 1. The base string class is the "FreeformClass" class specified in >>> [I-D.ietf-precis-framework] >>> >>> 2. Fullwidth and halfwidth characters MAY be mapped to their >>> decomposition equivalents. >>> >>> That is, the base string class can immediately limit the characters that >>> you even consider. For the "JIDlocalIdentifierClass" profile (or >>> whatever we call it), if a character is disallowed by the >>> IdentifierClass then you don't need to consider it further, but if it's >>> allowed then you need to complete further processing (such as the >>> relevant mapping operations). >>> >> I'm not sure that is the right approach, see below. >> It also occurs to me that the framework draft currently calls this >> "Usage" instead of "Profile", or is that yet another concept? > > Based on other last call feedback (see exchanges with Martin), I've > provisionally replaced the concepts of subclasses and usages with the > concept of a profile. This has (IMHO) simplified matters. > >>>> For arguments sake lets pretend it also specified NFKC. >>>> Does "U+1D7D0 MATHEMATICAL BOLD DIGIT TWO" conform to "FreeformClass" in >>>> this case? >>>> >>>> It's either "Yes, that is clearly FREE_PVAL", or "No, that must be >>>> normalized to U+0032 DIGIT TWO", depending on your reading. >>> >>> Here again I think conformance applies only at the level of the profile. >>> The base string classes just limit the universe of characters you need >>> to consider. >>> >>>>>> This may even already be the intent, but as I said a profile can easily >>>>>> be defined such, that a string matches this criteria, but can never be >>>>>> produced after the specified normalization and all mappings were applied. >>>>>> At any rate I think we need clearer text about the intention here, >>>>>> answering the question: "When is a string allowed by a profile?". I >>>>>> personally can not really tell from the draft right now. >>>>> >>>>> In part, I don't think it is the responsibility of this specification to >>>>> answer that question, other than to make it clear that you need to check >>>>> a string against the full set of rules defined by a profile. I do think >>>>> it would be helpful to provide some examples, although I think they >>>>> probably belong in the various specs that define the profiles (so far >>>>> that would be nickname, saslprepbis, and 6122bis). >>>>> >>>> I think I agree. And I think that is why I suggested leaving >>>> normalizations and mappings out of the classes. We want to tell people >>>> that they have to normalize, and we want them to think about mappings. >>>> But the exact order of those operations, who needs to perform them, what >>>> is valid in protocol slots, etc. is their business. >>>> >>>> And what that means in particular (to me) is that a profile would tell >>>> you after which of the steps a string needs to be PVALID under a certain >>>> class. >>> >>> s/class/profile/ (IMHO) >>> >> I think that might be where we are talking cross purposes. >> My understanding is, that we have an algorithm that will tell us whether >> a codepoint is PVALID, according to the set of codepoints a class >> allows. Profiles have no influence on this decision. I.e. nothing that >> determines whether a codepoint is PVALID may be (re)defined by a >> profile. This always requires a subclass. > > It all depends on what you mean by the "P" in PVALID. In practice, my > feeling is that you want to know if a given codepoint is allowed in, > say, the localpart of an XMPP address. The base class isn't always going > to answer that question for you. > I'm actually talking about the calculated property here, be it named as it will. My point is we have an algorithm to calculate PVALID, but we don't have one for "is this an allowed string for a profile". Which, to be clear, I think is fine for the framework document. >>>> E.g. for SASLPrepbis you would (as I understand it) split up the >>>> simple username into its parts, perform normalization and all mappings >>>> except case mapping, and then check whether the userparts are >>>> PVALID/ID_PVAL. Case mappings would then be performed whenever the SASL >>>> mechanism tells you to. >>>> >>>> If everyone is required to specify such rules (usually less complex ones >>>> I'd hope) I don't see the benefit of formally including normalization >>>> and mappings in the definition of a class (in particular if that >>>> definition pretty much is "that's up to you"). >>>> This would also allow making this text generic, and not repeating it for >>>> IdentifierClass and FreeformClass. >>> >>> I'm sorry, I've lost track of exactly what "this text" refers to here. >>> >> I think I had this much clearer in my head then I managed to express it, >> sorry. Let me try again: >> What we have right now are classes. These do two things: >> a) Limit the character set >> b) Specify a set of properties usages need to define > > s/usages/profiles/ yes (if we accept the simplification that Martin and > I worked out). > >> Specifically a) encompasses Valid, Disallowed, and Unassigned, while >> b) encompasses Width Mapping, Additional Mappings, Case Mapping, >> Normalization, and Directionality >> >> Note that the text describing b) is almost completely identical for >> IdentifierClass and FreeformClass. This is what "this text" was refering to. > > Thanks for the clarification. > >> My suggestion is to restrict classes to include only the a) properties. >> We would still say that a usage needs to specify everything in b) though. > > I'm confused again, because that's what I *thought* we were doing all > along. However, if that wasn't clear to you then we need to improve the > text. > Umm... I think I'm still not making myself clear :/. And I suspect that is, because "include" is ambiguous here. I do realize that we are already at the point where the classes explicitly specify everything in a), while everything in b) is profile dependent. What I'm saying is that IMHO b) should not be part of a class at all. I'd want to have classes, consisting of Valid, Disallowed and Unassigned sets. For these we have an algorithm determining whether a codepoint is within the class (i.e. PVALID or CONTEXT[JO] + rule), or not. Each usage (I think the term is more appropriate for this scheme), would then define everything from the b) set, and which class to restrict data to. Florian >> The main benefit I see in this is that classes become self-contained. >> Saying that a string has to conform to a class becomes a much more >> self-explanatory statement. The usage would however need to further >> define at which point in time this conformance is necessary. >> E.g. if normalization is done server side, clients may already need to >> produce strings conforming to the class. But when clients perform >> normalization checking whether a string is in a class after >> normalization might reduce user surprise. > > Indeed. > > Peter > From nico@cryptonector.com Tue Oct 15 10:17:07 2013 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 3D49211E8141; Tue, 15 Oct 2013 10:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.114 X-Spam-Level: X-Spam-Status: No, score=-2.114 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmc1ZcMVyrcB; Tue, 15 Oct 2013 10:17:02 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id F06C311E8186; Tue, 15 Oct 2013 10:16:52 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 7450E59807B; Tue, 15 Oct 2013 10:16:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=62vYhxeOj+yfom9jQAmX KZ5FThQ=; b=CNOoDEsGSkhSGGAteTZsMJFLzYHfXq6L4oRJyG5QYJQxgZ8o5uoO wLm5mjd656fLn4VsEaPXGABmE82kRdCV29XuuiBgS8JL4cU8dW8ARfl+yUTVETED +77xD0utbwZZyctlac/zhucnoXY1+tRlaiKa1zcakkYM30qs/Z7fRCQ= Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id D6E1B59806A; Tue, 15 Oct 2013 10:16:41 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t61so8769359wes.20 for ; Tue, 15 Oct 2013 10:16:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IY0aeA5+xTkixTXntBDXXSWowsiVRNyFXQ3JDMYHelQ=; b=D45c/WjVDZ8Rv+qOU+qBva3wwzLyiLhiMAa5UdXzwuajz1PVSSBvIfn3tmQWzhw/tT 7opjGcTYlI4TUSFCtrKUP+s95OQQU2quJ1brz3E5MS5H+lWAARBKp8a3twWc1+8c06Et 5iZu55LH8BbAksgMvCtP0auiJVZdi5jGcmKgUT3GRKUHyXWP9FcG71RuKm6mc6e+3bXO hnYt5XS68xGjVdc7ocie6kphvIVcdvt33rbHjy/Rwv8lSFgxyfQ0rJR412QZEk+tGnd6 iouvuXw4rP1OGt+AR4R8arTgoW5I7erJmqMXXm1aBbZ0R2Wc+IisKK/qLlkhOx1be/QU rxhg== MIME-Version: 1.0 X-Received: by 10.194.248.130 with SMTP id ym2mr2698689wjc.61.1381857400192; Tue, 15 Oct 2013 10:16:40 -0700 (PDT) Received: by 10.216.151.136 with HTTP; Tue, 15 Oct 2013 10:16:40 -0700 (PDT) In-Reply-To: <525C339A.20407@stpeter.im> References: <51FEEC99.1020901@stpeter.im> <52090F96.30700@stpeter.im> <522E5CAA.5010902@stpeter.im> <5230B3B3.3040805@babelmonkeys.de> <87zjr2pmhs.fsf@latte.josefsson.org> <87txharmne.fsf@latte.josefsson.org> <20130924231746.73c578b7@latte.josefsson.org> <524EB8B4.2000509@isode.com> <525C339A.20407@stpeter.im> Date: Tue, 15 Oct 2013 12:16:40 -0500 Message-ID: From: Nico Williams To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Sam Hartman , "precis@ietf.org" Subject: Re: [precis] [kitten] Fwd: Re: I-D Action: draft-ietf-precis-saslprepbis-04.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2013 17:17:07 -0000 On Mon, Oct 14, 2013 at 1:10 PM, Peter Saint-Andre wrote: I'm OK with this. I would add that if a mechanism allows the "last possible moment" to always be on the server side then the choice of whether to case fold can be left to the deployer. Also, mechanisms that have enough round trips can always leave this to the deployer as well. Even mechanisms that don't -- one could always indicate this via DNS, but I won't go there. Nico -- From stpeter@stpeter.im Tue Oct 15 10:39:36 2013 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 AE70D1F0D5C; Tue, 15 Oct 2013 10:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.482 X-Spam-Level: X-Spam-Status: No, score=-102.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQYWyo3p--Tu; Tue, 15 Oct 2013 10:39:30 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 991881F0D57; Tue, 15 Oct 2013 10:39:27 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0AEA341019; Tue, 15 Oct 2013 11:45:43 -0600 (MDT) Message-ID: <525D7DCC.6020609@stpeter.im> Date: Tue, 15 Oct 2013 11:39:24 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Nico Williams References: <51FEEC99.1020901@stpeter.im> <52090F96.30700@stpeter.im> <522E5CAA.5010902@stpeter.im> <5230B3B3.3040805@babelmonkeys.de> <87zjr2pmhs.fsf@latte.josefsson.org> <87txharmne.fsf@latte.josefsson.org> <20130924231746.73c578b7@latte.josefsson.org> <524EB8B4.2000509@isode.com> <525C339A.20407@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" , Sam Hartman , "precis@ietf.org" Subject: Re: [precis] [kitten] Fwd: Re: I-D Action: draft-ietf-precis-saslprepbis-04.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2013 17:39:36 -0000 On 10/15/13 11:16 AM, Nico Williams wrote: > On Mon, Oct 14, 2013 at 1:10 PM, Peter Saint-Andre wrote: > > I'm OK with this. I would add that if a mechanism allows the "last > possible moment" to always be on the server side then the choice of > whether to case fold can be left to the deployer. Also, mechanisms > that have enough round trips can always leave this to the deployer as > well. True. I'll try to formulate some text along those lines. > Even mechanisms that don't -- one could always indicate this > via DNS, but I won't go there. Agreed. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Tue Oct 15 10:56:54 2013 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 5DC3C11E81F7 for ; Tue, 15 Oct 2013 10:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUYs9AUaI5A9 for ; Tue, 15 Oct 2013 10:56:35 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id F0F0911E819D for ; Tue, 15 Oct 2013 10:56:27 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.235]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F1AB641019; Tue, 15 Oct 2013 12:02:43 -0600 (MDT) Message-ID: <525D81C7.6010904@stpeter.im> Date: Tue, 15 Oct 2013 11:56:23 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Florian Zeitz References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> <522FD033.3070001@babelmonkeys.de> <5254CB86.40706@stpeter.im> <5258A86C.7080708@babelmonkeys.de> <5258B4F8.4030601@stpeter.im> <525931C0.6090600@babelmonkeys.de> <525C0F72.1050002@stpeter.im> <525D1608.3050309@babelmonkeys.de> <525D38DC.7010504@stpeter.im> <525D43F8.6030300@babelmonkeys.de> In-Reply-To: <525D43F8.6030300@babelmonkeys.de> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: precis@ietf.org Subject: Re: [precis] WGLC: draft-ietf-precis-framework-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2013 17:56:54 -0000 On 10/15/13 7:32 AM, Florian Zeitz wrote: > Am 15.10.2013 14:45, schrieb Peter Saint-Andre: >> On 10/15/13 4:16 AM, Florian Zeitz wrote: >>> Am 14.10.2013 17:36, schrieb Peter Saint-Andre: >>>> On 10/12/13 5:25 AM, Florian Zeitz wrote: >>>>> On 12.10.2013 04:33, Peter Saint-Andre wrote: >>>>>> On 10/11/2013 07:39 PM, Florian Zeitz wrote: >>>>>>> On 09.10.2013 05:20, Peter Saint-Andre wrote: >>>>> What I'm trying to avoid here is a certain ambiguity I think we have >>>>> now. To give an example: Text we have in 6122bis now says «MUST consist >>>>> only of Unicode code points that conform to the "FreeformClass" base >>>>> string class». >>>> >>>> Ah, I see your point. I think we'll need to adjust the text in all of >>>> the documents that use the framework. >>>> >>>> So for instance, currently we say: >>>> >>>> A resourcepart MUST consist only of Unicode code points that conform >>>> to the "FreeformClass" base string class defined in >>>> [I-D.ietf-precis-framework]. (Note that there is no XMPP-specific >>>> subclass for resourceparts.) >>>> >>>> The normalization and mapping rules for the resourcepart of a JID are >>>> as follows, where the operations specified MUST be completed in the >>>> order shown: >>>> >>>> 1. Fullwidth and halfwidth characters MAY be mapped to their >>>> decomposition equivalents. >>>> >>>> [etc.] >>>> >>>> I think we'll need to change that to say something like this: >>>> >>>> A resourcepart MUST consist only of Unicode code points that conform >>>> to the "JIDresourceFreeformClass" profile, which is defined as >>>> follows: >>>> >>>> 1. The base string class is the "FreeformClass" class specified in >>>> [I-D.ietf-precis-framework] >>>> >>>> 2. Fullwidth and halfwidth characters MAY be mapped to their >>>> decomposition equivalents. >>>> >>>> That is, the base string class can immediately limit the characters that >>>> you even consider. For the "JIDlocalIdentifierClass" profile (or >>>> whatever we call it), if a character is disallowed by the >>>> IdentifierClass then you don't need to consider it further, but if it's >>>> allowed then you need to complete further processing (such as the >>>> relevant mapping operations). >>>> >>> I'm not sure that is the right approach, see below. >>> It also occurs to me that the framework draft currently calls this >>> "Usage" instead of "Profile", or is that yet another concept? >> >> Based on other last call feedback (see exchanges with Martin), I've >> provisionally replaced the concepts of subclasses and usages with the >> concept of a profile. This has (IMHO) simplified matters. >> >>>>> For arguments sake lets pretend it also specified NFKC. >>>>> Does "U+1D7D0 MATHEMATICAL BOLD DIGIT TWO" conform to "FreeformClass" in >>>>> this case? >>>>> >>>>> It's either "Yes, that is clearly FREE_PVAL", or "No, that must be >>>>> normalized to U+0032 DIGIT TWO", depending on your reading. >>>> >>>> Here again I think conformance applies only at the level of the profile. >>>> The base string classes just limit the universe of characters you need >>>> to consider. >>>> >>>>>>> This may even already be the intent, but as I said a profile can easily >>>>>>> be defined such, that a string matches this criteria, but can never be >>>>>>> produced after the specified normalization and all mappings were applied. >>>>>>> At any rate I think we need clearer text about the intention here, >>>>>>> answering the question: "When is a string allowed by a profile?". I >>>>>>> personally can not really tell from the draft right now. >>>>>> >>>>>> In part, I don't think it is the responsibility of this specification to >>>>>> answer that question, other than to make it clear that you need to check >>>>>> a string against the full set of rules defined by a profile. I do think >>>>>> it would be helpful to provide some examples, although I think they >>>>>> probably belong in the various specs that define the profiles (so far >>>>>> that would be nickname, saslprepbis, and 6122bis). >>>>>> >>>>> I think I agree. And I think that is why I suggested leaving >>>>> normalizations and mappings out of the classes. We want to tell people >>>>> that they have to normalize, and we want them to think about mappings. >>>>> But the exact order of those operations, who needs to perform them, what >>>>> is valid in protocol slots, etc. is their business. >>>>> >>>>> And what that means in particular (to me) is that a profile would tell >>>>> you after which of the steps a string needs to be PVALID under a certain >>>>> class. >>>> >>>> s/class/profile/ (IMHO) >>>> >>> I think that might be where we are talking cross purposes. >>> My understanding is, that we have an algorithm that will tell us whether >>> a codepoint is PVALID, according to the set of codepoints a class >>> allows. Profiles have no influence on this decision. I.e. nothing that >>> determines whether a codepoint is PVALID may be (re)defined by a >>> profile. This always requires a subclass. >> >> It all depends on what you mean by the "P" in PVALID. In practice, my >> feeling is that you want to know if a given codepoint is allowed in, >> say, the localpart of an XMPP address. The base class isn't always going >> to answer that question for you. >> > I'm actually talking about the calculated property here, be it named as > it will. My point is we have an algorithm to calculate PVALID, but we > don't have one for "is this an allowed string for a profile". Which, to > be clear, I think is fine for the framework document. OK. I agree. >>>>> E.g. for SASLPrepbis you would (as I understand it) split up the >>>>> simple username into its parts, perform normalization and all mappings >>>>> except case mapping, and then check whether the userparts are >>>>> PVALID/ID_PVAL. Case mappings would then be performed whenever the SASL >>>>> mechanism tells you to. >>>>> >>>>> If everyone is required to specify such rules (usually less complex ones >>>>> I'd hope) I don't see the benefit of formally including normalization >>>>> and mappings in the definition of a class (in particular if that >>>>> definition pretty much is "that's up to you"). >>>>> This would also allow making this text generic, and not repeating it for >>>>> IdentifierClass and FreeformClass. >>>> >>>> I'm sorry, I've lost track of exactly what "this text" refers to here. >>>> >>> I think I had this much clearer in my head then I managed to express it, >>> sorry. Let me try again: >>> What we have right now are classes. These do two things: >>> a) Limit the character set >>> b) Specify a set of properties usages need to define >> >> s/usages/profiles/ yes (if we accept the simplification that Martin and >> I worked out). >> >>> Specifically a) encompasses Valid, Disallowed, and Unassigned, while >>> b) encompasses Width Mapping, Additional Mappings, Case Mapping, >>> Normalization, and Directionality >>> >>> Note that the text describing b) is almost completely identical for >>> IdentifierClass and FreeformClass. This is what "this text" was refering to. >> >> Thanks for the clarification. >> >>> My suggestion is to restrict classes to include only the a) properties. >>> We would still say that a usage needs to specify everything in b) though. >> >> I'm confused again, because that's what I *thought* we were doing all >> along. However, if that wasn't clear to you then we need to improve the >> text. >> > Umm... I think I'm still not making myself clear :/. And I suspect that > is, because "include" is ambiguous here. > I do realize that we are already at the point where the classes > explicitly specify everything in a), while everything in b) is profile > dependent. > What I'm saying is that IMHO b) should not be part of a class at all. I understand. You're saying let's move everything about mapping and normalization and directionality out of Section 3 (about string classes) and move it to Section 4 (about profiles). That makes a lot of sense. Sorry I was so dense. :-) > I'd want to have classes, consisting of Valid, Disallowed and Unassigned > sets. For these we have an algorithm determining whether a codepoint is > within the class (i.e. PVALID or CONTEXT[JO] + rule), or not. > Each usage (I think the term is more appropriate for this scheme), would > then define everything from the b) set, and which class to restrict data to. Got it. BTW, I prefer the term profile because during WG meetings and list discussions that's the term I've heard people naturally use. It seems artificial to force people to call it a "usage" when their tendency is to use the term "profile". Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Tue Oct 15 12:57:37 2013 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 6D4E411E81E9 for ; Tue, 15 Oct 2013 12:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGcr0g2vXBFz for ; Tue, 15 Oct 2013 12:57:22 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 93F2211E8183 for ; Tue, 15 Oct 2013 12:57:22 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2A5DE41019; Tue, 15 Oct 2013 14:03:40 -0600 (MDT) Message-ID: <525D9E20.40209@stpeter.im> Date: Tue, 15 Oct 2013 13:57:20 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "precis@ietf.org" X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [precis] submission plan X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2013 19:57:37 -0000 Dear chairs and WG, Because the submission cut-off is approaching and I've incorporated lots of feedback into the documents, I'd like to submit version -10 of draft-ietf-precis-framework today or tonight so that folks here can review what I've done. That will enable me to submit a second revision before the cut-off if needed, along with updated versions of the nickname, saslprepbis, and XMPP documents to track the framework. Thanks! Peter -- Peter Saint-Andre https://stpeter.im/ From internet-drafts@ietf.org Tue Oct 15 15:26:45 2013 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 DC43B11E8229; Tue, 15 Oct 2013 15:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ND2Cok20VqEH; Tue, 15 Oct 2013 15:26:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD5611E8153; Tue, 15 Oct 2013 15:26:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131015222642.2154.19165.idtracker@ietfa.amsl.com> Date: Tue, 15 Oct 2013 15:26:42 -0700 Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-framework-10.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 22:26:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Preparation and Comparison of Internation= alized Strings Working Group of the IETF. Title : PRECIS Framework: Preparation and Comparison of Internat= ionalized Strings in Application Protocols Author(s) : Peter Saint-Andre Marc Blanchet Filename : draft-ietf-precis-framework-10.txt Pages : 63 Date : 2013-10-15 Abstract: Application protocols using Unicode code points in protocol strings need to properly prepare such strings in order 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 and comparison of internationalized strings (a.k.a. "PRECIS") in a way that depends on the properties of Unicode code points 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 3454. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-framework There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-precis-framework-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-precis-framework-10 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 stpeter@stpeter.im Tue Oct 15 15:52:41 2013 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 972F821F9DF6 for ; Tue, 15 Oct 2013 15:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVITl0w77tYI for ; Tue, 15 Oct 2013 15:52:26 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4B21411E81FA for ; Tue, 15 Oct 2013 15:52:26 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 365DA4100F; Tue, 15 Oct 2013 16:58:44 -0600 (MDT) Message-ID: <525DC728.2090002@stpeter.im> Date: Tue, 15 Oct 2013 16:52:24 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: precis@ietf.org References: <20131015222642.2154.19165.idtracker@ietfa.amsl.com> In-Reply-To: <20131015222642.2154.19165.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [precis] I-D Action: draft-ietf-precis-framework-10.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2013 22:52:41 -0000 On 10/15/13 4:26 PM, internet-drafts@ietf.org wrote: > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-precis-framework > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-precis-framework-10 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-framework-10 Reviews of -10 or the diff would be helpful. I plan to check them both to make sure that I've accurately addressed all of the last call feedback. Thanks! Peter From duerst@it.aoyama.ac.jp Tue Oct 15 19:34:48 2013 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 5F18D11E81F4 for ; Tue, 15 Oct 2013 19:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.569 X-Spam-Level: X-Spam-Status: No, score=-104.569 tagged_above=-999 required=5 tests=[AWL=1.221, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijgUdVPP7Pa3 for ; Tue, 15 Oct 2013 19:34:43 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id B5EC911E80E9 for ; Tue, 15 Oct 2013 19:34:42 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r9G2YTBM000607; Wed, 16 Oct 2013 11:34:30 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 2606_6102_7b6f932e_360b_11e3_93cd_001e6722eec2; Wed, 16 Oct 2013 11:34:29 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id F0EC1BF521; Wed, 16 Oct 2013 11:34:28 +0900 (JST) Message-ID: <525DFB1F.8040401@it.aoyama.ac.jp> Date: Wed, 16 Oct 2013 11:34:07 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "precis@ietf.org" , "idna-update@alvestrand.no" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [precis] Category changes with Unicode 6.3 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 02:34:48 -0000 Excuse me if this has been checked and/or discussed already, but I just downloaded the Unicode 6.3 version (officially published a few days ago) of http://www.unicode.org/Public/UCD/latest/ucd/UnicodeData.txt and found several changes in character classification: OLD 180E;MONGOLIAN VOWEL SEPARATOR;Zs;0;WS;;;;;N;;;;; NEW 180E;MONGOLIAN VOWEL SEPARATOR;Cf;0;BN;;;;;N;;;;; OLD 1A1B;BUGINESE VOWEL SIGN AE;Mc;0;L;;;;;N;;;;; NEW 1A1B;BUGINESE VOWEL SIGN AE;Mn;0;NSM;;;;;N;;;;; OLD 2308;LEFT CEILING;Sm;0;ON;;;;;Y;;;;; 2309;RIGHT CEILING;Sm;0;ON;;;;;Y;;;;; 230A;LEFT FLOOR;Sm;0;ON;;;;;Y;;;;; 230B;RIGHT FLOOR;Sm;0;ON;;;;;Y;;;;; NEW 2308;LEFT CEILING;Ps;0;ON;;;;;Y;;;;; 2309;RIGHT CEILING;Pe;0;ON;;;;;Y;;;;; 230A;LEFT FLOOR;Ps;0;ON;;;;;Y;;;;; 230B;RIGHT FLOOR;Pe;0;ON;;;;;Y;;;;; Can somebody check whether and how they affect IDNA 2008 and/or precis? Again, if that has already been done, sorry for the noise. Regards, Martin. P.S.: All the other changes in UnicodeData.txt: Change in numerical value only: OLD 12456;CUNEIFORM NUMERIC SIGN NIGIDAMIN;Nl;0;L;;;;-1;N;;;;; 12457;CUNEIFORM NUMERIC SIGN NIGIDAESH;Nl;0;L;;;;-1;N;;;;; NEW 12456;CUNEIFORM NUMERIC SIGN NIGIDAMIN;Nl;0;L;;;;2;N;;;;; 12457;CUNEIFORM NUMERIC SIGN NIGIDAESH;Nl;0;L;;;;3;N;;;;; New characters (my understanding is that these are taken care of automatically): 061C;ARABIC LETTER MARK;Cf;0;AL;;;;;N;;;;; 2066;LEFT-TO-RIGHT ISOLATE;Cf;0;LRI;;;;;N;;;;; 2067;RIGHT-TO-LEFT ISOLATE;Cf;0;RLI;;;;;N;;;;; 2068;FIRST STRONG ISOLATE;Cf;0;FSI;;;;;N;;;;; 2069;POP DIRECTIONAL ISOLATE;Cf;0;PDI;;;;;N;;;;; From stpeter@stpeter.im Tue Oct 15 20:15:26 2013 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 1FA6921F994A for ; Tue, 15 Oct 2013 20:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.346 X-Spam-Level: X-Spam-Status: No, score=-102.346 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnqbqckAx-9l for ; Tue, 15 Oct 2013 20:15:18 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 21FBE21F992B for ; Tue, 15 Oct 2013 20:15:17 -0700 (PDT) Received: from [192.168.1.3] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 81BDB40FA9 for ; Tue, 15 Oct 2013 21:21:36 -0600 (MDT) Message-ID: <525E04C4.4040007@stpeter.im> Date: Tue, 15 Oct 2013 21:15:16 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: precis@ietf.org References: <525DFB1F.8040401@it.aoyama.ac.jp> In-Reply-To: <525DFB1F.8040401@it.aoyama.ac.jp> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [precis] Category changes with Unicode 6.3 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 03:15:28 -0000 On 10/15/2013 08:34 PM, "Martin J. Dürst" wrote: > Excuse me if this has been checked and/or discussed already, but I just > downloaded the Unicode 6.3 version (officially published a few days ago) I had not seen the new release, so I will check over the code points you have highlighted. Thank you very much for the report! Peter From paf@frobbit.se Tue Oct 15 22:26:59 2013 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 B4BFA11E80D9 for ; Tue, 15 Oct 2013 22:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j39O5SCrmbJi for ; Tue, 15 Oct 2013 22:26:58 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id C8C4A11E825A for ; Tue, 15 Oct 2013 22:26:54 -0700 (PDT) Received: from [IPv6:2001:67c:64:42:d997:fadd:90f:58bd] (unknown [IPv6:2001:67c:64:42:d997:fadd:90f:58bd]) by mail.frobbit.se (Postfix) with ESMTPSA id 2B3AA24066; Wed, 16 Oct 2013 07:26:44 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_D1C19706-8238-4286-BEA3-8FF3BBD5A397"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <525DFB1F.8040401@it.aoyama.ac.jp> Date: Wed, 16 Oct 2013 08:26:43 +0300 Message-Id: <828E7B94-0900-4CA4-96D1-47FEBC1881AA@frobbit.se> References: <525DFB1F.8040401@it.aoyama.ac.jp> To: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= X-Mailer: Apple Mail (2.1510) Cc: "idna-update@alvestrand.no" , "precis@ietf.org" Subject: Re: [precis] Category changes with Unicode 6.3 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 05:26:59 -0000 --Apple-Mail=_D1C19706-8238-4286-BEA3-8FF3BBD5A397 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I have in earlier beta versions of 6.3 not seen any problems, but I am = running my scripts now to see what's = up. Patrik On 16 okt 2013, at 05:34, Martin J. D=FCrst = wrote: > Excuse me if this has been checked and/or discussed already, but I = just downloaded the Unicode 6.3 version (officially published a few days = ago) of http://www.unicode.org/Public/UCD/latest/ucd/UnicodeData.txt and = found several changes in character classification: >=20 > OLD > 180E;MONGOLIAN VOWEL SEPARATOR;Zs;0;WS;;;;;N;;;;; > NEW > 180E;MONGOLIAN VOWEL SEPARATOR;Cf;0;BN;;;;;N;;;;; >=20 > OLD > 1A1B;BUGINESE VOWEL SIGN AE;Mc;0;L;;;;;N;;;;; > NEW > 1A1B;BUGINESE VOWEL SIGN AE;Mn;0;NSM;;;;;N;;;;; >=20 > OLD > 2308;LEFT CEILING;Sm;0;ON;;;;;Y;;;;; > 2309;RIGHT CEILING;Sm;0;ON;;;;;Y;;;;; > 230A;LEFT FLOOR;Sm;0;ON;;;;;Y;;;;; > 230B;RIGHT FLOOR;Sm;0;ON;;;;;Y;;;;; > NEW > 2308;LEFT CEILING;Ps;0;ON;;;;;Y;;;;; > 2309;RIGHT CEILING;Pe;0;ON;;;;;Y;;;;; > 230A;LEFT FLOOR;Ps;0;ON;;;;;Y;;;;; > 230B;RIGHT FLOOR;Pe;0;ON;;;;;Y;;;;; >=20 > Can somebody check whether and how they affect IDNA 2008 and/or = precis? >=20 > Again, if that has already been done, sorry for the noise. >=20 > Regards, Martin. >=20 >=20 > P.S.: > All the other changes in UnicodeData.txt: >=20 > Change in numerical value only: >=20 > OLD > 12456;CUNEIFORM NUMERIC SIGN NIGIDAMIN;Nl;0;L;;;;-1;N;;;;; > 12457;CUNEIFORM NUMERIC SIGN NIGIDAESH;Nl;0;L;;;;-1;N;;;;; > NEW > 12456;CUNEIFORM NUMERIC SIGN NIGIDAMIN;Nl;0;L;;;;2;N;;;;; > 12457;CUNEIFORM NUMERIC SIGN NIGIDAESH;Nl;0;L;;;;3;N;;;;; >=20 >=20 > New characters (my understanding is that these are taken care of = automatically): >=20 > 061C;ARABIC LETTER MARK;Cf;0;AL;;;;;N;;;;; >=20 > 2066;LEFT-TO-RIGHT ISOLATE;Cf;0;LRI;;;;;N;;;;; > 2067;RIGHT-TO-LEFT ISOLATE;Cf;0;RLI;;;;;N;;;;; > 2068;FIRST STRONG ISOLATE;Cf;0;FSI;;;;;N;;;;; > 2069;POP DIRECTIONAL ISOLATE;Cf;0;PDI;;;;;N;;;;; > _______________________________________________ > Idna-update mailing list > Idna-update@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/idna-update --Apple-Mail=_D1C19706-8238-4286-BEA3-8FF3BBD5A397 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSXiOTrMabGguI180RAlJlAKCRAGuUxl1Z0+JqwKaYphgoBadpGACeKc1p Oemf2KGKcex8StFmeFx5DGo= =MQ1o -----END PGP SIGNATURE----- --Apple-Mail=_D1C19706-8238-4286-BEA3-8FF3BBD5A397-- From paf@frobbit.se Tue Oct 15 22:40:40 2013 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 F399521F9A8D for ; Tue, 15 Oct 2013 22:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yj0dqlBZAtmx for ; Tue, 15 Oct 2013 22:40:39 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id AEB2421F9A49 for ; Tue, 15 Oct 2013 22:40:37 -0700 (PDT) Received: from [IPv6:2001:67c:64:42:d997:fadd:90f:58bd] (unknown [IPv6:2001:67c:64:42:d997:fadd:90f:58bd]) by mail.frobbit.se (Postfix) with ESMTPSA id 9D2E0219C6; Wed, 16 Oct 2013 07:40:36 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_07D02D0C-9749-4244-88CF-D4AB930B13A1"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <525DFB1F.8040401@it.aoyama.ac.jp> Date: Wed, 16 Oct 2013 08:40:35 +0300 Message-Id: <7693B3B4-7204-48F0-8C42-EBF5D701BAF4@frobbit.se> References: <525DFB1F.8040401@it.aoyama.ac.jp> To: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= X-Mailer: Apple Mail (2.1510) Cc: "idna-update@alvestrand.no" , "precis@ietf.org" Subject: Re: [precis] Category changes with Unicode 6.3 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 05:40:40 -0000 --Apple-Mail=_07D02D0C-9749-4244-88CF-D4AB930B13A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Executive summary: Does not impact IDNA2008. Longer explanation: On 16 okt 2013, at 05:34, Martin J. D=FCrst = wrote: > Excuse me if this has been checked and/or discussed already, but I = just downloaded the Unicode 6.3 version (officially published a few days = ago) of http://www.unicode.org/Public/UCD/latest/ucd/UnicodeData.txt and = found several changes in character classification: >=20 > OLD > 180E;MONGOLIAN VOWEL SEPARATOR;Zs;0;WS;;;;;N;;;;; > NEW > 180E;MONGOLIAN VOWEL SEPARATOR;Cf;0;BN;;;;;N;;;;; No change: $ grep '^180E;' ../6.[23].0/allcodepoints.txt=20 ../6.2.0/allcodepoints.txt:180E;DISALLOWED;I;C;MONGOLIAN VOWEL SEPARATOR ../6.3.0/allcodepoints.txt:180E;DISALLOWED;I;C;MONGOLIAN VOWEL SEPARATOR > OLD > 1A1B;BUGINESE VOWEL SIGN AE;Mc;0;L;;;;;N;;;;; > NEW > 1A1B;BUGINESE VOWEL SIGN AE;Mn;0;NSM;;;;;N;;;;; No change: $ grep '^1A1B;' ../6.[23].0/allcodepoints.txt=20 ../6.2.0/allcodepoints.txt:1A1B;PVALID;I;A;BUGINESE VOWEL SIGN AE ../6.3.0/allcodepoints.txt:1A1B;PVALID;I;A;BUGINESE VOWEL SIGN AE > OLD > 2308;LEFT CEILING;Sm;0;ON;;;;;Y;;;;; > 2309;RIGHT CEILING;Sm;0;ON;;;;;Y;;;;; > 230A;LEFT FLOOR;Sm;0;ON;;;;;Y;;;;; > 230B;RIGHT FLOOR;Sm;0;ON;;;;;Y;;;;; > NEW > 2308;LEFT CEILING;Ps;0;ON;;;;;Y;;;;; > 2309;RIGHT CEILING;Pe;0;ON;;;;;Y;;;;; > 230A;LEFT FLOOR;Ps;0;ON;;;;;Y;;;;; > 230B;RIGHT FLOOR;Pe;0;ON;;;;;Y;;;;; No change: $ egrep '^230[89AB];' ../6.[23].0/allcodepoints.txt=20 ../6.2.0/allcodepoints.txt:2308;DISALLOWED;I;;LEFT CEILING ../6.2.0/allcodepoints.txt:2309;DISALLOWED;I;;RIGHT CEILING ../6.2.0/allcodepoints.txt:230A;DISALLOWED;I;;LEFT FLOOR ../6.2.0/allcodepoints.txt:230B;DISALLOWED;I;;RIGHT FLOOR ../6.3.0/allcodepoints.txt:2308;DISALLOWED;I;;LEFT CEILING ../6.3.0/allcodepoints.txt:2309;DISALLOWED;I;;RIGHT CEILING ../6.3.0/allcodepoints.txt:230A;DISALLOWED;I;;LEFT FLOOR ../6.3.0/allcodepoints.txt:230B;DISALLOWED;I;;RIGHT FLOOR > Can somebody check whether and how they affect IDNA 2008 and/or = precis? >=20 > Again, if that has already been done, sorry for the noise. >=20 > Regards, Martin. >=20 >=20 > P.S.: > All the other changes in UnicodeData.txt: >=20 > Change in numerical value only: >=20 > OLD > 12456;CUNEIFORM NUMERIC SIGN NIGIDAMIN;Nl;0;L;;;;-1;N;;;;; > 12457;CUNEIFORM NUMERIC SIGN NIGIDAESH;Nl;0;L;;;;-1;N;;;;; > NEW > 12456;CUNEIFORM NUMERIC SIGN NIGIDAMIN;Nl;0;L;;;;2;N;;;;; > 12457;CUNEIFORM NUMERIC SIGN NIGIDAESH;Nl;0;L;;;;3;N;;;;; $ egrep '^1245[67];' ../6.[23].0/allcodepoints.txt=20 ../6.2.0/allcodepoints.txt:12456;DISALLOWED;I;;CUNEIFORM NUMERIC SIGN = NIGIDAMIN ../6.2.0/allcodepoints.txt:12457;DISALLOWED;I;;CUNEIFORM NUMERIC SIGN = NIGIDAESH ../6.3.0/allcodepoints.txt:12456;DISALLOWED;I;;CUNEIFORM NUMERIC SIGN = NIGIDAMIN ../6.3.0/allcodepoints.txt:12457;DISALLOWED;I;;CUNEIFORM NUMERIC SIGN = NIGIDAESH > New characters (my understanding is that these are taken care of = automatically): >=20 > 061C;ARABIC LETTER MARK;Cf;0;AL;;;;;N;;;;; $ egrep '^061C;' ../6.[23].0/allcodepoints.txt=20 ../6.2.0/allcodepoints.txt:061C;UNASSIGNED;I;J; ../6.3.0/allcodepoints.txt:061C;DISALLOWED;I;C;ARABIC LETTER MARK > 2066;LEFT-TO-RIGHT ISOLATE;Cf;0;LRI;;;;;N;;;;; > 2067;RIGHT-TO-LEFT ISOLATE;Cf;0;RLI;;;;;N;;;;; > 2068;FIRST STRONG ISOLATE;Cf;0;FSI;;;;;N;;;;; > 2069;POP DIRECTIONAL ISOLATE;Cf;0;PDI;;;;;N;;;;; $ egrep '^206[6789];' ../6.[23].0/allcodepoints.txt=20 ../6.2.0/allcodepoints.txt:2066;UNASSIGNED;I;CJ; ../6.2.0/allcodepoints.txt:2067;UNASSIGNED;I;CJ; ../6.2.0/allcodepoints.txt:2068;UNASSIGNED;I;CJ; ../6.2.0/allcodepoints.txt:2069;UNASSIGNED;I;CJ; ../6.3.0/allcodepoints.txt:2066;DISALLOWED;I;C;LEFT-TO-RIGHT ISOLATE ../6.3.0/allcodepoints.txt:2067;DISALLOWED;I;C;RIGHT-TO-LEFT ISOLATE ../6.3.0/allcodepoints.txt:2068;DISALLOWED;I;C;FIRST STRONG ISOLATE ../6.3.0/allcodepoints.txt:2069;DISALLOWED;I;C;POP DIRECTIONAL ISOLATE Patrik --Apple-Mail=_07D02D0C-9749-4244-88CF-D4AB930B13A1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSXibTrMabGguI180RAkXyAKCP0DrosytMzRL5n37MGumv+xZbnQCgkLaM A227wqJ+mtDKAZwQPQOoQp0= =fuUc -----END PGP SIGNATURE----- --Apple-Mail=_07D02D0C-9749-4244-88CF-D4AB930B13A1-- From duerst@it.aoyama.ac.jp Wed Oct 16 00:05:33 2013 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 A616F21F9A65 for ; Wed, 16 Oct 2013 00:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.641 X-Spam-Level: X-Spam-Status: No, score=-104.641 tagged_above=-999 required=5 tests=[AWL=1.149, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFhdEhAX8BsW for ; Wed, 16 Oct 2013 00:05:22 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7294F11E815F for ; Wed, 16 Oct 2013 00:05:12 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r9G74rfr016625; Wed, 16 Oct 2013 16:04:54 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 2606_ba73_41c77c06_3631_11e3_93cd_001e6722eec2; Wed, 16 Oct 2013 16:04:53 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id E2F74BF521; Wed, 16 Oct 2013 16:04:52 +0900 (JST) Message-ID: <525E3A7F.9040204@it.aoyama.ac.jp> Date: Wed, 16 Oct 2013 16:04:31 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= References: <525DFB1F.8040401@it.aoyama.ac.jp> <7693B3B4-7204-48F0-8C42-EBF5D701BAF4@frobbit.se> In-Reply-To: <7693B3B4-7204-48F0-8C42-EBF5D701BAF4@frobbit.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "idna-update@alvestrand.no" , "precis@ietf.org" Subject: Re: [precis] Category changes with Unicode 6.3 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 07:05:33 -0000 Hello Patrick, Many thanks for checking. Great to see that everything is okay. Regards, Martin. On 2013/10/16 14:40, Patrik F=C3=A4ltstr=C3=B6m wrote: > Executive summary: Does not impact IDNA2008. > > Longer explanation: > > On 16 okt 2013, at 05:34, Martin J. D=C3=BCrst = wrote: > >> Excuse me if this has been checked and/or discussed already, but I jus= t downloaded the Unicode 6.3 version (officially published a few days ago= ) of http://www.unicode.org/Public/UCD/latest/ucd/UnicodeData.txt and fou= nd several changes in character classification: >> >> OLD >> 180E;MONGOLIAN VOWEL SEPARATOR;Zs;0;WS;;;;;N;;;;; >> NEW >> 180E;MONGOLIAN VOWEL SEPARATOR;Cf;0;BN;;;;;N;;;;; > > No change: > > $ grep '^180E;' ../6.[23].0/allcodepoints.txt > ../6.2.0/allcodepoints.txt:180E;DISALLOWED;I;C;MONGOLIAN VOWEL SEPARATO= R > ../6.3.0/allcodepoints.txt:180E;DISALLOWED;I;C;MONGOLIAN VOWEL SEPARATO= R > >> OLD >> 1A1B;BUGINESE VOWEL SIGN AE;Mc;0;L;;;;;N;;;;; >> NEW >> 1A1B;BUGINESE VOWEL SIGN AE;Mn;0;NSM;;;;;N;;;;; > > No change: > > $ grep '^1A1B;' ../6.[23].0/allcodepoints.txt > ../6.2.0/allcodepoints.txt:1A1B;PVALID;I;A;BUGINESE VOWEL SIGN AE > ../6.3.0/allcodepoints.txt:1A1B;PVALID;I;A;BUGINESE VOWEL SIGN AE > >> OLD >> 2308;LEFT CEILING;Sm;0;ON;;;;;Y;;;;; >> 2309;RIGHT CEILING;Sm;0;ON;;;;;Y;;;;; >> 230A;LEFT FLOOR;Sm;0;ON;;;;;Y;;;;; >> 230B;RIGHT FLOOR;Sm;0;ON;;;;;Y;;;;; >> NEW >> 2308;LEFT CEILING;Ps;0;ON;;;;;Y;;;;; >> 2309;RIGHT CEILING;Pe;0;ON;;;;;Y;;;;; >> 230A;LEFT FLOOR;Ps;0;ON;;;;;Y;;;;; >> 230B;RIGHT FLOOR;Pe;0;ON;;;;;Y;;;;; > > No change: > > $ egrep '^230[89AB];' ../6.[23].0/allcodepoints.txt > ../6.2.0/allcodepoints.txt:2308;DISALLOWED;I;;LEFT CEILING > ../6.2.0/allcodepoints.txt:2309;DISALLOWED;I;;RIGHT CEILING > ../6.2.0/allcodepoints.txt:230A;DISALLOWED;I;;LEFT FLOOR > ../6.2.0/allcodepoints.txt:230B;DISALLOWED;I;;RIGHT FLOOR > ../6.3.0/allcodepoints.txt:2308;DISALLOWED;I;;LEFT CEILING > ../6.3.0/allcodepoints.txt:2309;DISALLOWED;I;;RIGHT CEILING > ../6.3.0/allcodepoints.txt:230A;DISALLOWED;I;;LEFT FLOOR > ../6.3.0/allcodepoints.txt:230B;DISALLOWED;I;;RIGHT FLOOR > >> Can somebody check whether and how they affect IDNA 2008 and/or precis= ? >> >> Again, if that has already been done, sorry for the noise. >> >> Regards, Martin. >> >> >> P.S.: >> All the other changes in UnicodeData.txt: >> >> Change in numerical value only: >> >> OLD >> 12456;CUNEIFORM NUMERIC SIGN NIGIDAMIN;Nl;0;L;;;;-1;N;;;;; >> 12457;CUNEIFORM NUMERIC SIGN NIGIDAESH;Nl;0;L;;;;-1;N;;;;; >> NEW >> 12456;CUNEIFORM NUMERIC SIGN NIGIDAMIN;Nl;0;L;;;;2;N;;;;; >> 12457;CUNEIFORM NUMERIC SIGN NIGIDAESH;Nl;0;L;;;;3;N;;;;; > > $ egrep '^1245[67];' ../6.[23].0/allcodepoints.txt > ../6.2.0/allcodepoints.txt:12456;DISALLOWED;I;;CUNEIFORM NUMERIC SIGN N= IGIDAMIN > ../6.2.0/allcodepoints.txt:12457;DISALLOWED;I;;CUNEIFORM NUMERIC SIGN N= IGIDAESH > ../6.3.0/allcodepoints.txt:12456;DISALLOWED;I;;CUNEIFORM NUMERIC SIGN N= IGIDAMIN > ../6.3.0/allcodepoints.txt:12457;DISALLOWED;I;;CUNEIFORM NUMERIC SIGN N= IGIDAESH > >> New characters (my understanding is that these are taken care of autom= atically): >> >> 061C;ARABIC LETTER MARK;Cf;0;AL;;;;;N;;;;; > > $ egrep '^061C;' ../6.[23].0/allcodepoints.txt > ../6.2.0/allcodepoints.txt:061C;UNASSIGNED;I;J; > ../6.3.0/allcodepoints.txt:061C;DISALLOWED;I;C;ARABIC LETTER MARK > >> 2066;LEFT-TO-RIGHT ISOLATE;Cf;0;LRI;;;;;N;;;;; >> 2067;RIGHT-TO-LEFT ISOLATE;Cf;0;RLI;;;;;N;;;;; >> 2068;FIRST STRONG ISOLATE;Cf;0;FSI;;;;;N;;;;; >> 2069;POP DIRECTIONAL ISOLATE;Cf;0;PDI;;;;;N;;;;; > > $ egrep '^206[6789];' ../6.[23].0/allcodepoints.txt > ../6.2.0/allcodepoints.txt:2066;UNASSIGNED;I;CJ; > ../6.2.0/allcodepoints.txt:2067;UNASSIGNED;I;CJ; > ../6.2.0/allcodepoints.txt:2068;UNASSIGNED;I;CJ; > ../6.2.0/allcodepoints.txt:2069;UNASSIGNED;I;CJ; > ../6.3.0/allcodepoints.txt:2066;DISALLOWED;I;C;LEFT-TO-RIGHT ISOLATE > ../6.3.0/allcodepoints.txt:2067;DISALLOWED;I;C;RIGHT-TO-LEFT ISOLATE > ../6.3.0/allcodepoints.txt:2068;DISALLOWED;I;C;FIRST STRONG ISOLATE > ../6.3.0/allcodepoints.txt:2069;DISALLOWED;I;C;POP DIRECTIONAL ISOLATE > > Patrik > From paf@frobbit.se Wed Oct 16 00:16:17 2013 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 F291921F9D5E for ; Wed, 16 Oct 2013 00:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmBT6DwZF03W for ; Wed, 16 Oct 2013 00:16:15 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF7A21F9D9A for ; Wed, 16 Oct 2013 00:16:10 -0700 (PDT) Received: from [IPv6:2001:67c:64:42:d997:fadd:90f:58bd] (unknown [IPv6:2001:67c:64:42:d997:fadd:90f:58bd]) by mail.frobbit.se (Postfix) with ESMTPSA id 70EDB219C6; Wed, 16 Oct 2013 09:16:09 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_C3314DB8-C154-4A26-A1EE-0E1672E12B35"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <525E3A7F.9040204@it.aoyama.ac.jp> Date: Wed, 16 Oct 2013 10:16:08 +0300 Message-Id: References: <525DFB1F.8040401@it.aoyama.ac.jp> <7693B3B4-7204-48F0-8C42-EBF5D701BAF4@frobbit.se> <525E3A7F.9040204@it.aoyama.ac.jp> To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= X-Mailer: Apple Mail (2.1510) Cc: "idna-update@alvestrand.no" , "precis@ietf.org" Subject: Re: [precis] Category changes with Unicode 6.3 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 07:16:17 -0000 --Apple-Mail=_C3314DB8-C154-4A26-A1EE-0E1672E12B35 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Yeah, I had to do it anyways -- as I am expert reviewer of the IANA = tables. New versions of the IANA tables where created by IANA the other = day, and I just approved them as they match my own calculations. I.e. we = have two completely independent implementations of IDNA2008 (one at = IANA, one that I have -- see link below) and I compare the output of the = two. If the output matches, then we are pretty sure we are correct. Patrik On 16 okt 2013, at 10:04, "Martin J. D=FCrst" = wrote: > Hello Patrick, >=20 > Many thanks for checking. Great to see that everything is okay. >=20 > Regards, Martin. >=20 > On 2013/10/16 14:40, Patrik F=E4ltstr=F6m wrote: >> Executive summary: Does not impact IDNA2008. >>=20 >> Longer explanation: >>=20 >> On 16 okt 2013, at 05:34, Martin J. D=FCrst = wrote: >>=20 >>> Excuse me if this has been checked and/or discussed already, but I = just downloaded the Unicode 6.3 version (officially published a few days = ago) of http://www.unicode.org/Public/UCD/latest/ucd/UnicodeData.txt and = found several changes in character classification: >>>=20 >>> OLD >>> 180E;MONGOLIAN VOWEL SEPARATOR;Zs;0;WS;;;;;N;;;;; >>> NEW >>> 180E;MONGOLIAN VOWEL SEPARATOR;Cf;0;BN;;;;;N;;;;; >>=20 >> No change: >>=20 >> $ grep '^180E;' ../6.[23].0/allcodepoints.txt >> ../6.2.0/allcodepoints.txt:180E;DISALLOWED;I;C;MONGOLIAN VOWEL = SEPARATOR >> ../6.3.0/allcodepoints.txt:180E;DISALLOWED;I;C;MONGOLIAN VOWEL = SEPARATOR >>=20 >>> OLD >>> 1A1B;BUGINESE VOWEL SIGN AE;Mc;0;L;;;;;N;;;;; >>> NEW >>> 1A1B;BUGINESE VOWEL SIGN AE;Mn;0;NSM;;;;;N;;;;; >>=20 >> No change: >>=20 >> $ grep '^1A1B;' ../6.[23].0/allcodepoints.txt >> ../6.2.0/allcodepoints.txt:1A1B;PVALID;I;A;BUGINESE VOWEL SIGN AE >> ../6.3.0/allcodepoints.txt:1A1B;PVALID;I;A;BUGINESE VOWEL SIGN AE >>=20 >>> OLD >>> 2308;LEFT CEILING;Sm;0;ON;;;;;Y;;;;; >>> 2309;RIGHT CEILING;Sm;0;ON;;;;;Y;;;;; >>> 230A;LEFT FLOOR;Sm;0;ON;;;;;Y;;;;; >>> 230B;RIGHT FLOOR;Sm;0;ON;;;;;Y;;;;; >>> NEW >>> 2308;LEFT CEILING;Ps;0;ON;;;;;Y;;;;; >>> 2309;RIGHT CEILING;Pe;0;ON;;;;;Y;;;;; >>> 230A;LEFT FLOOR;Ps;0;ON;;;;;Y;;;;; >>> 230B;RIGHT FLOOR;Pe;0;ON;;;;;Y;;;;; >>=20 >> No change: >>=20 >> $ egrep '^230[89AB];' ../6.[23].0/allcodepoints.txt >> ../6.2.0/allcodepoints.txt:2308;DISALLOWED;I;;LEFT CEILING >> ../6.2.0/allcodepoints.txt:2309;DISALLOWED;I;;RIGHT CEILING >> ../6.2.0/allcodepoints.txt:230A;DISALLOWED;I;;LEFT FLOOR >> ../6.2.0/allcodepoints.txt:230B;DISALLOWED;I;;RIGHT FLOOR >> ../6.3.0/allcodepoints.txt:2308;DISALLOWED;I;;LEFT CEILING >> ../6.3.0/allcodepoints.txt:2309;DISALLOWED;I;;RIGHT CEILING >> ../6.3.0/allcodepoints.txt:230A;DISALLOWED;I;;LEFT FLOOR >> ../6.3.0/allcodepoints.txt:230B;DISALLOWED;I;;RIGHT FLOOR >>=20 >>> Can somebody check whether and how they affect IDNA 2008 and/or = precis? >>>=20 >>> Again, if that has already been done, sorry for the noise. >>>=20 >>> Regards, Martin. >>>=20 >>>=20 >>> P.S.: >>> All the other changes in UnicodeData.txt: >>>=20 >>> Change in numerical value only: >>>=20 >>> OLD >>> 12456;CUNEIFORM NUMERIC SIGN NIGIDAMIN;Nl;0;L;;;;-1;N;;;;; >>> 12457;CUNEIFORM NUMERIC SIGN NIGIDAESH;Nl;0;L;;;;-1;N;;;;; >>> NEW >>> 12456;CUNEIFORM NUMERIC SIGN NIGIDAMIN;Nl;0;L;;;;2;N;;;;; >>> 12457;CUNEIFORM NUMERIC SIGN NIGIDAESH;Nl;0;L;;;;3;N;;;;; >>=20 >> $ egrep '^1245[67];' ../6.[23].0/allcodepoints.txt >> ../6.2.0/allcodepoints.txt:12456;DISALLOWED;I;;CUNEIFORM NUMERIC SIGN = NIGIDAMIN >> ../6.2.0/allcodepoints.txt:12457;DISALLOWED;I;;CUNEIFORM NUMERIC SIGN = NIGIDAESH >> ../6.3.0/allcodepoints.txt:12456;DISALLOWED;I;;CUNEIFORM NUMERIC SIGN = NIGIDAMIN >> ../6.3.0/allcodepoints.txt:12457;DISALLOWED;I;;CUNEIFORM NUMERIC SIGN = NIGIDAESH >>=20 >>> New characters (my understanding is that these are taken care of = automatically): >>>=20 >>> 061C;ARABIC LETTER MARK;Cf;0;AL;;;;;N;;;;; >>=20 >> $ egrep '^061C;' ../6.[23].0/allcodepoints.txt >> ../6.2.0/allcodepoints.txt:061C;UNASSIGNED;I;J; >> ../6.3.0/allcodepoints.txt:061C;DISALLOWED;I;C;ARABIC LETTER MARK >>=20 >>> 2066;LEFT-TO-RIGHT ISOLATE;Cf;0;LRI;;;;;N;;;;; >>> 2067;RIGHT-TO-LEFT ISOLATE;Cf;0;RLI;;;;;N;;;;; >>> 2068;FIRST STRONG ISOLATE;Cf;0;FSI;;;;;N;;;;; >>> 2069;POP DIRECTIONAL ISOLATE;Cf;0;PDI;;;;;N;;;;; >>=20 >> $ egrep '^206[6789];' ../6.[23].0/allcodepoints.txt >> ../6.2.0/allcodepoints.txt:2066;UNASSIGNED;I;CJ; >> ../6.2.0/allcodepoints.txt:2067;UNASSIGNED;I;CJ; >> ../6.2.0/allcodepoints.txt:2068;UNASSIGNED;I;CJ; >> ../6.2.0/allcodepoints.txt:2069;UNASSIGNED;I;CJ; >> ../6.3.0/allcodepoints.txt:2066;DISALLOWED;I;C;LEFT-TO-RIGHT ISOLATE >> ../6.3.0/allcodepoints.txt:2067;DISALLOWED;I;C;RIGHT-TO-LEFT ISOLATE >> ../6.3.0/allcodepoints.txt:2068;DISALLOWED;I;C;FIRST STRONG ISOLATE >> ../6.3.0/allcodepoints.txt:2069;DISALLOWED;I;C;POP DIRECTIONAL = ISOLATE >>=20 >> Patrik >>=20 > _______________________________________________ > Idna-update mailing list > Idna-update@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/idna-update --Apple-Mail=_C3314DB8-C154-4A26-A1EE-0E1672E12B35 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSXj04rMabGguI180RAh9+AKCRX+DA3iA22E4vpZ27IlPbQHsywQCffJEK 5QESlqR0uh2fq29E3kZqo9Q= =GVy9 -----END PGP SIGNATURE----- --Apple-Mail=_C3314DB8-C154-4A26-A1EE-0E1672E12B35-- From mark.edward.davis@gmail.com Wed Oct 16 00:50:14 2013 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 6253911E8115 for ; Wed, 16 Oct 2013 00:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.793 X-Spam-Level: X-Spam-Status: No, score=-2.793 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EYAEhkyH7Qg for ; Wed, 16 Oct 2013 00:50:13 -0700 (PDT) Received: from mail-qe0-x22a.google.com (mail-qe0-x22a.google.com [IPv6:2607:f8b0:400d:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 596FB11E81B3 for ; Wed, 16 Oct 2013 00:50:05 -0700 (PDT) Received: by mail-qe0-f42.google.com with SMTP id gc15so307776qeb.1 for ; Wed, 16 Oct 2013 00:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=9V5qDNXY1PM8VawCT++Dg3U/i3ubBYF9+MS1SehVQho=; b=RwzibIQ8XS/NcGS1iIeSMbZM+yKFmntCmyvfwW+qIkErzAB59V4Ir9i/Fh/wBsJgUf FSNNM7/cpkgxTm/r2aulx8yccrGoPIc4cl8vA9nG09qL3C5BNl2dOWvi7mYaKqvj8ak3 7zPqp4bP2BZtVQ1/T/CYtWrBXMssCBYBwKimx3123z3TrJaNEfM+6bf1/+BkIEQt0KuV IzAToldF3kZDwXyfzqfFObU/hN4MICLQVQbII3laws2JzHxwiQrOPxNzMaVkxfKbmKS2 REhEM82KpPuwbSeumRU9vSlMfq+2WYb6n/8YF/uVpZLYcMdWIVeJ6RTPUT2Z1VzkhV+6 p2ig== MIME-Version: 1.0 X-Received: by 10.49.29.230 with SMTP id n6mr1861802qeh.20.1381909804801; Wed, 16 Oct 2013 00:50:04 -0700 (PDT) Sender: mark.edward.davis@gmail.com Received: by 10.96.214.98 with HTTP; Wed, 16 Oct 2013 00:50:04 -0700 (PDT) In-Reply-To: <7693B3B4-7204-48F0-8C42-EBF5D701BAF4@frobbit.se> References: <525DFB1F.8040401@it.aoyama.ac.jp> <7693B3B4-7204-48F0-8C42-EBF5D701BAF4@frobbit.se> Date: Wed, 16 Oct 2013 09:50:04 +0200 X-Google-Sender-Auth: UTvNGsaikhYTr6c9nRd-CFHVfZE Message-ID: From: =?UTF-8?B?TWFyayBEYXZpcyDimJU=?= To: =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= Content-Type: multipart/alternative; boundary=047d7bdc7a6406e62204e8d6f32e X-Mailman-Approved-At: Wed, 16 Oct 2013 01:33:10 -0700 Cc: "idna-update@alvestrand.no" , "precis@ietf.org" Subject: Re: [precis] Category changes with Unicode 6.3 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 07:50:14 -0000 --047d7bdc7a6406e62204e8d6f32e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FYI: We are considering a change in UTS46 ( http://www.unicode.org/reports/tr46/proposed.html) for the new Bidi_Controls. However, this does *not* affect IDNA2008. Mark * * *=E2=80=94 Il meglio =C3=A8 l=E2=80=99inimico del bene =E2=80=94* ** On Wed, Oct 16, 2013 at 7:40 AM, Patrik F=C3=A4ltstr=C3=B6m wrote: > Executive summary: Does not impact IDNA2008. > > Longer explanation: > > On 16 okt 2013, at 05:34, Martin J. D=C3=BCrst w= rote: > > > Excuse me if this has been checked and/or discussed already, but I just > downloaded the Unicode 6.3 version (officially published a few days ago) = of > http://www.unicode.org/Public/UCD/latest/ucd/UnicodeData.txt and found > several changes in character classification: > > > > OLD > > 180E;MONGOLIAN VOWEL SEPARATOR;Zs;0;WS;;;;;N;;;;; > > NEW > > 180E;MONGOLIAN VOWEL SEPARATOR;Cf;0;BN;;;;;N;;;;; > > No change: > > $ grep '^180E;' ../6.[23].0/allcodepoints.txt > ../6.2.0/allcodepoints.txt:180E;DISALLOWED;I;C;MONGOLIAN VOWEL SEPARATOR > ../6.3.0/allcodepoints.txt:180E;DISALLOWED;I;C;MONGOLIAN VOWEL SEPARATOR > > > OLD > > 1A1B;BUGINESE VOWEL SIGN AE;Mc;0;L;;;;;N;;;;; > > NEW > > 1A1B;BUGINESE VOWEL SIGN AE;Mn;0;NSM;;;;;N;;;;; > > No change: > > $ grep '^1A1B;' ../6.[23].0/allcodepoints.txt > ../6.2.0/allcodepoints.txt:1A1B;PVALID;I;A;BUGINESE VOWEL SIGN AE > ../6.3.0/allcodepoints.txt:1A1B;PVALID;I;A;BUGINESE VOWEL SIGN AE > > > OLD > > 2308;LEFT CEILING;Sm;0;ON;;;;;Y;;;;; > > 2309;RIGHT CEILING;Sm;0;ON;;;;;Y;;;;; > > 230A;LEFT FLOOR;Sm;0;ON;;;;;Y;;;;; > > 230B;RIGHT FLOOR;Sm;0;ON;;;;;Y;;;;; > > NEW > > 2308;LEFT CEILING;Ps;0;ON;;;;;Y;;;;; > > 2309;RIGHT CEILING;Pe;0;ON;;;;;Y;;;;; > > 230A;LEFT FLOOR;Ps;0;ON;;;;;Y;;;;; > > 230B;RIGHT FLOOR;Pe;0;ON;;;;;Y;;;;; > > No change: > > $ egrep '^230[89AB];' ../6.[23].0/allcodepoints.txt > ../6.2.0/allcodepoints.txt:2308;DISALLOWED;I;;LEFT CEILING > ../6.2.0/allcodepoints.txt:2309;DISALLOWED;I;;RIGHT CEILING > ../6.2.0/allcodepoints.txt:230A;DISALLOWED;I;;LEFT FLOOR > ../6.2.0/allcodepoints.txt:230B;DISALLOWED;I;;RIGHT FLOOR > ../6.3.0/allcodepoints.txt:2308;DISALLOWED;I;;LEFT CEILING > ../6.3.0/allcodepoints.txt:2309;DISALLOWED;I;;RIGHT CEILING > ../6.3.0/allcodepoints.txt:230A;DISALLOWED;I;;LEFT FLOOR > ../6.3.0/allcodepoints.txt:230B;DISALLOWED;I;;RIGHT FLOOR > > > Can somebody check whether and how they affect IDNA 2008 and/or precis? > > > > Again, if that has already been done, sorry for the noise. > > > > Regards, Martin. > > > > > > P.S.: > > All the other changes in UnicodeData.txt: > > > > Change in numerical value only: > > > > OLD > > 12456;CUNEIFORM NUMERIC SIGN NIGIDAMIN;Nl;0;L;;;;-1;N;;;;; > > 12457;CUNEIFORM NUMERIC SIGN NIGIDAESH;Nl;0;L;;;;-1;N;;;;; > > NEW > > 12456;CUNEIFORM NUMERIC SIGN NIGIDAMIN;Nl;0;L;;;;2;N;;;;; > > 12457;CUNEIFORM NUMERIC SIGN NIGIDAESH;Nl;0;L;;;;3;N;;;;; > > $ egrep '^1245[67];' ../6.[23].0/allcodepoints.txt > ../6.2.0/allcodepoints.txt:12456;DISALLOWED;I;;CUNEIFORM NUMERIC SIGN > NIGIDAMIN > ../6.2.0/allcodepoints.txt:12457;DISALLOWED;I;;CUNEIFORM NUMERIC SIGN > NIGIDAESH > ../6.3.0/allcodepoints.txt:12456;DISALLOWED;I;;CUNEIFORM NUMERIC SIGN > NIGIDAMIN > ../6.3.0/allcodepoints.txt:12457;DISALLOWED;I;;CUNEIFORM NUMERIC SIGN > NIGIDAESH > > > New characters (my understanding is that these are taken care of > automatically): > > > > 061C;ARABIC LETTER MARK;Cf;0;AL;;;;;N;;;;; > > $ egrep '^061C;' ../6.[23].0/allcodepoints.txt > ../6.2.0/allcodepoints.txt:061C;UNASSIGNED;I;J; > ../6.3.0/allcodepoints.txt:061C;DISALLOWED;I;C;ARABIC LETTER MARK > > > 2066;LEFT-TO-RIGHT ISOLATE;Cf;0;LRI;;;;;N;;;;; > > 2067;RIGHT-TO-LEFT ISOLATE;Cf;0;RLI;;;;;N;;;;; > > 2068;FIRST STRONG ISOLATE;Cf;0;FSI;;;;;N;;;;; > > 2069;POP DIRECTIONAL ISOLATE;Cf;0;PDI;;;;;N;;;;; > > $ egrep '^206[6789];' ../6.[23].0/allcodepoints.txt > ../6.2.0/allcodepoints.txt:2066;UNASSIGNED;I;CJ; > ../6.2.0/allcodepoints.txt:2067;UNASSIGNED;I;CJ; > ../6.2.0/allcodepoints.txt:2068;UNASSIGNED;I;CJ; > ../6.2.0/allcodepoints.txt:2069;UNASSIGNED;I;CJ; > ../6.3.0/allcodepoints.txt:2066;DISALLOWED;I;C;LEFT-TO-RIGHT ISOLATE > ../6.3.0/allcodepoints.txt:2067;DISALLOWED;I;C;RIGHT-TO-LEFT ISOLATE > ../6.3.0/allcodepoints.txt:2068;DISALLOWED;I;C;FIRST STRONG ISOLATE > ../6.3.0/allcodepoints.txt:2069;DISALLOWED;I;C;POP DIRECTIONAL ISOLATE > > Patrik > > > _______________________________________________ > Idna-update mailing list > Idna-update@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/idna-update > > --047d7bdc7a6406e62204e8d6f32e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI: We are considering a change in UTS46 (http://www.unicode.o= rg/reports/tr46/proposed.html) for the new Bidi_Controls. However, this= does not affect IDNA2008.

=


=E2=80=94 Il meglio =C3=A8 l=E2=80=99inimico del bene =E2=80=94


On Wed, Oct 16, 2013 at 7:40 AM, Patrik = F=C3=A4ltstr=C3=B6m <paf@frobbit.se> wrote:
Executive summary: Does not impact IDNA2008.

Longer explanation:

On 16 okt 2013, at 05:34, Martin J. D=C3=BCrst <duerst@it.aoyama.ac.jp> wrote:

> Excuse me if this has been checked and/or disc= ussed already, but I just downloaded the Unicode 6.3 version (officially pu= blished a few days ago) of http://www.unicode.org/Public/UC= D/latest/ucd/UnicodeData.txt and found several changes in character cla= ssification:
>
> OLD
> 180E;MONGOLIAN VOWEL SEPARATOR;Zs;0;WS;;;;;N;;;;;
> NEW
> 180E;MONGOLIAN VOWEL SEPARATOR;Cf;0;BN;;;;;N;;;;;

No change:

$ grep '^180E;' ../6.[23].0/allcodepoints.txt
../6.2.0/allcodepoints.txt:180E;DISALLOWED;I;C;MONGOLIAN VOWEL SEPARATOR ../6.3.0/allcodepoints.txt:180E;DISALLOWED;I;C;MONGOLIAN VOWEL SEPARATOR

> OLD
> 1A1B;BUGINESE VOWEL SIGN AE;Mc;0;L;;;;;N;;;;;
> NEW
> 1A1B;BUGINESE VOWEL SIGN AE;Mn;0;NSM;;;;;N;;;;;

No change:

$ grep '^1A1B;' ../6.[23].0/allcodepoints.txt
../6.2.0/allcodepoints.txt:1A1B;PVALID;I;A;BUGINESE VOWEL SIGN AE
../6.3.0/allcodepoints.txt:1A1B;PVALID;I;A;BUGINESE VOWEL SIGN AE

> OLD
> 2308;LEFT CEILING;Sm;0;ON;;;;;Y;;;;;
> 2309;RIGHT CEILING;Sm;0;ON;;;;;Y;;;;;
> 230A;LEFT FLOOR;Sm;0;ON;;;;;Y;;;;;
> 230B;RIGHT FLOOR;Sm;0;ON;;;;;Y;;;;;
> NEW
> 2308;LEFT CEILING;Ps;0;ON;;;;;Y;;;;;
> 2309;RIGHT CEILING;Pe;0;ON;;;;;Y;;;;;
> 230A;LEFT FLOOR;Ps;0;ON;;;;;Y;;;;;
> 230B;RIGHT FLOOR;Pe;0;ON;;;;;Y;;;;;

No change:

$ egrep '^230[89AB];' ../6.[23].0/allcodepoints.txt
../6.2.0/allcodepoints.txt:2308;DISALLOWED;I;;LEFT CEILING
../6.2.0/allcodepoints.txt:2309;DISALLOWED;I;;RIGHT CEILING
../6.2.0/allcodepoints.txt:230A;DISALLOWED;I;;LEFT FLOOR
../6.2.0/allcodepoints.txt:230B;DISALLOWED;I;;RIGHT FLOOR
../6.3.0/allcodepoints.txt:2308;DISALLOWED;I;;LEFT CEILING
../6.3.0/allcodepoints.txt:2309;DISALLOWED;I;;RIGHT CEILING
../6.3.0/allcodepoints.txt:230A;DISALLOWED;I;;LEFT FLOOR
../6.3.0/allcodepoints.txt:230B;DISALLOWED;I;;RIGHT FLOOR

> Can somebody check whether and how they affect IDNA 2008 and/or precis= ?
>
> Again, if that has already been done, sorry for the noise.
>
> Regards, =C2=A0 Martin.
>
>
> P.S.:
> All the other changes in UnicodeData.txt:
>
> Change in numerical value only:
>
> OLD
> 12456;CUNEIFORM NUMERIC SIGN NIGIDAMIN;Nl;0;L;;;;-1;N;;;;;
> 12457;CUNEIFORM NUMERIC SIGN NIGIDAESH;Nl;0;L;;;;-1;N;;;;;
> NEW
> 12456;CUNEIFORM NUMERIC SIGN NIGIDAMIN;Nl;0;L;;;;2;N;;;;;
> 12457;CUNEIFORM NUMERIC SIGN NIGIDAESH;Nl;0;L;;;;3;N;;;;;

$ egrep '^1245[67];' ../6.[23].0/allcodepoints.txt
../6.2.0/allcodepoints.txt:12456;DISALLOWED;I;;CUNEIFORM NUMERIC SIGN NIGID= AMIN
../6.2.0/allcodepoints.txt:12457;DISALLOWED;I;;CUNEIFORM NUMERIC SIGN NIGID= AESH
../6.3.0/allcodepoints.txt:12456;DISALLOWED;I;;CUNEIFORM NUMERIC SIGN NIGID= AMIN
../6.3.0/allcodepoints.txt:12457;DISALLOWED;I;;CUNEIFORM NUMERIC SIGN NIGID= AESH

> New characters (my understanding is that these are taken care of autom= atically):
>
> 061C;ARABIC LETTER MARK;Cf;0;AL;;;;;N;;;;;

$ egrep '^061C;' ../6.[23].0/allcodepoints.txt
../6.2.0/allcodepoints.txt:061C;UNASSIGNED;I;J;<reserved>
../6.3.0/allcodepoints.txt:061C;DISALLOWED;I;C;ARABIC LETTER MARK

> 2066;LEFT-TO-RIGHT ISOLATE;Cf;0;LRI;;;;;N;;;;;
> 2067;RIGHT-TO-LEFT ISOLATE;Cf;0;RLI;;;;;N;;;;;
> 2068;FIRST STRONG ISOLATE;Cf;0;FSI;;;;;N;;;;;
> 2069;POP DIRECTIONAL ISOLATE;Cf;0;PDI;;;;;N;;;;;

$ egrep '^206[6789];' ../6.[23].0/allcodepoints.txt
../6.2.0/allcodepoints.txt:2066;UNASSIGNED;I;CJ;<reserved>
../6.2.0/allcodepoints.txt:2067;UNASSIGNED;I;CJ;<reserved>
../6.2.0/allcodepoints.txt:2068;UNASSIGNED;I;CJ;<reserved>
../6.2.0/allcodepoints.txt:2069;UNASSIGNED;I;CJ;<reserved>
../6.3.0/allcodepoints.txt:2066;DISALLOWED;I;C;LEFT-TO-RIGHT ISOLATE
../6.3.0/allcodepoints.txt:2067;DISALLOWED;I;C;RIGHT-TO-LEFT ISOLATE
../6.3.0/allcodepoints.txt:2068;DISALLOWED;I;C;FIRST STRONG ISOLATE
../6.3.0/allcodepoints.txt:2069;DISALLOWED;I;C;POP DIRECTIONAL ISOLATE

=C2=A0 =C2=A0Patrik


_______________________________________________
Idna-update mailing list
Idna-update@alvestrand.no<= br> http://www.alvestrand.no/mailman/listinfo/idna-update


--047d7bdc7a6406e62204e8d6f32e-- From florob@babelmonkeys.de Wed Oct 16 04:32:35 2013 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 7BC6A11E8193 for ; Wed, 16 Oct 2013 04:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtgBHU1hSpbE for ; Wed, 16 Oct 2013 04:32:35 -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 0909D11E81BB for ; Wed, 16 Oct 2013 04:32:32 -0700 (PDT) Received: from [134.130.62.162] by babelmonkeys.de with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1VWPN4-0007Pf-0W; Wed, 16 Oct 2013 13:34:34 +0200 Message-ID: <525E794E.6000509@babelmonkeys.de> Date: Wed, 16 Oct 2013 13:32:30 +0200 From: Florian Zeitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Peter Saint-Andre , precis@ietf.org References: <20131015222642.2154.19165.idtracker@ietfa.amsl.com> <525DC728.2090002@stpeter.im> In-Reply-To: <525DC728.2090002@stpeter.im> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [precis] I-D Action: draft-ietf-precis-framework-10.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 11:32:35 -0000 Am 16.10.2013 00:52, schrieb Peter Saint-Andre: > On 10/15/13 4:26 PM, internet-drafts@ietf.org wrote: > >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-precis-framework >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-precis-framework-10 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-framework-10 > > Reviews of -10 or the diff would be helpful. I plan to check them both > to make sure that I've accurately addressed all of the last call feedback. > > Thanks! > > Peter > I've had a quick look at the diff, and some areas I felt I should look at again. I'm generally very happy about the outcome. Thank you for your hard work. Some minor comments: Sections 3.2.2 and 3.3.2 say «Certain characters from the Exceptions ("F")». That's a bit awkward as a reader. A forward reference to section 7.6, noting they are explicitly listed there would help. In Section 4.1.3 about case mapping we currently have: «In general, the combination of case preservation and case-insensitive comparison of internationalized strings is NOT RECOMMENDED; instead, application protocols SHOULD either (a) not preserve case but perform case-insensitive comparison or (b) preserve case but perform case-sensitive comparison.» I wonder what the rational for this is? Both SASLprep-bis and Nicknames seem to want case-preservation, but case-insensitive comparison. I may be mistaken though. In Section 10.5 "Visually Similar Characters" I'd suggest a reference to UTS #39, describing confusable detection and mixed-script detection. Regards, Florian From paf@frobbit.se Wed Oct 16 06:49:29 2013 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 B1F9011E82B0 for ; Wed, 16 Oct 2013 06:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.765 X-Spam-Level: X-Spam-Status: No, score=-1.765 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpkCE982salP for ; Wed, 16 Oct 2013 06:49:28 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 4749011E8132 for ; Wed, 16 Oct 2013 06:49:24 -0700 (PDT) Received: from dhcp-24-112.ripemtg.ripe.net (dhcp-24-112.ripemtg.ripe.net [193.0.24.112]) by mail.frobbit.se (Postfix) with ESMTPSA id 651882405E; Wed, 16 Oct 2013 15:49:10 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_DB932989-032C-426C-AB1C-BDF232D1D232"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <11194FD50DDFBDB190254386@JcK-HP8200.jck.com> Date: Wed, 16 Oct 2013 16:49:09 +0300 Message-Id: References: <525DFB1F.8040401@it.aoyama.ac.jp> <7693B3B4-7204-48F0-8C42-EBF5D701BAF4@frobbit.se> <525E3A7F.9040204@it.aoyama.ac.jp> <11194FD50DDFBDB190254386@JcK-HP8200.jck.com> To: John C Klensin X-Mailer: Apple Mail (2.1510) Cc: idna-update@alvestrand.no, precis@ietf.org Subject: Re: [precis] Category changes with Unicode 6.3 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 13:49:30 -0000 --Apple-Mail=_DB932989-032C-426C-AB1C-BDF232D1D232 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 16 okt 2013, at 16:46, John C Klensin wrote: > This is great. To a considerable extent, it reinforces the > utility and importance of the IDNA2008 approach. Absolutely! Having the original IDNA locked with one version of Unicode is so weird = I ask myself quite often how I could come up with that idea :-P Patrik --Apple-Mail=_DB932989-032C-426C-AB1C-BDF232D1D232 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSXplVrMabGguI180RAnutAKCAI0F6xi/BjhQ5FEiF3Wn5NCEudgCeOvbD 8XD/s62wf2rm7YPXDvyGYwY= =y0CH -----END PGP SIGNATURE----- --Apple-Mail=_DB932989-032C-426C-AB1C-BDF232D1D232-- From klensin@jck.com Wed Oct 16 06:47:07 2013 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 B61AB11E81D1 for ; Wed, 16 Oct 2013 06:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.285 X-Spam-Level: X-Spam-Status: No, score=-3.285 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Him+5Bykkwf for ; Wed, 16 Oct 2013 06:47:02 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id D8BB921F9E98 for ; Wed, 16 Oct 2013 06:47:01 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1VWRRA-0000PF-HR; Wed, 16 Oct 2013 09:46:56 -0400 Date: Wed, 16 Oct 2013 09:46:51 -0400 From: John C Klensin To: =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= , =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= Message-ID: <11194FD50DDFBDB190254386@JcK-HP8200.jck.com> In-Reply-To: References: <525DFB1F.8040401@it.aoyama.ac.jp> <7693B3B4-7204-48F0-8C42-EBF5D701BAF4@frobbit.se> <525E3A7F.9040204@it.aoyama.ac.jp> 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-Mailman-Approved-At: Wed, 16 Oct 2013 07:06:19 -0700 Cc: idna-update@alvestrand.no, precis@ietf.org Subject: Re: [precis] Category changes with Unicode 6.3 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 13:47:07 -0000 --On Wednesday, October 16, 2013 10:16 +0300 Patrik = F=C3=A4ltstr=C3=B6m wrote: > Yeah, I had to do it anyways -- as I am expert reviewer of the > IANA tables. New versions of the IANA tables where created by > IANA the other day, and I just approved them as they match my > own calculations. I.e. we have two completely independent > implementations of IDNA2008 (one at IANA, one that I have -- > see link below) and I compare the output of the two. If the > output matches, then we are pretty sure we are correct. This is great. To a considerable extent, it reinforces the utility and importance of the IDNA2008 approach. YOu (and IANA) reapply the rules to a new version of Unicode, verify that nothing significant has changed and your results are the same, and we move on. In addition, because mapping is defined on top of those rules and the collection of allowable code points they create, we don't end up with different profiles for different domains or applications. It remains to be seen whether the PRECIS approach will work as well. On the one hand, generation rules have replaced the normative Stringprep table. On the other, that system leads, not to a definitive list but to string classes that are then profiled, potentially on an application-by-application or even implementation-by-implementation basis, to yield actual practices. Different behavior in different applications may be inevitable but it is certain that it will confuse at least some users. And, because different profiles will address different parts of the basic PRECIS code space, it is possible that the same evaluations that are run against the generation rules for IDNA (and exceptional adjustments added if needed) will need to be performed for each profile, resulting in temporal instability. Perhaps it will all work out and the profiles will be completely stable, but it is hard to be completely confident about that. best, john From stpeter@stpeter.im Wed Oct 16 10:43:58 2013 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 1817B11E82F3 for ; Wed, 16 Oct 2013 10:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfubsJbMv0dr for ; Wed, 16 Oct 2013 10:43:53 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A8AA211E82C3 for ; Wed, 16 Oct 2013 10:43:44 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D750B40FA9; Wed, 16 Oct 2013 11:50:04 -0600 (MDT) Message-ID: <525ED04E.7030605@stpeter.im> Date: Wed, 16 Oct 2013 11:43:42 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Florian Zeitz References: <20131015222642.2154.19165.idtracker@ietfa.amsl.com> <525DC728.2090002@stpeter.im> <525E794E.6000509@babelmonkeys.de> In-Reply-To: <525E794E.6000509@babelmonkeys.de> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: precis@ietf.org Subject: Re: [precis] I-D Action: draft-ietf-precis-framework-10.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 17:43:58 -0000 On 10/16/13 5:32 AM, Florian Zeitz wrote: > Am 16.10.2013 00:52, schrieb Peter Saint-Andre: >> On 10/15/13 4:26 PM, internet-drafts@ietf.org wrote: >> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-precis-framework >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-precis-framework-10 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-framework-10 >> >> Reviews of -10 or the diff would be helpful. I plan to check them both >> to make sure that I've accurately addressed all of the last call feedback. >> >> Thanks! >> >> Peter >> > I've had a quick look at the diff, and some areas I felt I should look > at again. I'm generally very happy about the outcome. Excellent, thanks for reviewing the changes. > Thank you for your > hard work. Some minor comments: > > Sections 3.2.2 and 3.3.2 say «Certain characters from the Exceptions > ("F")». That's a bit awkward as a reader. A forward reference to section > 7.6, noting they are explicitly listed there would help. I agree about the forward reference. Will add. (Also the xref in that text was pointing to Section 7.5, not Section 7.6.) > In Section 4.1.3 about case mapping we currently have: > «In general, the combination of case preservation and case-insensitive > comparison of internationalized strings is NOT RECOMMENDED; instead, > application protocols SHOULD either (a) not preserve case but perform > case-insensitive comparison or (b) preserve case but perform > case-sensitive comparison.» > I wonder what the rational for this is? Both SASLprep-bis and Nicknames > seem to want case-preservation, but case-insensitive comparison. I may > be mistaken though. You make a good point. I can't recall the rationale for that text, but it does seem to be violated by several of our profiles, so I'm inclined to remove it. > In Section 10.5 "Visually Similar Characters" I'd suggest a reference to > UTS #39, describing confusable detection and mixed-script detection. That document is referenced in Section 10.1, but mentioning it again in 10.5 would be good. (Also the reference was incorrect since it said UTR39, not UTS39.) Peter -- Peter Saint-Andre https://stpeter.im/ From duerst@it.aoyama.ac.jp Wed Oct 16 15:04:52 2013 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 18DC611E82E9 for ; Wed, 16 Oct 2013 15:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.696 X-Spam-Level: X-Spam-Status: No, score=-103.696 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPoXC1BWH9Kn for ; Wed, 16 Oct 2013 15:04:44 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id EEFA611E82BE for ; Wed, 16 Oct 2013 15:04:43 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r9GM4QJP013202; Thu, 17 Oct 2013 07:04:27 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 6284_2d01_ec4bf378_36ae_11e3_b7f7_001e6722eec2; Thu, 17 Oct 2013 07:04:26 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 73211BF54C; Thu, 17 Oct 2013 07:04:26 +0900 (JST) Message-ID: <525F0D53.5080308@it.aoyama.ac.jp> Date: Thu, 17 Oct 2013 07:04:03 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= References: <525DFB1F.8040401@it.aoyama.ac.jp> <7693B3B4-7204-48F0-8C42-EBF5D701BAF4@frobbit.se> <525E3A7F.9040204@it.aoyama.ac.jp> <11194FD50DDFBDB190254386@JcK-HP8200.jck.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: idna-update@alvestrand.no, John C Klensin , precis@ietf.org Subject: Re: [precis] Category changes with Unicode 6.3 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 22:04:52 -0000 On 2013/10/16 22:49, Patrik F=C3=A4ltstr=C3=B6m wrote: > On 16 okt 2013, at 16:46, John C Klensin wrote: > >> This is great. To a considerable extent, it reinforces the >> utility and importance of the IDNA2008 approach. > > Absolutely! > > Having the original IDNA locked with one version of Unicode is so weird= I ask myself quite often how I could come up with that idea :-P I think there are simple explanations, but they are non-technical. When we worked on IDNA2003, there were so many people asking for so many=20 things (many of them rather impossible, dangerous, or otherwise of=20 doubtful value, but never mind), that any idea that was able to restrict=20 the solution space looked like a good idea. Also, there seems to be a psychological value in the newest version. In=20 economic terms, no difference between 10 cents and 5 cents, and 5 cents=20 and free, but because of psychological reasons, people behave quite=20 differently once something is free. Likewise, with versions, even though=20 the differences from version 3.1 to version 3.2 and from version 3.2 to=20 3.3 or 4.0 may be of the same nature or magnitude, if version 3.2 is the=20 newest, that's seen as more stable and permanent that the others. Thinking about many standardization efforts I have seen over time, there=20 also seems to be a tendency to ignore versioning in the first version,=20 because it's seen as the only one, and people are really concerned with=20 getting the basics right. Occasionally, one sees a lot of effort being=20 put into versioning and extensibility, but it usually doesn't work out=20 exactly as intended. So in summary, versioning is hard, and maybe it's easier to get right in=20 the second version than in the first. Regards, Martin. From paf@frobbit.se Wed Oct 16 15:47:43 2013 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 4FB3211E8189 for ; Wed, 16 Oct 2013 15:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.3 X-Spam-Level: X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNrsAWfrX3vD for ; Wed, 16 Oct 2013 15:47:41 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFC811E8217 for ; Wed, 16 Oct 2013 15:47:17 -0700 (PDT) Received: from [10.10.9.216] (unknown [46.245.141.210]) by mail.frobbit.se (Postfix) with ESMTPSA id 2ED0A21CD7; Thu, 17 Oct 2013 00:47:15 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_740194B7-4CF2-4C12-AB44-785B690FC4CE"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <525F0D53.5080308@it.aoyama.ac.jp> Date: Thu, 17 Oct 2013 01:47:14 +0300 Message-Id: References: <525DFB1F.8040401@it.aoyama.ac.jp> <7693B3B4-7204-48F0-8C42-EBF5D701BAF4@frobbit.se> <525E3A7F.9040204@it.aoyama.ac.jp> <11194FD50DDFBDB190254386@JcK-HP8200.jck.com> <525F0D53.5080308@it.aoyama.ac.jp> To: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= X-Mailer: Apple Mail (2.1510) Cc: John C Klensin , idna-update@alvestrand.no, precis@ietf.org Subject: Re: [precis] Category changes with Unicode 6.3 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 22:47:43 -0000 --Apple-Mail=_740194B7-4CF2-4C12-AB44-785B690FC4CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 17 okt 2013, at 01:04, Martin J. D=FCrst = wrote: > So in summary, versioning is hard, and maybe it's easier to get right = in the second version than in the first. If you do a second version, it better be better than the first :-P paf --Apple-Mail=_740194B7-4CF2-4C12-AB44-785B690FC4CE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSXxdyrMabGguI180RAuVhAJ9DYSAWacyasoE5+4MpeQ9syoYltACeObKR SNN0q6C319g6qOh4K3vPhwY= =vFmr -----END PGP SIGNATURE----- --Apple-Mail=_740194B7-4CF2-4C12-AB44-785B690FC4CE-- From t.nemo10@kmd.keio.ac.jp Fri Oct 18 00:44:15 2013 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 6EF6121F9FA4 for ; Fri, 18 Oct 2013 00:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxCpta2Wyz-f for ; Fri, 18 Oct 2013 00:44:14 -0700 (PDT) Received: from mail.kmd.keio.ac.jp (mail.kmd.keio.ac.jp [IPv6:2001:200:167:2e90::164]) by ietfa.amsl.com (Postfix) with ESMTP id 8018421F9FB0 for ; Fri, 18 Oct 2013 00:44:11 -0700 (PDT) Received: from host201.kmd.keio.ac.jp (host201.kmd.keio.ac.jp [131.113.136.201]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.kmd.keio.ac.jp (Postfix) with ESMTPSA id 41A28806F7; Fri, 18 Oct 2013 16:44:07 +0900 (JST) Content-Type: multipart/signed; boundary="Apple-Mail=_073C64E2-0C87-48A0-BDB3-A011840FA6FF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Takahiro Nemoto In-Reply-To: <20131008224453.GG46045@mx1.yitter.info> Date: Fri, 18 Oct 2013 16:41:19 +0900 Message-Id: <6E7B1D8D-AB23-4FD7-99B6-D1A333772A37@kmd.keio.ac.jp> References: <5227A979.7050403@stpeter.im> <4C8248EF-51BD-4736-A930-E2FEE610EC03@kmd.keio.ac.jp> <20131005031746.GC38902@mx1.yitter.info> <5254632F.6060106@stpeter.im> <20131008211611.GA45541@mx1.yitter.info> <52548959.1040306@stpeter.im> <20131008224453.GG46045@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1510) Cc: precis@ietf.org Subject: Re: [precis] local case mapping X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 18 Oct 2013 07:44:15 -0000 --Apple-Mail=_073C64E2-0C87-48A0-BDB3-A011840FA6FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I would like to address some of the comments that I have received from = Peter, Alexey, and Andrew in this email. First, I would like to do some revision to the document according to = Peter's suggestions. Also, I am planning to split the "References" section into "Normative = References" and "Informative References". One other thing, as Andrew has pointed out, I am thinking of local case = mapping as followings: Purpose: The purpose of local case mapping is to increase the probability of = matching-result from the comparison between=20 uppercase and lowercase characters, targeting language-dependent = characters. Regarding the final sigma, Currently, the handling order of PRECIS Framework is local case mapping = to case mapping. Because of this, when =CE=A3=3DU+03A3 is handled by local case mapping = that apply the context-sensitive (i.e., "language-insensitive") mappings from SpecialCasing.txt, it becomes =CF=82=3D03C2, in the end, when = =CF=82=3D03C2 is case mapped, it will still result in =CF=83=3D03C3. For this reason, final sigma is not one of the targets for local case = mapping. Also, in the next I-D, I would like to add "local case mapping can be = selected only when case mapping is selected=20 using the PRECIS Framework profile" and "casefolding in this document = means full casefolding described in=20 the Casefolding.txt file". Regards, Nemo On 2013/10/09, at 7:44, Andrew Sullivan wrote: > On Tue, Oct 08, 2013 at 04:38:17PM -0600, Peter Saint-Andre wrote: >> case mapping. Better, I think, to say "apply full case mapping". >=20 > Sure, yes. >=20 > A >=20 > --=20 > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis --Apple-Mail=_073C64E2-0C87-48A0-BDB3-A011840FA6FF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJSYOYfAAoJEJk7o/xhVanaHbEH/R8yMZCLsIv2NVUKTTl8q9IV xCaoeirO3tcsgvyX//Y2k9nl/cqdUjfHWTzJVbhd2CIuVk9L9Etm03fTMUqS1L+j xqXJNRxcBbmOTlU0XI5q+RLtZFTF35wmBiZtcPbRG5KWkpZ3z7Cfd8yVgo5jL8G7 7A9RRw6V2sCxcBXFT9tkZt2mLol+SP1A5M2lRYuoTjTEVY2AKnMaqZsChUtWbdNa Fu4mq/zyRut64+NEF+COPM5eEB07xhNug7k1/ZMSFzLCi36UUy7pdSm/AouEabLs LIYw8FhKmgQ6rAX++LK8y8U+oE7YBWG6os+3/+GZM+inO/Ec93pLlbSKZX9HgWs= =8GeO -----END PGP SIGNATURE----- --Apple-Mail=_073C64E2-0C87-48A0-BDB3-A011840FA6FF-- From internet-drafts@ietf.org Fri Oct 18 03:31:40 2013 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 59DC821F9FCF; Fri, 18 Oct 2013 03:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIqTKr7Wi+23; Fri, 18 Oct 2013 03:31:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3880711E8171; Fri, 18 Oct 2013 03:31:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131018103139.2313.67406.idtracker@ietfa.amsl.com> Date: Fri, 18 Oct 2013 03:31:39 -0700 Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-mappings-04.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 10:31:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Preparation and Comparison of Internation= alized Strings Working Group of the IETF. Title : Mapping characters for PRECIS classes Author(s) : Yoshiro YONEYA Takahiro Nemoto Filename : draft-ietf-precis-mappings-04.txt Pages : 9 Date : 2013-10-18 Abstract: The framework for preparation and comparison of internationalized strings ("PRECIS") defines several classes of strings for preparation and comparison. In the framework, case mapping is defined because many protocols handle case-sensitive or case-insensitive string comparison and therefore preparation of the string is mandatory. As described in the mapping for Internationalized Domain Names in Applications (IDNA) and the PRECIS problem statement, mappings for internationalized strings are not limited to case, but also width mapping and mapping of delimiters and other specials can be taken into consideration. This document provides guidelines for authors of protocol profiles of the PRECIS framework and describes several mappings that can be applied between receiving user input and passing permitted code points to internationalized protocols. The mappings described here are expected to be applied as Additional mapping in the PRECIS framework. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-mappings There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-precis-mappings-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-precis-mappings-04 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 t.nemo10@kmd.keio.ac.jp Fri Oct 18 03:49:34 2013 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 89B8921F9F88 for ; Fri, 18 Oct 2013 03:49:34 -0700 (PDT) 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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XE0oiH0v1DbG for ; Fri, 18 Oct 2013 03:49:34 -0700 (PDT) Received: from mail.kmd.keio.ac.jp (mail.kmd.keio.ac.jp [IPv6:2001:200:167:2e90::164]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7E111E81E9 for ; Fri, 18 Oct 2013 03:49:33 -0700 (PDT) Received: from [IPv6:2001:df0:8:81:c14c:697:e5c5:479a] (unknown [IPv6:2001:df0:8:81:c14c:697:e5c5:479a]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.kmd.keio.ac.jp (Postfix) with ESMTPSA id 82FB380446 for ; Fri, 18 Oct 2013 19:49:31 +0900 (JST) From: Takahiro Nemoto Content-Type: multipart/signed; boundary="Apple-Mail=_55A35A5A-A5C2-449D-9C9C-9F6FAA528B92"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <322DC842-F900-471F-AFA9-DBC5BB9F3DEF@kmd.keio.ac.jp> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Date: Fri, 18 Oct 2013 19:49:32 +0900 References: <5227A979.7050403@stpeter.im> <4C8248EF-51BD-4736-A930-E2FEE610EC03@kmd.keio.ac.jp> <20131005031746.GC38902@mx1.yitter.info> <5254632F.6060106@stpeter.im> <20131008211611.GA45541@mx1.yitter.info> <52548959.1040306@stpeter.im> <20131008224453.GG46045@mx1.yitter.info> <6E7B1D8D-AB23-4FD7-99B6-D1A333772A37@kmd.keio.ac.jp> To: "precis@ietf.org" In-Reply-To: <6E7B1D8D-AB23-4FD7-99B6-D1A333772A37@kmd.keio.ac.jp> X-Mailer: Apple Mail (2.1510) Subject: Re: [precis] local case mapping X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 18 Oct 2013 10:49:34 -0000 --Apple-Mail=_55A35A5A-A5C2-449D-9C9C-9F6FAA528B92 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yoneya-san and I submitted new version of precis mappings document.=20 We reflected comments from this ML in this version. Please read and give your comments/suggestions whether this version=20 is an accurate reflection of the comments. BTW, Final sigma is too Unicode-y, so there is not final sigma in this = document. Regards, Nemo On 2013/10/18, at 16:41, Takahiro Nemoto = wrote: > I would like to address some of the comments that I have received from = Peter, Alexey, and Andrew in this email. >=20 > First, I would like to do some revision to the document according to = Peter's suggestions. > Also, I am planning to split the "References" section into "Normative = References" and "Informative References". > One other thing, as Andrew has pointed out, I am thinking of local = case mapping as followings: >=20 > Purpose: > The purpose of local case mapping is to increase the probability of = matching-result from the comparison between=20 > uppercase and lowercase characters, targeting language-dependent = characters. >=20 > Regarding the final sigma, >=20 > Currently, the handling order of PRECIS Framework is local case = mapping to case mapping. > Because of this, when =CE=A3=3DU+03A3 is handled by local case mapping = that apply the context-sensitive (i.e., "language-insensitive") mappings > from SpecialCasing.txt, it becomes =CF=82=3D03C2, in the end, when = =CF=82=3D03C2 is case mapped, it will still result in =CF=83=3D03C3. >=20 > For this reason, final sigma is not one of the targets for local case = mapping. >=20 > Also, in the next I-D, I would like to add "local case mapping can be = selected only when case mapping is selected=20 > using the PRECIS Framework profile" and "casefolding in this document = means full casefolding described in=20 > the Casefolding.txt file". >=20 > Regards, >=20 > Nemo >=20 > On 2013/10/09, at 7:44, Andrew Sullivan = wrote: >=20 >> On Tue, Oct 08, 2013 at 04:38:17PM -0600, Peter Saint-Andre wrote: >>> case mapping. Better, I think, to say "apply full case mapping". >>=20 >> Sure, yes. >>=20 >> A >>=20 >> --=20 >> Andrew Sullivan >> ajs@anvilwalrusden.com >> _______________________________________________ >> precis mailing list >> precis@ietf.org >> https://www.ietf.org/mailman/listinfo/precis >=20 > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis --Apple-Mail=_55A35A5A-A5C2-449D-9C9C-9F6FAA528B92 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJSYRI8AAoJEJk7o/xhVanaamgIAIA32iB5I8MOAJCRMQwt/USI MzC+d+gNDclr/BbaIlElQMTZV4GxS/OnxiyiKlIroW8GgRLGT437oBDn+JawbOc4 uzl5W8VxhRBLlSgJa6yoE/FbgQfhnOox2FRbw/9kNSFSw8Wyzp7OT3tudIzOUPv6 dgQerwOkFgIEDxFi9TQ3RunzRPa+iwV+nweyj0jloZi+725fOQtNjXaipjo2OMCV i48yrU6JFzim1YnIX5ZSBmJhB43NTM1sntoNo2yLkZjFvGwtajw55uaZTeCt8zyZ Ip4O8FWbeUdIYzFbEO4ZYDOh7iTRpsMGYOnC5bz0/4vFCdtdxzSiUAkaWGJCNNA= =AFjP -----END PGP SIGNATURE----- --Apple-Mail=_55A35A5A-A5C2-449D-9C9C-9F6FAA528B92-- From stpeter@stpeter.im Fri Oct 18 10:00:13 2013 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 CB05C11E8318 for ; Fri, 18 Oct 2013 10:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.342 X-Spam-Level: X-Spam-Status: No, score=-102.342 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXDZcFZohKcu for ; Fri, 18 Oct 2013 10:00:07 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A63C711E8311 for ; Fri, 18 Oct 2013 09:58:21 -0700 (PDT) Received: from sjc-vpn3-1120.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 983114100F; Fri, 18 Oct 2013 11:04:45 -0600 (MDT) Message-ID: <526168A8.8050401@stpeter.im> Date: Fri, 18 Oct 2013 10:58:16 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Takahiro Nemoto References: <5227A979.7050403@stpeter.im> <4C8248EF-51BD-4736-A930-E2FEE610EC03@kmd.keio.ac.jp> <20131005031746.GC38902@mx1.yitter.info> <5254632F.6060106@stpeter.im> <20131008211611.GA45541@mx1.yitter.info> <52548959.1040306@stpeter.im> <20131008224453.GG46045@mx1.yitter.info> <6E7B1D8D-AB23-4FD7-99B6-D1A333772A37@kmd.keio.ac.jp> In-Reply-To: <6E7B1D8D-AB23-4FD7-99B6-D1A333772A37@kmd.keio.ac.jp> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: precis@ietf.org Subject: Re: [precis] local case mapping X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 18 Oct 2013 17:00:13 -0000 On 10/18/13 1:41 AM, Takahiro Nemoto wrote: > I would like to address some of the comments that I have received > from Peter, Alexey, and Andrew in this email. > > First, I would like to do some revision to the document according to > Peter's suggestions. Also, I am planning to split the "References" > section into "Normative References" and "Informative References". That's all good. > One > other thing, as Andrew has pointed out, I am thinking of local case > mapping as followings: > > Purpose: The purpose of local case mapping is to increase the > probability of matching-result from the comparison between uppercase > and lowercase characters, targeting language-dependent characters. Works for me. The text in the I-D is now: The purpose of local case mapping is to increase the probability of matching-result from the comparison between uppercase and lowercase characters, targeting locale and locale and context-dependent characters. I stumbled over the last clause. I think it would be a bit clearer as follows: targeting characters whose mapping depends on locale or on locale and context. > Regarding the final sigma, > > Currently, the handling order of PRECIS Framework is local case > mapping to case mapping. Because of this, when Σ=U+03A3 is handled by > local case mapping that apply the context-sensitive (i.e., > "language-insensitive") mappings from SpecialCasing.txt, it becomes > Ï‚=03C2, in the end, when Ï‚=03C2 is case mapped, it will still result > in σ=03C3. > > For this reason, final sigma is not one of the targets for local case > mapping. OK, I understand that logic. However, it implies that if a protocol or PRECIS profile uses local case mapping then it will benefit from the nice language-sensitive mappings in SpecialCasing.txt but it can't handle Greek final sigma in a context-sensitive way. I *think* that's probably fine for comparison purposes. To use my previous example, a nickname of "ΦΙΛΟΣ ΜΟΙ" would be case folded to "φιλοσ μοι" (not "φιλος μοι"). That comparison would be applied consistently, without attention to context (i.e., we wouldn't get "φιλοσμοι" if there's no space but "φιλος μοι" if there is a space). This seems to be an acceptable approach, I just wanted us to be clear that this is what we're doing. :-) > Also, in the next I-D, I would like to add "local case mapping can be > selected only when case mapping is selected using the PRECIS > Framework profile" and "casefolding in this document means full > casefolding described in the Casefolding.txt file". That's sensible. Peter -- Peter Saint-Andre https://stpeter.im/ From internet-drafts@ietf.org Fri Oct 18 14:39:17 2013 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 9569111E8340; Fri, 18 Oct 2013 14:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyJCBFyAZwve; Fri, 18 Oct 2013 14:39:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3F311E8346; Fri, 18 Oct 2013 14:39:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131018213913.21887.55426.idtracker@ietfa.amsl.com> Date: Fri, 18 Oct 2013 14:39:13 -0700 Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-framework-11.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 21:39:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Preparation and Comparison of Internation= alized Strings Working Group of the IETF. Title : PRECIS Framework: Preparation and Comparison of Internat= ionalized Strings in Application Protocols Author(s) : Peter Saint-Andre Marc Blanchet Filename : draft-ietf-precis-framework-11.txt Pages : 63 Date : 2013-10-18 Abstract: Application protocols using Unicode code points in protocol strings need to properly prepare such strings in order 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 and comparison of internationalized strings (a.k.a. "PRECIS") in a way that depends on the properties of Unicode code points 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 3454. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-framework There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-precis-framework-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-precis-framework-11 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 internet-drafts@ietf.org Fri Oct 18 14:40:34 2013 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 4C4D311E8350; Fri, 18 Oct 2013 14:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCd2QofdYfsT; Fri, 18 Oct 2013 14:40:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4919C11E81DB; Fri, 18 Oct 2013 14:40:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131018214030.21947.85427.idtracker@ietfa.amsl.com> Date: Fri, 18 Oct 2013 14:40:30 -0700 Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-nickname-07.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 21:40:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Preparation and Comparison of Internation= alized Strings Working Group of the IETF. Title : Preparation and Comparison of Nicknames Author(s) : Peter Saint-Andre Filename : draft-ietf-precis-nickname-07.txt Pages : 8 Date : 2013-10-18 Abstract: This document describes how to prepare and compare Unicode strings representing nicknames, primarily for use within textual chatrooms. This profile is intended to be used by messaging and text conferencing technologies such as the Extensible Messaging and Presence Protocol (XMPP), the Message Session Relay Protocol (MSRP), and Centralized Conferencing (XCON). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-nickname There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-precis-nickname-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-precis-nickname-07 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 internet-drafts@ietf.org Fri Oct 18 14:44:19 2013 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 E138311E8354; Fri, 18 Oct 2013 14:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QddJgcpIMbxS; Fri, 18 Oct 2013 14:44:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5965811E8353; Fri, 18 Oct 2013 14:44:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131018214418.21929.86472.idtracker@ietfa.amsl.com> Date: Fri, 18 Oct 2013 14:44:18 -0700 Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-saslprepbis-05.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 21:44:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Preparation and Comparison of Internation= alized Strings Working Group of the IETF. Title : Preparation and Comparison of Internationalized Strings = Representing Usernames and Passwords Author(s) : Peter Saint-Andre Alexey Melnikov Filename : draft-ietf-precis-saslprepbis-05.txt Pages : 15 Date : 2013-10-18 Abstract: This document describes methods for handling Unicode strings representing usernames and passwords. This document obsoletes RFC 4013. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-precis-saslprepbis-05 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 internet-drafts@ietf.org Sun Oct 20 22:32:15 2013 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 DE96911E814C; Sun, 20 Oct 2013 22:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecu7qwkG4ZfP; Sun, 20 Oct 2013 22:32:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7A311E8160; Sun, 20 Oct 2013 22:32:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021053215.8729.42323.idtracker@ietfa.amsl.com> Date: Sun, 20 Oct 2013 22:32:15 -0700 Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-mappings-05.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 05:32:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Preparation and Comparison of Internation= alized Strings Working Group of the IETF. Title : Mapping characters for PRECIS classes Author(s) : Yoshiro YONEYA Takahiro Nemoto Filename : draft-ietf-precis-mappings-05.txt Pages : 10 Date : 2013-10-20 Abstract: The framework for preparation and comparison of internationalized strings ("PRECIS") defines several classes of strings for preparation and comparison. In the framework, case mapping is defined because many protocols handle case-sensitive or case-insensitive string comparison and therefore preparation of the string is mandatory. As described in the mapping for Internationalized Domain Names in Applications (IDNA) and the PRECIS problem statement, mappings for internationalized strings are not limited to case, but also width mapping and mapping of delimiters and other specials can be taken into consideration. This document provides guidelines for authors of protocol profiles of the PRECIS framework and describes several mappings that can be applied between receiving user input and passing permitted code points to internationalized protocols. The mappings described here are expected to be applied as Additional mapping in the PRECIS framework. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-mappings There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-precis-mappings-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-precis-mappings-05 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 stpeter@stpeter.im Thu Oct 24 10:27:56 2013 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 C4DCC11E82DA for ; Thu, 24 Oct 2013 10:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.207 X-Spam-Level: X-Spam-Status: No, score=-102.207 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Knk3pV3t98Rb for ; Thu, 24 Oct 2013 10:27:51 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D034411E81A0 for ; Thu, 24 Oct 2013 10:27:49 -0700 (PDT) Received: from sjc-vpn2-18.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C9DB74100F; Thu, 24 Oct 2013 11:34:35 -0600 (MDT) Message-ID: <52695893.9040208@stpeter.im> Date: Thu, 24 Oct 2013 11:27:47 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= References: <525DFB1F.8040401@it.aoyama.ac.jp> <7693B3B4-7204-48F0-8C42-EBF5D701BAF4@frobbit.se> <525E3A7F.9040204@it.aoyama.ac.jp> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "idna-update@alvestrand.no" , "precis@ietf.org" Subject: Re: [precis] Category changes with Unicode 6.3 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 24 Oct 2013 17:27:56 -0000 On 10/16/13 1:16 AM, Patrik Fältström wrote: > Yeah, I had to do it anyways -- as I am expert reviewer of the IANA > tables. New versions of the IANA tables where created by IANA the > other day, and I just approved them as they match my own > calculations. I.e. we have two completely independent implementations > of IDNA2008 (one at IANA, one that I have -- see link below) and I > compare the output of the two. If the output matches, then we are > pretty sure we are correct. Patrik, if I may ask, which implementation does IANA use? Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Thu Oct 24 10:44:31 2013 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 3B99C11E8368 for ; Thu, 24 Oct 2013 10:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.359 X-Spam-Level: X-Spam-Status: No, score=-102.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgTuMO5wPZ6h for ; Thu, 24 Oct 2013 10:43:48 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E25D621E8056 for ; Thu, 24 Oct 2013 10:42:49 -0700 (PDT) Received: from sjc-vpn7-728.cisco.com (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B95264100F; Thu, 24 Oct 2013 11:49:33 -0600 (MDT) Message-ID: <52695C15.6010303@stpeter.im> Date: Thu, 24 Oct 2013 11:42:45 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: John C Klensin References: <525DFB1F.8040401@it.aoyama.ac.jp> <7693B3B4-7204-48F0-8C42-EBF5D701BAF4@frobbit.se> <525E3A7F.9040204@it.aoyama.ac.jp> <11194FD50DDFBDB190254386@JcK-HP8200.jck.com> In-Reply-To: <11194FD50DDFBDB190254386@JcK-HP8200.jck.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: precis@ietf.org Subject: Re: [precis] Category changes with Unicode 6.3 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 24 Oct 2013 17:44:31 -0000 [ removing idna-update ] On 10/16/13 7:46 AM, John C Klensin wrote: > > > --On Wednesday, October 16, 2013 10:16 +0300 Patrik Fältström > wrote: > >> Yeah, I had to do it anyways -- as I am expert reviewer of the >> IANA tables. New versions of the IANA tables where created by >> IANA the other day, and I just approved them as they match my >> own calculations. I.e. we have two completely independent >> implementations of IDNA2008 (one at IANA, one that I have -- >> see link below) and I compare the output of the two. If the >> output matches, then we are pretty sure we are correct. > > This is great. To a considerable extent, it reinforces the > utility and importance of the IDNA2008 approach. YOu (and > IANA) reapply the rules to a new version of Unicode, verify that > nothing significant has changed and your results are the same, > and we move on. > > In addition, because mapping is defined on top of those rules > and the collection of allowable code points they create, we > don't end up with different profiles for different domains or > applications. > > It remains to be seen whether the PRECIS approach will work as > well. On the one hand, generation rules have replaced the > normative Stringprep table. On the other, that system leads, > not to a definitive list but to string classes that are then > profiled, potentially on an application-by-application or even > implementation-by-implementation basis, to yield actual > practices. Different behavior in different applications may be > inevitable but it is certain that it will confuse at least some > users. And, because different profiles will address different > parts of the basic PRECIS code space, it is possible that the > same evaluations that are run against the generation rules for > IDNA (and exceptional adjustments added if needed) will need to > be performed for each profile, resulting in temporal > instability. Perhaps it will all work out and the profiles > will be completely stable, but it is hard to be completely > confident about that. Unfortunately, I have to agree. It seems to me that with IDNA2008 we don't end up with different profiles for different applications because there's only one application. With PRECIS we're again attempting to generalize beyond the IDN case to a wider variety of applications, and different applications have different requirements with regard to case preservation and case mapping, normalization, excluded characters, etc. It strikes me that we'll need code to test all of the PRECIS profiles, not just the string classes. I haven't had time to keep my PrecisMaker code up to date, let alone extend it for all of the profiles, but I will try to work on those tasks after the Vancouver meeting. Peter -- Peter Saint-Andre https://stpeter.im/ From paf@frobbit.se Thu Oct 24 11:00:27 2013 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 7248C11E819A for ; Thu, 24 Oct 2013 11:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3eanPS5gr8h for ; Thu, 24 Oct 2013 11:00:27 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id E280611E81B4 for ; Thu, 24 Oct 2013 11:00:26 -0700 (PDT) Received: from [IPv6:2a02:80:3ffc::dd37:9960:69bf:f2ed] (unknown [IPv6:2a02:80:3ffc:0:dd37:9960:69bf:f2ed]) by mail.frobbit.se (Postfix) with ESMTPSA id 9619820106; Thu, 24 Oct 2013 20:00:19 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_7455125A-8DA6-49CA-9476-8E5842C5A37A"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <52695893.9040208@stpeter.im> Date: Thu, 24 Oct 2013 20:00:18 +0200 Message-Id: <7B91C7A5-B466-4440-A78D-4C2FE8BA3B7F@frobbit.se> References: <525DFB1F.8040401@it.aoyama.ac.jp> <7693B3B4-7204-48F0-8C42-EBF5D701BAF4@frobbit.se> <525E3A7F.9040204@it.aoyama.ac.jp> <52695893.9040208@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1816) Cc: "idna-update@alvestrand.no" , "precis@ietf.org" Subject: Re: [precis] Category changes with Unicode 6.3 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 24 Oct 2013 18:00:27 -0000 --Apple-Mail=_7455125A-8DA6-49CA-9476-8E5842C5A37A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 24 okt 2013, at 19:27, Peter Saint-Andre wrote: > On 10/16/13 1:16 AM, Patrik F=E4ltstr=F6m wrote: >> Yeah, I had to do it anyways -- as I am expert reviewer of the IANA >> tables. New versions of the IANA tables where created by IANA the >> other day, and I just approved them as they match my own >> calculations. I.e. we have two completely independent implementations >> of IDNA2008 (one at IANA, one that I have -- see link below) and I >> compare the output of the two. If the output matches, then we are >> pretty sure we are correct. >=20 > Patrik, if I may ask, which implementation does IANA use? Not mine :-) I know Marc Blanchet was involved in developing it, because he asked me = some questions, but honestly I do not know. You must ask IANA. I had my code ready (I actually have two versions of the code, ruby and = python -- where the ruby code is completely written from base up while = python use some external libraries for a few things) when IANA started = to implement theirs. I asked them to ensure they would develop their = code completely independent from mine. What we do though is that when IANA has calculated a new version of the = tables (for a new version of Unicode) I do the calculations as well with = my code. I do a diff, and if there are no differences, then I say "go" = to IANA and they make the new version available. Patrik --Apple-Mail=_7455125A-8DA6-49CA-9476-8E5842C5A37A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSaWAyrMabGguI180RAlrPAJ9SDO5aSw5Dw+sw5uFo8Eo+t1WaggCeLoRG aBBqEacyxBwjunt0RzR7vAM= =/D80 -----END PGP SIGNATURE----- --Apple-Mail=_7455125A-8DA6-49CA-9476-8E5842C5A37A-- From stpeter@stpeter.im Thu Oct 24 11:14:10 2013 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 3922411E837C for ; Thu, 24 Oct 2013 11:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.221 X-Spam-Level: X-Spam-Status: No, score=-102.221 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0sd4Tb9WiIB for ; Thu, 24 Oct 2013 11:14:05 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BDA6011E8368 for ; Thu, 24 Oct 2013 11:13:56 -0700 (PDT) Received: from sjc-vpn7-273.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D6A984100F; Thu, 24 Oct 2013 12:20:42 -0600 (MDT) Message-ID: <52696362.8020507@stpeter.im> Date: Thu, 24 Oct 2013 12:13:54 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= References: <525DFB1F.8040401@it.aoyama.ac.jp> <7693B3B4-7204-48F0-8C42-EBF5D701BAF4@frobbit.se> <525E3A7F.9040204@it.aoyama.ac.jp> <52695893.9040208@stpeter.im> <7B91C7A5-B466-4440-A78D-4C2FE8BA3B7F@frobbit.se> In-Reply-To: <7B91C7A5-B466-4440-A78D-4C2FE8BA3B7F@frobbit.se> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "precis@ietf.org" Subject: Re: [precis] Category changes with Unicode 6.3 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 24 Oct 2013 18:14:10 -0000 On 10/24/13 12:00 PM, Patrik Fältström wrote: > > On 24 okt 2013, at 19:27, Peter Saint-Andre > wrote: > >> On 10/16/13 1:16 AM, Patrik Fältström wrote: >>> Yeah, I had to do it anyways -- as I am expert reviewer of the >>> IANA tables. New versions of the IANA tables where created by >>> IANA the other day, and I just approved them as they match my >>> own calculations. I.e. we have two completely independent >>> implementations of IDNA2008 (one at IANA, one that I have -- see >>> link below) and I compare the output of the two. If the output >>> matches, then we are pretty sure we are correct. >> >> Patrik, if I may ask, which implementation does IANA use? > > Not mine :-) > > I know Marc Blanchet was involved in developing it, because he asked > me some questions, but honestly I do not know. You must ask IANA. > > I had my code ready (I actually have two versions of the code, ruby > and python -- where the ruby code is completely written from base up > while python use some external libraries for a few things) when IANA > started to implement theirs. I asked them to ensure they would > develop their code completely independent from mine. > > What we do though is that when IANA has calculated a new version of > the tables (for a new version of Unicode) I do the calculations as > well with my code. I do a diff, and if there are no differences, then > I say "go" to IANA and they make the new version available. > > Patrik > Thanks, that's helpful. We'll need to establish a similar workflow for PRECIS. Peter -- Peter Saint-Andre https://stpeter.im/ From john-ietf@jck.com Thu Oct 24 12:42:47 2013 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 DB09911E8218 for ; Thu, 24 Oct 2013 12:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.552 X-Spam-Level: X-Spam-Status: No, score=-103.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZZPYTtBemYs for ; Thu, 24 Oct 2013 12:42:40 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAA311E8152 for ; Thu, 24 Oct 2013 12:42:40 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1VZQnl-0007rT-VE; Thu, 24 Oct 2013 15:42:37 -0400 Date: Thu, 24 Oct 2013 15:42:32 -0400 From: John C Klensin To: Peter Saint-Andre Message-ID: <1F7316EC4689A417B3D70577@JcK-HP8200.jck.com> In-Reply-To: <52695C15.6010303@stpeter.im> References: <525DFB1F.8040401@it.aoyama.ac.jp> <7693B3B4-7204-48F0-8C42-EBF5D701BAF4@frobbit.se> <525E3A7F.9040204@it.aoyama.ac.jp> <11194FD50DDFBDB190254386@JcK-HP8200.jck.com> <52695C15.6010303@stpeter.im> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: precis@ietf.org Subject: Re: [precis] Category changes with Unicode 6.3 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 24 Oct 2013 19:42:47 -0000 (changing return address in the hope of avoiding filtering) --On Thursday, October 24, 2013 11:42 -0600 Peter Saint-Andre wrote: >... >> It remains to be seen whether the PRECIS approach will work as >> well. On the one hand, generation rules have replaced the >> normative Stringprep table. On the other, that system leads, >> not to a definitive list but to string classes that are then >> profiled, potentially on an application-by-application or even >> implementation-by-implementation basis, to yield actual >> practices. Different behavior in different applications may >> be inevitable but it is certain that it will confuse at least >> some users. And, because different profiles will address >> different parts of the basic PRECIS code space, it is >> possible that the same evaluations that are run against the >> generation rules for IDNA (and exceptional adjustments added >> if needed) will need to be performed for each profile, >> resulting in temporal instability. Perhaps it will all >> work out and the profiles will be completely stable, but it >> is hard to be completely confident about that. > > Unfortunately, I have to agree. It seems to me that with > IDNA2008 we don't end up with different profiles for different > applications because there's only one application. Yes, although it wasn't for lack of trying by people who, instead, wanted different profiles for different scripts and/or languages. > With PRECIS > we're again attempting to generalize beyond the IDN case to a > wider variety of applications, and different applications have > different requirements with regard to case preservation and > case mapping, normalization, excluded characters, etc. It > strikes me that we'll need code to test all of the PRECIS > profiles, not just the string classes. I haven't had time to > keep my PrecisMaker code up to date, let alone extend it for > all of the profiles, but I will try to work on those tasks > after the Vancouver meeting. I completely agree, but was actually trying to make a slightly different point. It is certainly the case that different applications have evolved differently and developed different ways of dealing with non-ASCII characters. Characterizing those as "different requirements", except in the sense of what those evolutionary processes came up with, is another matter. All of those different rules and profiles are probably ok today, while non-ASCII strings are still relatively unusual and most of those who are using them either understands the issues or understands that they are wandering around on thin ice. But, in the long run, they are almost certain to cause a huge amount of user confusion as those users make inferences about what should work in application X based on what works in application Y. I recognize that there are real differences between, e.g., a set of rules that can serve to maximize entropy in a password-like application and rules for what we normally think of as system identifiers (including, but not limited to the DNS) or user names. But it seems to me that, if we end up needing per-application profiles rather than a very small number of profiles (I'd guess four or five including the IDN one would be too many) for application categories that can be explained to users, we will be doing ourselves and the Internet a real disservice. If that means some applications will need to undergo a difficult transition around some edge cases, better sooner than later: if enough users and confused and cry out in pain, it will be only a matter of time before applications start applying their own restrictions to reduce the number of painful surprises. best, john From yoshiro.yoneya@jprs.co.jp Mon Oct 28 23:22:54 2013 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 284D421E80DE for ; Mon, 28 Oct 2013 23:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.349 X-Spam-Level: X-Spam-Status: No, score=-102.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljJrffIXyey9 for ; Mon, 28 Oct 2013 23:22:53 -0700 (PDT) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id 87C0121E80DC for ; Mon, 28 Oct 2013 23:22:53 -0700 (PDT) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id r9T6MpoQ018857 for ; Tue, 29 Oct 2013 15:22:51 +0900 X-AuditID: ac120820-b7f196d00000167f-30-526f543b002a Received: from NOTE701 (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id 8D.C6.05759.B345F625; Tue, 29 Oct 2013 15:22:51 +0900 (JST) Date: Tue, 29 Oct 2013 15:22:42 +0900 From: Yoshiro YONEYA To: precis@ietf.org Message-Id: <20131029152242.b6e8541d8fbec599a143b1a9@jprs.co.jp> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsWyRoiFT9c6JD/IYMF9YYtd3/+wOjB6LFny kymAMYrLJiU1J7MstUjfLoEr4/a3r2wFGzkq3i6JaWC8xtbFyMkhIWAi8fbJVhYIW0ziwr31 QHEuDiGB44wSyx+/AytiEVCVOHxmFjOIzSZgIPFr2W8mEFtEQFji1u2FrF2MHBzCAmoSx5e5 gYR5BRwkvp9aBzXTQuJCUwc7SAmvgKDE3x3CIGFmAS2Jh79usUDY8hLb385hnsDIMwuhahaS qllIqhYwMq9ilMlPS9MtTs1LKc5NNzDUK6nM18sqKCrWSwbRmxjBgcKhsINxximDQ4wCHIxK PLxr+PODhFgTy4orcw8xSnIwKYny8gYChfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nw7ggGyvGm JFZWpRblw6SkOViUxHmP/zkTKCSQnliSmp2aWpBaBJOV4eBQkuBlBmkULEpNT61Iy8wpQUgz cXCCDOcBGi4XBDK8uCAxtzgzHSJ/ilFSSpz3P0hCACSRUZoH1/uKURzoBWFef5DRPMCoh+t6 BTSQCWjgHpY8kIEliQgpqQbG+RVvJFy6yyT6trBrqmu4ChTJCjvo83Nt9rv+itthpdyFzgUO up46xsG+qXVvdm3xksj/X/rtdX7iJREd7pX3l844bLZ488M3Hoa+ZwqYOR9cLPFkZt535Off Ir0NsWZvzy66laTz+qjhk10yD7dv6XtdUcBrEDHvefLOE9fiN9qG7Qi6OklLiaU4I9FQi7mo OBEAtgb1nbcCAAA= Subject: [precis] IETF88 Vancouver draft agenda X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 06:22:54 -0000 Dear all, Following is draft agenda for IETF 88 Vancouver. Please send comments/additions/changes to the chairs. 1. Administrativia 2. Document updates / Discussion 2.1 WG I-Ds (1) Framework https://datatracker.ietf.org/doc/draft-ietf-precis-framework/ (2) Preparation and Comparison of Nicknames https://datatracker.ietf.org/doc/draft-ietf-precis-nickname/ (3) Mapping characters for precis classes http://datatracker.ietf.org/doc/draft-ietf-precis-mappings/ (4) Preparation and Comparison of Internationalized Strings Representing Simple User Names and Passwords http://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/ 2.2 Discussion on WG LC comments (1) Framework (2) Mapping characters for precis classes 2.3 Individual Documents (1) HTTPAuthPrep: PRECIS profile for HTTP Authentication https://datatracker.ietf.org/doc/draft-oiwa-precis-httpauthprep/ 3. Next steps 3.1 Profile documents 3.2 Guideline documents Marc & Yoneya, co-chairs