From nobody Tue Feb 3 18:43:58 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4411A1A5A for ; Tue, 3 Feb 2015 18:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.111 X-Spam-Level: X-Spam-Status: No, score=-7.111 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKKnmCkITVe5 for ; Tue, 3 Feb 2015 18:43:52 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D53E1A1A39 for ; Tue, 3 Feb 2015 18:43:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1423017832; x=1454553832; h=message-id:date:from:mime-version:to:subject; bh=0kU92nifku9nagf3J/bOPy456hqh/cP7XhSWbY1d4q0=; b=hftnB29M3yzS9WF+13G4d4K+kXVdWYoANMDhECm7sQ3Z/jOw4U+kj5/N h8tuam0GhqhGxKMmwvTsnuc/6EdD5cRqsMDA2I5o9nnkHlZJYQUa1VCTK kBxV+m1MxxGMKBX/HksbTw9qpIUS4ampYWs0HBDSz2198GwyS3FUaDGw7 c=; X-IronPort-AV: E=McAfee;i="5600,1067,7701"; a="82648343" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth01.qualcomm.com with ESMTP; 03 Feb 2015 18:43:47 -0800 X-IronPort-AV: E=Sophos; i="5.09,516,1418112000"; d="scan'208,217"; a="32294761" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 03 Feb 2015 18:43:47 -0800 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 3 Feb 2015 18:43:46 -0800 Message-ID: <54D18760.8090100@qti.qualcomm.com> Date: Tue, 3 Feb 2015 20:43:44 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "precis@ietf.org" Content-Type: multipart/alternative; boundary="------------090805080702080706050603" X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (10.85.0.83) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Subject: [precis] One change before Last Call X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 02:43:55 -0000 --------------090805080702080706050603 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Greetings, Given the late-breaking excitement of the IAB Statement[1], I have been chatting with a few folks (John Klensin, Andrew Sullivan, Patrik Fältström) about text we can add to the document to explain the state of affairs before I send it out for a second Last Call. We've worked out the following (with a bit of editorial help from PSA): As part of the review of Unicode 7.0 for IDNA, a question was raised about a newly-added code point that led to a re-analysis of the Normalization Rules used by IDNA and inherited by this document (section 5.2.4). Some of the general issues are described in [IAB-Statement] and pursued in more detail in [draft-klensin-idna-5892upd-unicode70], but the result is that in the future, this specification is likely to be updated such that the range of characters in the LetterDigits category (Sections 4.2.1 and 9.1) may be narrowed, some characters with special properties that are now allowed may be excluded, more Additional Mapping Rules (Section 5.2.2) may be added, and/or alternative normalization methods may be added. Even so, implementations that are sensitive to the advice given in this specification (to be careful to only allow characters whose implications they actually understand and, especially for the LetterDigit case, characters that actually are used to write relevant human languages) are unlikely to run into significant problems as a consequence of these issues or potential changes. That is, we're aware of the issue, it's not just about Hamza, it's documented elsewhere, and the spec might change down the road because of it, but it's unlikely to affect an implementer who does the right thing anyway. Does that text work for folks? If I don't hear much in the way of objection in the next 24 hours, I'll ask the authors to put that in and do the Last Call. pr [1] https://www.iab.org/documents/correspondence-reports-documents/2015-2/iab-statement-on-identifiers-and-unicode-7-0-0/ -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------090805080702080706050603 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Greetings,

Given the late-breaking excitement of the IAB Statement[1], I have been chatting with a few folks (John Klensin, Andrew Sullivan, Patrik Fältström) about text we can add to the document to explain the state of affairs before I send it out for a second Last Call. We've worked out the following (with a bit of editorial help from PSA):

As part of the review of Unicode 7.0 for IDNA, a question was raised about a newly-added code point that led to a re-analysis of the Normalization Rules used by IDNA and inherited by this document (section 5.2.4). Some of the general issues are described in [IAB-Statement] and pursued in more detail in [draft-klensin-idna-5892upd-unicode70], but the result is that in the future, this specification is likely to be updated such that the range of characters in the LetterDigits category (Sections 4.2.1 and 9.1) may be narrowed, some characters with special properties that are now allowed may be excluded, more Additional Mapping Rules (Section 5.2.2) may be added, and/or alternative normalization methods may be added. Even so, implementations that are sensitive to the advice given in this specification (to be careful to only allow characters whose implications they actually understand and, especially for the LetterDigit case, characters that actually are used to write relevant human languages) are unlikely to run into significant problems as a consequence of these issues or potential changes.

That is, we're aware of the issue, it's not just about Hamza, it's documented elsewhere, and the spec might change down the road because of it, but it's unlikely to affect an implementer who does the right thing anyway.

Does that text work for folks? If I don't hear much in the way of objection in the next 24 hours, I'll ask the authors to put that in and do the Last Call.

pr

[1] https://www.iab.org/documents/correspondence-reports-documents/2015-2/iab-statement-on-identifiers-and-unicode-7-0-0/
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------090805080702080706050603-- From nobody Tue Feb 3 19:12:30 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88AA61A1BBD for ; Tue, 3 Feb 2015 19:12:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwKz5VVqTMTX for ; Tue, 3 Feb 2015 19:12:23 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EEDB1A1ACA for ; Tue, 3 Feb 2015 19:12:23 -0800 (PST) Received: from netb ([82.113.106.93]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lxt3Q-1XXWhE0D36-015HKL; Wed, 04 Feb 2015 04:12:21 +0100 From: Bjoern Hoehrmann To: Pete Resnick Date: Wed, 04 Feb 2015 04:12:21 +0100 Message-ID: <2423dah4ipo7jhvjr3vq4alidnsk7qdt5v@hive.bjoern.hoehrmann.de> References: <54D18760.8090100@qti.qualcomm.com> In-Reply-To: <54D18760.8090100@qti.qualcomm.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:5Ab5YSJX8/K4MkELu3OHng34786g91we9041q69IZwaNzpz1qeh DX7wxFbqyZjq80AY0mId6sOjCP7YJOxEgFvkLTxtzqq4xK+s+CcBn+dGokz4vI8uKR6Ut7L mxl+43WQfg99qKeHgndoC/vNXB8hPcPzN3a1eWOuLV+i+CQANdI4WbuiQ00SVMo7ngYRlTg ejQyUU/V9pHxg6OV+cVXg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "precis@ietf.org" Subject: Re: [precis] One change before Last Call X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 03:12:25 -0000 * Pete Resnick wrote: > [...] Even so, implementations that are sensitive to > the advice given in this specification (to be careful to only allow > characters whose implications they actually understand and, > especially for the LetterDigit case, characters that actually are > used to write relevant human languages) are unlikely to run into > significant problems as a consequence of these issues or potential > changes. You did not say which document this is for, but if it actually gives the advice above, then it probably should be abandoned. As an example, even though I had seen any number of mispellings of my name, it was not until a Google employee trying to recruit me kept addressing me as "Bjoem" that I realised "rn" can be confused with "m" a couple of years ago. So, the text above pretty much comes across as mockery, there is no way for me to fully understand the implications of dozens of characters, and the Unicode range spans across over a million of characters. I think it is not appropriate for the specification to try and shift responsibility to implementers in this extreme fashion. Might as well suggest that stereo- typical monolingual citizens of the United States reject non-ASCII input and even then still blame them for confusions like "rn" versus "m". -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/ From nobody Tue Feb 3 19:24:54 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A43C1A1BD1 for ; Tue, 3 Feb 2015 19:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGqt0v-35IGH for ; Tue, 3 Feb 2015 19:24:50 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18E641A1BCF for ; Tue, 3 Feb 2015 19:24:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1423020290; x=1454556290; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=fvi5WKOnMdwUIFI6fyYBggvt7fZLwTsOn/Ey01GVWfc=; b=bzHWSLLXtfsWqkG5rsrS0UDhWn8j+mwoJvGrbdr/pR4rRmeF0dwGwMHu qgp3IH2WXV+RZvjAWtzBCVlHxM7uNY0h/3ecegCWAmD9N6NpxtEcS8Kau Tx6RyqXuXKZ5yzuosLIw659AarrP58OXfFAWRZ6NQ47QwHkKK4jY5dWAK 8=; X-IronPort-AV: E=McAfee;i="5600,1067,7701"; a="101760630" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by wolverine01.qualcomm.com with ESMTP; 03 Feb 2015 19:24:46 -0800 X-IronPort-AV: E=Sophos;i="5.09,516,1418112000"; d="scan'208";a="31660590" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 03 Feb 2015 19:24:46 -0800 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 3 Feb 2015 19:24:44 -0800 Message-ID: <54D190FB.9060609@qti.qualcomm.com> Date: Tue, 3 Feb 2015 21:24:43 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Bjoern Hoehrmann References: <54D18760.8090100@qti.qualcomm.com> <2423dah4ipo7jhvjr3vq4alidnsk7qdt5v@hive.bjoern.hoehrmann.de> In-Reply-To: <2423dah4ipo7jhvjr3vq4alidnsk7qdt5v@hive.bjoern.hoehrmann.de> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01D.na.qualcomm.com (10.85.0.84) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Cc: "precis@ietf.org" Subject: Re: [precis] One change before Last Call X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 03:24:52 -0000 On 2/3/15 9:12 PM, Bjoern Hoehrmann wrote: > You did not say which document this is for... -framework. > ...but if it actually gives the advice above... > Might I suggest that before commenting on what you think the text might mean, you actually read over the document and see if it says something that is in fact problematic. Since the documents cited in the text I provided are *not* about confusability, and the present document's section 12.5 discusses the issue and what can, and more importantly can't, be done about it, I'd suggest that the rest of what you write is not applicable to either the document or the text to be added. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Tue Feb 3 20:04:44 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDDFA1A1B7E for ; Tue, 3 Feb 2015 20:04:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPBu90usCo7L for ; Tue, 3 Feb 2015 20:04:39 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A353D1A1B77 for ; Tue, 3 Feb 2015 20:04:38 -0800 (PST) Received: from netb ([82.113.106.93]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MHso5-1YLsXn3Q7B-003fTg; Wed, 04 Feb 2015 05:04:36 +0100 From: Bjoern Hoehrmann To: Pete Resnick Date: Wed, 04 Feb 2015 05:04:35 +0100 Message-ID: References: <54D18760.8090100@qti.qualcomm.com> <2423dah4ipo7jhvjr3vq4alidnsk7qdt5v@hive.bjoern.hoehrmann.de> <54D190FB.9060609@qti.qualcomm.com> In-Reply-To: <54D190FB.9060609@qti.qualcomm.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:yk5ruvDsE7/ReLswFI9iq/RJNkSWqzu2hKO6Lzn5z/tpAlIn5eu 1I+G879mx+7g4SKSaELBFQOIIRyatS65SwbttRpSmtmcleLCFew0OfA4Y1qmZQoFjDyfRpD UUHGN54JaBjYIGnM0MTFNwUIb37cuQJAvtZt0p1HOS3sPkrVirO4GPzw5Xrriusxu1sFo6c PX4nglzHGt0IiHoYcB9Qg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "precis@ietf.org" Subject: Re: [precis] One change before Last Call X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 04:04:42 -0000 * Pete Resnick wrote: >On 2/3/15 9:12 PM, Bjoern Hoehrmann wrote: >> You did not say which document this is for... > >-framework. > >> ...but if it actually gives the advice above... >> > >Might I suggest that before commenting on what you think the text might >mean, you actually read over the document and see if it says something >that is in fact problematic. Since the documents cited in the text I >provided are *not* about confusability, and the present document's >section 12.5 discusses the issue and what can, and more importantly >can't, be done about it, I'd suggest that the rest of what you write is >not applicable to either the document or the text to be added. I think the text to be added is very clear that implementations should disallow all characters whose implications are not actually understood. If you cannot produce a complete list of all characters implementations should disallow with the current version of the Unicode standard, then my comment seems very applicable to me. Note that I have reviewed the document before and did not come across the advice the proposed text claims to be there, and I've checked section 12.5 right now and do not see it there either. Regardless, as an example, if, instead of saying Even so, implementations that are sensitive to the advice given in this specification (to be careful to only allow characters whose implications they actually understand and, especially for the LetterDigit case, characters that actually are used to write relevant human languages) are unlikely to run into significant problems as a consequence of these issues or potential changes. the specification were to say something like Implementations that heavily restrict which characters they allow, like limiting the set of permissable characters to a single script, are unlikely to run into significant problems as a consequence of these issues or potential changes. I would find that much less objectionable. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/ From nobody Tue Feb 3 20:40:46 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0FDC1A1BEA for ; Tue, 3 Feb 2015 20:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.01 X-Spam-Level: X-Spam-Status: No, score=-9.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMIIzmchGjME for ; Tue, 3 Feb 2015 20:40:42 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F9B21A1BE6 for ; Tue, 3 Feb 2015 20:40:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1423024843; x=1454560843; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=h69BkW4rd9BATw/kiY5DTviMtIW2YP9i8Y87RskIrWo=; b=QaF9NLkYH/cG3yAA/iumFAhQ1E07v/w4hwVv7ZTotZR9LqajlvEewBF5 Q4HnAsYVGYcVU17mejOGfR6AisMysq9uEv1jno5RMjAkmMK3aBUdXk3u9 ZwhhUjhmkQpmV0liRk727SOuZlvNnVAWowslxzVGgpJRf9LIzGrraVkFn 0=; X-IronPort-AV: E=McAfee;i="5600,1067,7701"; a="82652703" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Feb 2015 20:40:43 -0800 X-IronPort-AV: E=Sophos;i="5.09,517,1418112000"; d="scan'208,217";a="807089102" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 03 Feb 2015 20:40:43 -0800 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 3 Feb 2015 20:40:41 -0800 Message-ID: <54D1A2C7.8020301@qti.qualcomm.com> Date: Tue, 3 Feb 2015 22:40:39 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Bjoern Hoehrmann References: <54D18760.8090100@qti.qualcomm.com> <2423dah4ipo7jhvjr3vq4alidnsk7qdt5v@hive.bjoern.hoehrmann.de> <54D190FB.9060609@qti.qualcomm.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050905060201030509020502" X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01G.na.qualcomm.com (10.85.0.33) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Cc: "precis@ietf.org" Subject: Re: [precis] One change before Last Call X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 04:40:45 -0000 --------------050905060201030509020502 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 2/3/15 10:04 PM, Bjoern Hoehrmann wrote: > I think the text to be added is very clear that implementations should > disallow all characters whose implications are not actually understood. > So, if you read the text below again, you'll see that it says that the *rest of the document* says that implementers need to be careful in certain ways. It is referring to advice in 4.1 and 12.3 regarding free-form class, to give two particular examples, as well as by reference the discussion in the IDNA document. Perhaps you are saying that the text I proposed does not properly capture what's in the document; that's a fine thing to discuss. Let's just not get off on the tangent of confusables. > Note that I have reviewed the > document before and did not come across the advice the proposed text > claims to be there, and I've checked section 12.5 right now and do not > see it there either. > I mentioned 12.5 in reference to your discussion of confusables, which is not part of what this text is meant to point to. > Regardless, as an example, if, instead of saying > > Even so, implementations that are sensitive to the advice given in > this specification (to be careful to only allow characters whose > implications they actually understand and, especially for the > LetterDigit case, characters that actually are used to write > relevant human languages) are unlikely to run into significant > problems as a consequence of these issues or potential changes. > > the specification were to say something like > > Implementations that heavily restrict which characters they allow, > like limiting the set of permissable characters to a single script, > are unlikely to run into significant problems as a consequence of > these issues or potential changes. > > I would find that much less objectionable. > Your suggestion I think is making too strong a claim, but I see where you're going. You needn't limit to a single script or otherwise heavily restrict to stay clear of potential problems; you simply have to stick to the more restrictive classes provided, or if you need to use free-form, then restrict to something more limited. So perhaps this would be clearer, and capture your concern: Even so, implementations that are sensitive to the advice given in this specification (to use the more restrictive String Classes, or otherwise to only allow a restricted set of characters, particularly ones whose implications they actually understand) are unlikely to run into significant problems as a consequence of these issues or potential changes. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------050905060201030509020502 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 2/3/15 10:04 PM, Bjoern Hoehrmann wrote:

I think the text to be added is very clear that implementations should
disallow all characters whose implications are not actually understood.

So, if you read the text below again, you'll see that it says that the *rest of the document* says that implementers need to be careful in certain ways. It is referring to advice in 4.1 and 12.3 regarding free-form class, to give two particular examples, as well as by reference the discussion in the IDNA document. Perhaps you are saying that the text I proposed does not properly capture what's in the document; that's a fine thing to discuss. Let's just not get off on the tangent of confusables.

Note that I have reviewed the
document before and did not come across the advice the proposed text
claims to be there, and I've checked section 12.5 right now and do not
see it there either.

I mentioned 12.5 in reference to your discussion of confusables, which is not part of what this text is meant to point to.

Regardless, as an example, if, instead of saying

    Even so, implementations that are sensitive to the advice given in 
    this specification (to be careful to only allow characters whose 
    implications they actually understand and, especially for the 
    LetterDigit case, characters that actually are used to write 
    relevant human languages) are unlikely to run into significant 
    problems as a consequence of these issues or potential changes.

the specification were to say something like

    Implementations that heavily restrict which characters they allow,
    like limiting the set of permissable characters to a single script,
    are unlikely to run into significant problems as a consequence of 
    these issues or potential changes.

I would find that much less objectionable.

Your suggestion I think is making too strong a claim, but I see where you're going. You needn't limit to a single script or otherwise heavily restrict to stay clear of potential problems; you simply have to stick to the more restrictive classes provided, or if you need to use free-form, then restrict to something more limited. So perhaps this would be clearer, and capture your concern:

Even so, implementations that are sensitive to the advice given in this specification (to use the more restrictive String Classes, or otherwise to only allow a restricted set of characters, particularly ones whose implications they actually understand) are unlikely to run into significant problems as a consequence of these issues or potential changes.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------050905060201030509020502-- From nobody Tue Feb 3 21:18:45 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07DB61A1BEA for ; Tue, 3 Feb 2015 21:18:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.14 X-Spam-Level: X-Spam-Status: No, score=-1.14 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vyt4QL6-9mqI for ; Tue, 3 Feb 2015 21:18:42 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8242D1A1BE4 for ; Tue, 3 Feb 2015 21:18:42 -0800 (PST) Received: from netb ([89.204.155.33]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LlHsg-1XlBy31BYc-00b5Gt; Wed, 04 Feb 2015 06:18:37 +0100 From: Bjoern Hoehrmann To: Pete Resnick Date: Wed, 04 Feb 2015 06:18:34 +0100 Message-ID: References: <54D18760.8090100@qti.qualcomm.com> <2423dah4ipo7jhvjr3vq4alidnsk7qdt5v@hive.bjoern.hoehrmann.de> <54D190FB.9060609@qti.qualcomm.com> <54D1A2C7.8020301@qti.qualcomm.com> In-Reply-To: <54D1A2C7.8020301@qti.qualcomm.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:Xbvi8ssRxot2rGjZ6z3dRscV+EdPD16PyEvr2l5bPGOfOChQwYT cXBno3cHxthkxx+GJ6VYgVyP31a/M+3YesERe9yttcaVhSZRaeYTs8X94v0jJChZgKQTsc/ 6wrjAcjJehwejt+JwqgF5gphBGBfZ/CcVWuzREqsRpnhKJTFszjMu71qi5fw02oKzACB+Fe ocey/YrN6QezH0H51xaaQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "precis@ietf.org" Subject: Re: [precis] One change before Last Call X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 05:18:44 -0000 * Pete Resnick wrote: >Your suggestion I think is making too strong a claim, but I see where >you're going. You needn't limit to a single script or otherwise heavily >restrict to stay clear of potential problems; you simply have to stick >to the more restrictive classes provided, or if you need to use >free-form, then restrict to something more limited. So perhaps this >would be clearer, and capture your concern: > > Even so, implementations that are sensitive to the advice given in > this specification (to use the more restrictive String Classes, or > otherwise to only allow a restricted set of characters, particularly > ones whose implications they actually understand) are unlikely to > run into significant problems as a consequence of these issues or > potential changes. This is better, but if I and my implementation do run into significant problems because I did not disallow some characters that I could have disallowed, do you really think that I am to blame? I18N folks tell me to have as few restrictions on characters as possible, while the text above suggests to have as many restrictions as possible. If I fail to find the proper balance myself, in the void that is left by the draft, I think the specification is also responsible. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/ From nobody Wed Feb 4 06:51:03 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51DE01A8843 for ; Wed, 4 Feb 2015 06:51:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gJNO7np9omL for ; Wed, 4 Feb 2015 06:50:59 -0800 (PST) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCBFE1A8784 for ; Wed, 4 Feb 2015 06:50:59 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id ar1so2421319iec.13 for ; Wed, 04 Feb 2015 06:50:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Emn7Kb+wBfAHpsxjcw5tX/CxyjZbsiv8NKX8lIXbPok=; b=ee0MZ2ZWgB96P5j2Qmpbm1VUzAMO+uujGDvqK8zeN6Wix/0+IvGxhNlYYrmJVMbpWn ZFm61cM5lJDGuS9cD4rtbPzaHxqU3qvDdKKvDg+h8dnDg5FJnBtFcqwwICQPuo7duS/b SvrRFos0HFseALKzabMR1sFbUDH+pgVdPic9Je36EFR/+kfn+H6BnQmSSDBkOTVgXs9Q q+Z3umTeD29nOxp5L6odG2ox8FyyLtcgM4wbouoDNcvYqXD3Y0oze794+kkox75NaJRD 9WtP2jfXRCxowBVK66F8fEqeO1iQo37TIIP/T/3R4raMDYuGvzjnL9MVYWD+zZXw6CJH VOsA== X-Gm-Message-State: ALoCoQnkiDWPQ98iG5NfMAC1DoQ1RlTi+n4+3nTlWpH5/NrTUx1qeaOUCAcKZeD0bt+/NgVzg0KU X-Received: by 10.42.88.9 with SMTP id a9mr2145917icm.34.1423061459217; Wed, 04 Feb 2015 06:50:59 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id c70sm982139ioc.3.2015.02.04.06.50.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Feb 2015 06:50:58 -0800 (PST) Message-ID: <54D231D1.20102@andyet.net> Date: Wed, 04 Feb 2015 07:50:57 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Bjoern Hoehrmann , Pete Resnick References: <54D18760.8090100@qti.qualcomm.com> <2423dah4ipo7jhvjr3vq4alidnsk7qdt5v@hive.bjoern.hoehrmann.de> <54D190FB.9060609@qti.qualcomm.com> <54D1A2C7.8020301@qti.qualcomm.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "precis@ietf.org" Subject: Re: [precis] One change before Last Call X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 14:51:01 -0000 On 2/3/15 10:18 PM, Bjoern Hoehrmann wrote: > * Pete Resnick wrote: >> Your suggestion I think is making too strong a claim, but I see where >> you're going. You needn't limit to a single script or otherwise heavily >> restrict to stay clear of potential problems; you simply have to stick >> to the more restrictive classes provided, or if you need to use >> free-form, then restrict to something more limited. So perhaps this >> would be clearer, and capture your concern: >> >> Even so, implementations that are sensitive to the advice given in >> this specification (to use the more restrictive String Classes, or >> otherwise to only allow a restricted set of characters, particularly >> ones whose implications they actually understand) are unlikely to >> run into significant problems as a consequence of these issues or >> potential changes. > > This is better, but if I and my implementation do run into significant > problems because I did not disallow some characters that I could have > disallowed, do you really think that I am to blame? I18N folks tell me > to have as few restrictions on characters as possible, while the text > above suggests to have as many restrictions as possible. If I fail to > find the proper balance myself, in the void that is left by the draft, > I think the specification is also responsible. I'm not sure who these i18n folks are who are telling you to have as few restrictions as possible. The very point of the PRECIS work, in part, has been to define a restricted, safe set of characters that is still expressive enough for most humans - i.e., the IdentifierClass. (The FreeformClass goes in the opposite direction, but then we provide some strong warnings about using that.) Yes, the balance between safety and expressiveness is hard to strike properly, but that's why we've done all this work. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed Feb 4 09:02:20 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 548FD1A8F36 for ; Wed, 4 Feb 2015 09:02:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5cq3X2E63co for ; Wed, 4 Feb 2015 09:02:16 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3456D1A1A09 for ; Wed, 4 Feb 2015 09:02:16 -0800 (PST) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YJ3LA-000LZf-Bq; Wed, 04 Feb 2015 12:02:12 -0500 Date: Wed, 04 Feb 2015 12:02:07 -0500 From: John C Klensin To: Pete Resnick , Bjoern Hoehrmann Message-ID: <1CC9F36F2D7AF58BD7353D80@JcK-HP8200.jck.com> In-Reply-To: <54D1A2C7.8020301@qti.qualcomm.com> References: <54D18760.8090100@qti.qualcomm.com> <2423dah4ipo7jhvjr3vq4alidnsk7qdt5v@hive.bjoern.hoehrmann.de> <54D190FB.9060609@qti.qualcomm.com> <54D1A2C7.8020301@qti.qualcomm.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: precis@ietf.org Subject: Re: [precis] One change before Last Call X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 17:02:18 -0000 --On Tuesday, February 03, 2015 22:40 -0600 Pete Resnick wrote: >... > Your suggestion I think is making too strong a claim, but I > see where you're going. You needn't limit to a single script > or otherwise heavily restrict to stay clear of potential > problems; you simply have to stick to the more restrictive > classes provided, or if you need to use free-form, then > restrict to something more limited. So perhaps this would be > clearer, and capture your concern: >=20 > Even so, implementations that are sensitive to the advice > given in > this specification (to use the more restrictive String > Classes, or > otherwise to only allow a restricted set of characters, > particularly > ones whose implications they actually understand) are > unlikely to > run into significant problems as a consequence of these > issues or > potential changes. Pete, It seems to me that "particularly ones whose implications they actually understand" in this newer phrasing essentially encourages people to allow/use characters whose implications they know they don't understand. I don't think we should encourage that. Ever. It may well happen with FreeFormClass, but I still think we shouldn't encourage it. Bjoern wrote, =20 "I think the text to be added is very clear that implementations should disallow all characters whose implications are not actually understood. If you cannot produce a complete list of all characters implementations should disallow with the current version of the Unicode standard, then my comment seems very applicable to me." We cannot produce such a list, especially in the presence of the issue of decomposability being less predictable than we had assumed, but it is equally possible to have characters in "a single script" (even the script in which one's first language is written) that one does not understand and characters in other scripts that one does. To illustrate the problem within the Latin script, while I might be able to make guesses from his use of a domain in the DE. tree, I would need to claim significantly more understanding than I have to be sure whether "Bjoern" is most properly "Bjoern", "Bj=C3=B6rn" or "Bj=C3=B8rn" and, if the latter, = whether it is expected to be coded as U+00F8 or as \u'006F'\u'0338' (or, for that matter, something else). Anyone who doesn't fully understand that remark probably doesn't fully understand the code points involved. I expect that Bjoern (sic) does understand them, but that many users of the Latin script might not. john From nobody Wed Feb 4 11:44:51 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11FBC1A1BC5 for ; Wed, 4 Feb 2015 11:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92U1td3ROJZ6 for ; Wed, 4 Feb 2015 11:44:38 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D55D1A6FF5 for ; Wed, 4 Feb 2015 11:44:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1423079066; x=1454615066; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=RmyKZfndDO7xVTaxFTWt6vmJ2A4wkH3zN8aDg5BNUUg=; b=iAnC8guNYMVg9PW0ewD6Ra9dKx3qiIV2IBmmO5wE1NcBnSLdBHcam/MR csLBgA/O0Z5pjEvWqjROGsAV8JUUJIq+izi5EG3wY+hsqga6tLPrObx58 IKL3gmx8BufDJE0XT3HkzFOfNlOGE/N7YtdgwOoaLL2KZjC/mpBdB1Gou k=; X-IronPort-AV: E=McAfee;i="5600,1067,7702"; a="83487391" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Feb 2015 11:44:25 -0800 X-IronPort-AV: E=Sophos;i="5.09,519,1418112000"; d="scan'208,217";a="898549451" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 04 Feb 2015 11:44:24 -0800 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 4 Feb 2015 11:44:21 -0800 Message-ID: <54D27694.7080300@qti.qualcomm.com> Date: Wed, 4 Feb 2015 13:44:20 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: John C Klensin References: <54D18760.8090100@qti.qualcomm.com> <2423dah4ipo7jhvjr3vq4alidnsk7qdt5v@hive.bjoern.hoehrmann.de> <54D190FB.9060609@qti.qualcomm.com> <54D1A2C7.8020301@qti.qualcomm.com> <1CC9F36F2D7AF58BD7353D80@JcK-HP8200.jck.com> In-Reply-To: <1CC9F36F2D7AF58BD7353D80@JcK-HP8200.jck.com> Content-Type: multipart/alternative; boundary="------------040501050003020104060504" X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01F.na.qualcomm.com (10.85.0.32) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Cc: Bjoern Hoehrmann , precis@ietf.org Subject: Re: [precis] One change before Last Call X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 19:44:43 -0000 --------------040501050003020104060504 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 2/4/15 11:02 AM, John C Klensin wrote: > --On Tuesday, February 03, 2015 22:40 -0600 Pete Resnick > wrote: > > >> ... >> Your suggestion I think is making too strong a claim, but I >> see where you're going. You needn't limit to a single script >> or otherwise heavily restrict to stay clear of potential >> problems; you simply have to stick to the more restrictive >> classes provided, or if you need to use free-form, then >> restrict to something more limited. So perhaps this would be >> clearer, and capture your concern: >> >> Even so, implementations that are sensitive to the advice >> given in >> this specification (to use the more restrictive String >> Classes, or >> otherwise to only allow a restricted set of characters, >> particularly >> ones whose implications they actually understand) are >> unlikely to >> run into significant problems as a consequence of these >> issues or >> potential changes. >> > Pete, > > It seems to me that "particularly ones whose implications they > actually understand" in this newer phrasing essentially > encourages people to allow/use characters whose implications > they know they don't understand. I don't think we should > encourage that. Ever. It may well happen with FreeFormClass, > but I still think we shouldn't encourage it. > Ah, so perhaps reversing it, and being more specific, would be better: Even so, implementations that are sensitive to the advice given in this specification (to use the more restrictive IdentifierClass whenever possible, or otherwise to only allow a restricted set of characters in the FreeformClass, particularly avoiding ones whose implications they don't actually understand) are unlikely to run into significant problems as a consequence of these issues or potential changes. Is that clearer for everyone? pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------040501050003020104060504 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 2/4/15 11:02 AM, John C Klensin wrote: 
--On Tuesday, February 03, 2015 22:40 -0600 Pete Resnick
<presnick@qti.qualcomm.com> wrote:

  
...
Your suggestion I think is making too strong a claim, but I
see where you're going. You needn't limit to a single script
or otherwise heavily restrict to stay clear of potential
problems; you simply have to stick to the more restrictive
classes provided, or if you need to use free-form, then
restrict to something more limited. So perhaps this would be
clearer, and capture your concern:

    Even so, implementations that are sensitive to the advice
given in
    this specification (to use the more restrictive String
Classes, or
    otherwise to only allow a restricted set of characters,
particularly
    ones whose implications they actually understand) are
unlikely to
    run into significant problems as a consequence of these
issues or
    potential changes.
    
Pete,

It seems to me that "particularly ones whose implications they
actually understand" in this newer phrasing essentially
encourages people to allow/use characters whose implications
they know they don't understand.  I don't think we should
encourage that.  Ever.  It may well happen with FreeFormClass,
but I still think we shouldn't encourage it.

Ah, so perhaps reversing it, and being more specific, would be better:

Even so, implementations that are sensitive to the advice given in this specification (to use the more restrictive IdentifierClass whenever possible, or otherwise to only allow a restricted set of characters in the FreeformClass, particularly avoiding ones whose implications they don't actually understand) are unlikely to run into significant problems as a consequence of these issues or potential changes.

Is that clearer for everyone?

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------040501050003020104060504-- From nobody Wed Feb 4 11:46:51 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71AEA1A6EFE for ; Wed, 4 Feb 2015 11:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXGIILu1UXNr for ; Wed, 4 Feb 2015 11:46:47 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5FBA1A2130 for ; Wed, 4 Feb 2015 11:46:47 -0800 (PST) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YJ5uO-000Lsv-Ne; Wed, 04 Feb 2015 14:46:44 -0500 Date: Wed, 04 Feb 2015 14:46:39 -0500 From: John C Klensin To: Pete Resnick Message-ID: <121BE2891A70D37E4CEE4169@JcK-HP8200.jck.com> In-Reply-To: <54D27694.7080300@qti.qualcomm.com> References: <54D18760.8090100@qti.qualcomm.com> <2423dah4ipo7jhvjr3vq4alidnsk7qdt5v@hive.bjoern.hoehrmann.de> <54D190FB.9060609@qti.qualcomm.com> <54D1A2C7.8020301@qti.qualcomm.com> <1CC9F36F2D7AF58BD7353D80@JcK-HP8200.jck.com> <54D27694.7080300@qti.qualcomm.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: Bjoern Hoehrmann , precis@ietf.org Subject: Re: [precis] One change before Last Call X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 19:46:49 -0000 --On Wednesday, February 04, 2015 13:44 -0600 Pete Resnick wrote: > Ah, so perhaps reversing it, and being more specific, would be > better: > > Even so, implementations that are sensitive to the advice > given in > this specification (to use the more restrictive > IdentifierClass > whenever possible, or otherwise to only allow a restricted > set of > characters in the FreeformClass, particularly avoiding > ones whose > implications they don't actually understand) are unlikely > to run > into significant problems as a consequence of these issues > or > potential changes. > > > Is that clearer for everyone? For me, at least, much clearer and better. So this works for me. john From nobody Wed Feb 4 12:33:06 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44E2A1A1A8D for ; Wed, 4 Feb 2015 12:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIE-CsSqy90g for ; Wed, 4 Feb 2015 12:33:04 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DB1F1A0372 for ; Wed, 4 Feb 2015 12:33:04 -0800 (PST) Received: from crankycanuck.ca (unknown [50.189.173.0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id B9D578A031; Wed, 4 Feb 2015 20:33:02 +0000 (UTC) Date: Wed, 4 Feb 2015 15:32:46 -0500 From: Andrew Sullivan To: Pete Resnick Message-ID: <20150204203246.GA1889@crankycanuck.ca> References: <54D18760.8090100@qti.qualcomm.com> <2423dah4ipo7jhvjr3vq4alidnsk7qdt5v@hive.bjoern.hoehrmann.de> <54D190FB.9060609@qti.qualcomm.com> <54D1A2C7.8020301@qti.qualcomm.com> <1CC9F36F2D7AF58BD7353D80@JcK-HP8200.jck.com> <54D27694.7080300@qti.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <54D27694.7080300@qti.qualcomm.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: Bjoern Hoehrmann , precis@ietf.org Subject: Re: [precis] One change before Last Call X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 20:33:05 -0000 On Wed, Feb 04, 2015 at 01:44:20PM -0600, Pete Resnick wrote: > Ah, so perhaps reversing it, and being more specific, would be better: […] I am happy with that. A -- Andrew Sullivan ajs@crankycanuck.ca From nobody Wed Feb 4 12:44:37 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07151A1B6A for ; Wed, 4 Feb 2015 12:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ciJ6hqXako9r for ; Wed, 4 Feb 2015 12:44:33 -0800 (PST) Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com [209.85.213.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81E141A1A8D for ; Wed, 4 Feb 2015 12:44:33 -0800 (PST) Received: by mail-ig0-f182.google.com with SMTP id h15so6939637igd.3 for ; Wed, 04 Feb 2015 12:44:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8iiTe3HG5tay3fsERaRjdZrghV7rcuGP9YTt9aJW6aA=; b=TChuMvdbXRkY2xTNO1jJkSP+1nokSa5q+a6IcfvrSNFiRWLIJXx2bhnz/Xu+COySQC ASaUwYGMEB2vsl1XQFA8BwGKxlTq+E1HuHKxO/zFJqg6Ff6BmuaBvtSmfIbfHN5HAczx lVl+GbKo+Kjs6rkOsKQy2OZNNvRks8OM0uDj1ZraFJD2j98+J5iCE/pgD9QH5vZ/AHYC vS6PVDzgVy2oITg5wCGtPgzJE7tw1IM0nvLE5/EN4Yjjew5GbuII+cszoMN8dODOzAdQ 13F46huyZfQRt/gU22MpsCBYNCP2Ru9975oAHNPH2mkLcPzn0kOs8jiNiAqmlhWjIq+O pFag== X-Gm-Message-State: ALoCoQlmAJc7cyNOB+ajD39xDh21VO6JpNkYYWwtp1zwUJLKkJa4RJuQ0P1IcamHBNhG10qmjUQt X-Received: by 10.50.137.99 with SMTP id qh3mr4545999igb.7.1423082671936; Wed, 04 Feb 2015 12:44:31 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id h191sm1416083ioh.0.2015.02.04.12.44.31 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Feb 2015 12:44:31 -0800 (PST) Message-ID: <54D284AE.8080707@andyet.net> Date: Wed, 04 Feb 2015 13:44:30 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Andrew Sullivan , Pete Resnick References: <54D18760.8090100@qti.qualcomm.com> <2423dah4ipo7jhvjr3vq4alidnsk7qdt5v@hive.bjoern.hoehrmann.de> <54D190FB.9060609@qti.qualcomm.com> <54D1A2C7.8020301@qti.qualcomm.com> <1CC9F36F2D7AF58BD7353D80@JcK-HP8200.jck.com> <54D27694.7080300@qti.qualcomm.com> <20150204203246.GA1889@crankycanuck.ca> In-Reply-To: <20150204203246.GA1889@crankycanuck.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Bjoern Hoehrmann , precis@ietf.org Subject: Re: [precis] One change before Last Call X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 20:44:34 -0000 On 2/4/15 1:32 PM, Andrew Sullivan wrote: > On Wed, Feb 04, 2015 at 01:44:20PM -0600, Pete Resnick wrote: >> Ah, so perhaps reversing it, and being more specific, would be better: > > […] > > I am happy with that. Ditto. Peter From nobody Wed Feb 4 12:47:58 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9061A6F0E for ; Wed, 4 Feb 2015 12:47:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sq-gLD7qIakK for ; Wed, 4 Feb 2015 12:47:55 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EED81A1A8D for ; Wed, 4 Feb 2015 12:47:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1423082875; x=1454618875; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=a0dl7oSGILRCxNOB01euoHAZbdu5D5xM2u83p6QAUCE=; b=O0T/dhWvCJHRTAVUxENSKef2rPK4w7OjKQ2U3qNQJlWUhwyeZpfxe2D5 3b2xTt+Whg4tiMX5FbnUPxvq/5cfstSdh+CyVvpCDscpqHPE9Mdq+8yzv 0CYrs8Pg32/TN7aSyiBX+D7HZo8+BvdPDKzK32drM/jps1a5GVUc8ptCU o=; X-IronPort-AV: E=McAfee;i="5600,1067,7702"; a="101907350" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Feb 2015 12:47:55 -0800 X-IronPort-AV: E=Sophos;i="5.09,519,1418112000"; d="scan'208";a="807632043" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 04 Feb 2015 12:47:55 -0800 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 4 Feb 2015 12:47:53 -0800 Message-ID: <54D28578.9000900@qti.qualcomm.com> Date: Wed, 4 Feb 2015 14:47:52 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Peter Saint-Andre - &yet References: <54D18760.8090100@qti.qualcomm.com> <2423dah4ipo7jhvjr3vq4alidnsk7qdt5v@hive.bjoern.hoehrmann.de> <54D190FB.9060609@qti.qualcomm.com> <54D1A2C7.8020301@qti.qualcomm.com> <1CC9F36F2D7AF58BD7353D80@JcK-HP8200.jck.com> <54D27694.7080300@qti.qualcomm.com> <20150204203246.GA1889@crankycanuck.ca> <54D284AE.8080707@andyet.net> In-Reply-To: <54D284AE.8080707@andyet.net> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01D.na.qualcomm.com (10.85.0.84) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Cc: Andrew Sullivan , Bjoern Hoehrmann , precis@ietf.org Subject: Re: [precis] One change before Last Call X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 20:47:56 -0000 On 2/4/15 2:44 PM, Peter Saint-Andre - &yet wrote: > On 2/4/15 1:32 PM, Andrew Sullivan wrote: >> On Wed, Feb 04, 2015 at 01:44:20PM -0600, Pete Resnick wrote: >>> Ah, so perhaps reversing it, and being more specific, would be better: >> >> […] >> >> I am happy with that. > > Ditto. I love the sound of growing consensus. :-) Give Björn (and anyone else, for that matter) a bit of time to yelp, but then feel free to publish a new version with the agreed text and I'll send out the Last Call. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Wed Feb 4 13:05:36 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B439F1A1A33 for ; Wed, 4 Feb 2015 13:05:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzsVwG5BmNio for ; Wed, 4 Feb 2015 13:05:21 -0800 (PST) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5EA21A1ABB for ; Wed, 4 Feb 2015 13:05:20 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id rd18so5252616iec.9 for ; Wed, 04 Feb 2015 13:05:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=F2zTSBNZcKpRqAY82KeICApbRgPPm9UFYu/WPaRM6Lo=; b=K2MTxUWH+vLo5LrCSnXovCSgjiPrPYzR2Oegas2cFI4T3uV6IZc2Nr04ZNevrPpFiS oeuuyC9Xgec57tlD05tS2hch9wj47nyI7vDJHjYOt0a7sLeoldd1EGk0fd37XxnkOIpn fYguCUUi1truREmFPL7rpGVcrpxV7Oj6It6Ra2BzxxjTVuNvArN3ymrcAzu1PdZUlEV6 NMqHZscckgblLJ+1PVx7IIvo9zcKJrtZc8pyVs9MduABRvbKuwvwZmCyVjgCvW0JjNL7 VWdagZcsj3uMLSPK5urIgAhxxwbVJELCANLua5gZyHd76yWyqAVlFHhqJbsHGe9gpG1T DYgw== X-Gm-Message-State: ALoCoQlGRyoW910YUUJjquyyaPDb+qGGqwdTnwtoGXjyXIGKKISc8YnJMBgO4b1+llbBhpGd2wgb X-Received: by 10.107.131.68 with SMTP id f65mr394404iod.70.1423083920099; Wed, 04 Feb 2015 13:05:20 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id m77sm1416858iom.38.2015.02.04.13.05.19 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Feb 2015 13:05:19 -0800 (PST) Message-ID: <54D2898E.1020400@andyet.net> Date: Wed, 04 Feb 2015 14:05:18 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Pete Resnick References: <54D18760.8090100@qti.qualcomm.com> <2423dah4ipo7jhvjr3vq4alidnsk7qdt5v@hive.bjoern.hoehrmann.de> <54D190FB.9060609@qti.qualcomm.com> <54D1A2C7.8020301@qti.qualcomm.com> <1CC9F36F2D7AF58BD7353D80@JcK-HP8200.jck.com> <54D27694.7080300@qti.qualcomm.com> <20150204203246.GA1889@crankycanuck.ca> <54D284AE.8080707@andyet.net> <54D28578.9000900@qti.qualcomm.com> In-Reply-To: <54D28578.9000900@qti.qualcomm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Andrew Sullivan , Bjoern Hoehrmann , precis@ietf.org Subject: Re: [precis] One change before Last Call X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 21:05:30 -0000 On 2/4/15 1:47 PM, Pete Resnick wrote: > On 2/4/15 2:44 PM, Peter Saint-Andre - &yet wrote: >> On 2/4/15 1:32 PM, Andrew Sullivan wrote: >>> On Wed, Feb 04, 2015 at 01:44:20PM -0600, Pete Resnick wrote: >>>> Ah, so perhaps reversing it, and being more specific, would be better: >>> >>> […] >>> >>> I am happy with that. >> >> Ditto. > > I love the sound of growing consensus. :-) > > Give Björn (and anyone else, for that matter) a bit of time to yelp, but > then feel free to publish a new version with the agreed text and I'll > send out the Last Call. Excellent. BTW, I am thinking that this new text would be best in the Interoperability Considerations section. Does that seem right? Peter From nobody Wed Feb 4 22:04:29 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A381B1A1AA0 for ; Wed, 4 Feb 2015 22:04:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbpbwVh3QdzN for ; Wed, 4 Feb 2015 22:04:23 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D7591A1A9D for ; Wed, 4 Feb 2015 22:04:22 -0800 (PST) Received: from netb ([82.113.98.237]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MWgND-1Y7YDa10pf-00XrUQ; Thu, 05 Feb 2015 07:04:19 +0100 From: Bjoern Hoehrmann To: Pete Resnick Date: Thu, 05 Feb 2015 07:04:18 +0100 Message-ID: References: <54D18760.8090100@qti.qualcomm.com> <2423dah4ipo7jhvjr3vq4alidnsk7qdt5v@hive.bjoern.hoehrmann.de> <54D190FB.9060609@qti.qualcomm.com> <54D1A2C7.8020301@qti.qualcomm.com> <1CC9F36F2D7AF58BD7353D80@JcK-HP8200.jck.com> <54D27694.7080300@qti.qualcomm.com> In-Reply-To: <54D27694.7080300@qti.qualcomm.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:eiTA2bOyfxtRJ3FdY/2PdazmyfcAaFdAIz8GNqjoxgOpgG6WQTJ ILO3qLcNqryUxmyM6gD6cIQUvGrq0Uc28py1EpFsvZvRGy87XsBPCYuI0WZVeI1yVA9MQMV Lfm+nMAm39Rb7pQRiTBH/fLvb4/bJ22YX4OhlzoH5sSBKR1a3Olmsvsv1NoYOXw2qhxYQ4l qbvo8xJIVkOq5/M3LPKXg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: precis@ietf.org Subject: Re: [precis] One change before Last Call X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 06:04:27 -0000 * Pete Resnick wrote: >Ah, so perhaps reversing it, and being more specific, would be better: > > Even so, implementations that are sensitive to the advice given in > this specification (to use the more restrictive IdentifierClass > whenever possible, or otherwise to only allow a restricted set of > characters in the FreeformClass, particularly avoiding ones whose > implications they don't actually understand) are unlikely to run > into significant problems as a consequence of these issues or > potential changes. > >Is that clearer for everyone? Yes, thank you. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/ From nobody Wed Feb 4 22:44:18 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4FD1A0203 for ; Wed, 4 Feb 2015 22:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkLhy0UnghK3 for ; Wed, 4 Feb 2015 22:44:16 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4125B1A017C for ; Wed, 4 Feb 2015 22:44:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1423118656; x=1454654656; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=3i0qKGA2XqCeaJz84duLWRwhQjGx6WcVlk0Kb1zQFU8=; b=rSUfFTrVU/CfdRQ/4s5qJF9lGyJlvYIVKghAZj9blvzL9+otBbJ5KVA4 0/ttrp1GZI+NzonupEcRgBGJHLvHPABk5zyul6wP0UFM9EBCVIdfDITZk Ixc0YKLB0Zhx32OFuFHPbvKWgw5U1LK++9Z5QZfqFnIG1dGdDndksW2eF U=; X-IronPort-AV: E=McAfee;i="5600,1067,7702"; a="83514266" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Feb 2015 22:44:15 -0800 X-IronPort-AV: E=Sophos;i="5.09,522,1418112000"; d="scan'208";a="898908096" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 04 Feb 2015 22:44:15 -0800 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 4 Feb 2015 22:44:14 -0800 Message-ID: <54D3113D.208@qti.qualcomm.com> Date: Thu, 5 Feb 2015 00:44:13 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Peter Saint-Andre - &yet References: <54D18760.8090100@qti.qualcomm.com> <2423dah4ipo7jhvjr3vq4alidnsk7qdt5v@hive.bjoern.hoehrmann.de> <54D190FB.9060609@qti.qualcomm.com> <54D1A2C7.8020301@qti.qualcomm.com> <1CC9F36F2D7AF58BD7353D80@JcK-HP8200.jck.com> <54D27694.7080300@qti.qualcomm.com> <20150204203246.GA1889@crankycanuck.ca> <54D284AE.8080707@andyet.net> <54D28578.9000900@qti.qualcomm.com> <54D2898E.1020400@andyet.net> In-Reply-To: <54D2898E.1020400@andyet.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (10.85.0.81) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Cc: Andrew Sullivan , Bjoern Hoehrmann , precis@ietf.org Subject: Re: [precis] One change before Last Call X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 06:44:17 -0000 On 2/4/15 3:05 PM, Peter Saint-Andre - &yet wrote: > I am thinking that this new text would be best in the Interoperability > Considerations section. Does that seem right? I think that's reasonable. Perhaps split it, and make "13.1 General Considerations" and "13.2 ???". It's a bit separate, so I don't know that it should just be added as a paragraph, but I don't have a good subsection title. I'll leave it to the authors. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Thu Feb 5 02:24:28 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1780B1A0211 for ; Thu, 5 Feb 2015 02:24:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.098 X-Spam-Level: ** X-Spam-Status: No, score=2.098 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9an29aUDH-Vo for ; Thu, 5 Feb 2015 02:24:11 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 03F081A0231 for ; Thu, 5 Feb 2015 02:24:11 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id B0F3B32E56A; Thu, 5 Feb 2015 19:23:25 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 70d6_923d_aee65eb7_96a4_4afd_801c_127c4c8fecd8; Thu, 05 Feb 2015 19:23:25 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id D5C67BF537; Thu, 5 Feb 2015 19:23:24 +0900 (JST) Message-ID: <54D3449B.10306@it.aoyama.ac.jp> Date: Thu, 05 Feb 2015 19:23:23 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Bjoern Hoehrmann , Pete Resnick References: <54D18760.8090100@qti.qualcomm.com> <2423dah4ipo7jhvjr3vq4alidnsk7qdt5v@hive.bjoern.hoehrmann.de> <54D190FB.9060609@qti.qualcomm.com> <54D1A2C7.8020301@qti.qualcomm.com> <1CC9F36F2D7AF58BD7353D80@JcK-HP8200.jck.com> <54D27694.7080300@qti.qualcomm.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: precis@ietf.org Subject: Re: [precis] One change before Last Call X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 10:24:14 -0000 On 2015/02/05 15:04, Bjoern Hoehrmann wrote: > * Pete Resnick wrote: >> Ah, so perhaps reversing it, and being more specific, would be better: >> >> Even so, implementations that are sensitive to the advice given in >> this specification (to use the more restrictive IdentifierClass >> whenever possible, or otherwise to only allow a restricted set of >> characters in the FreeformClass, particularly avoiding ones whose >> implications they don't actually understand) are unlikely to run >> into significant problems as a consequence of these issues or >> potential changes. >> >> Is that clearer for everyone? > > Yes, thank you. > I think the above should work. Giving that it's the most busy time of the Japanese academic year, I haven't been able to follow the discussion in as much detail as I would have wanted, but I remember that quite some time ago, I was very much concerned by phrases along the line of "only allow those characters whose implications they fully understand". Except maybe for two or three people on the Unicode Technical Committee I know, I wouldn't want to claim that anybody knows the implications of even a significant (in terms of size and use) part of the Unicode repertoire. And for the average implementer or system administrator, it's of course much less. But we definitely don't want that to lead to a situation where we go back to (some time) last century and ASCII only. Given that the text is now very clearly predicated on FreeformClass, which is indeed wide open, it looks okay. Regards, Martin. From nobody Thu Feb 5 05:46:14 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2B361A886D for ; Thu, 5 Feb 2015 05:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.159 X-Spam-Level: X-Spam-Status: No, score=0.159 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzdw8RcskOk3 for ; Thu, 5 Feb 2015 05:46:10 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37DA71A8763 for ; Thu, 5 Feb 2015 05:46:10 -0800 (PST) Received: from [10.152.98.56] (unknown [199.119.233.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 3934F8A031; Thu, 5 Feb 2015 13:46:08 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Andrew Sullivan X-Mailer: iPhone Mail (11D257) In-Reply-To: <54D3449B.10306@it.aoyama.ac.jp> Date: Thu, 5 Feb 2015 08:46:04 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54D18760.8090100@qti.qualcomm.com> <2423dah4ipo7jhvjr3vq4alidnsk7qdt5v@hive.bjoern.hoehrmann.de> <54D190FB.9060609@qti.qualcomm.com> <54D1A2C7.8020301@qti.qualcomm.com> <1CC9F36F2D7AF58BD7353D80@JcK-HP8200.jck.com> <54D27694.7080300@qti.qualcomm.com> <54D3449B.10306@it.aoyama.ac.jp> To: =?utf-8?Q?"Martin_J._D=C3=BCrst"?= Archived-At: Cc: Pete Resnick , Bjoern Hoehrmann , "precis@ietf.org" Subject: Re: [precis] One change before Last Call X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 13:46:11 -0000 If you're reading the text as implying that IdentifierClass is somehow guara= nteed safe, then I _think_ we still have a problem, because I don't think it= says that and anyway it isn't true. =20 A --=20 Andrew Sullivan=20 Please excuse my clumbsy thums.=20 > On Feb 5, 2015, at 5:23, "Martin J. D=C3=BCrst" w= rote: >=20 >> On 2015/02/05 15:04, Bjoern Hoehrmann wrote: >> * Pete Resnick wrote: >>> Ah, so perhaps reversing it, and being more specific, would be better: >>>=20 >>> Even so, implementations that are sensitive to the advice given in >>> this specification (to use the more restrictive IdentifierClass >>> whenever possible, or otherwise to only allow a restricted set of >>> characters in the FreeformClass, particularly avoiding ones whose >>> implications they don't actually understand) are unlikely to run >>> into significant problems as a consequence of these issues or >>> potential changes. >>>=20 >>> Is that clearer for everyone? >>=20 >> Yes, thank you. >=20 > I think the above should work. Giving that it's the most busy time of the J= apanese academic year, I haven't been able to follow the discussion in as mu= ch detail as I would have wanted, but I remember that quite some time ago, I= was very much concerned by phrases along the line of "only allow those char= acters whose implications they fully understand". >=20 > Except maybe for two or three people on the Unicode Technical Committee I k= now, I wouldn't want to claim that anybody knows the implications of even a s= ignificant (in terms of size and use) part of the Unicode repertoire. And fo= r the average implementer or system administrator, it's of course much less.= But we definitely don't want that to lead to a situation where we go back t= o (some time) last century and ASCII only. >=20 > Given that the text is now very clearly predicated on FreeformClass, which= is indeed wide open, it looks okay. >=20 > Regards, Martin. >=20 > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis From nobody Thu Feb 5 07:59:02 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A9B1A8838 for ; Thu, 5 Feb 2015 07:59:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.39 X-Spam-Level: X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puSdykCYSWdo for ; Thu, 5 Feb 2015 07:58:58 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F6091A8868 for ; Thu, 5 Feb 2015 07:58:55 -0800 (PST) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YJOpO-000Oin-O6; Thu, 05 Feb 2015 10:58:50 -0500 Date: Thu, 05 Feb 2015 10:58:45 -0500 From: John C Klensin To: =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= , Pete Resnick Message-ID: <916E45ADE98041A7C3A959D7@JcK-HP8200.jck.com> In-Reply-To: <54D3449B.10306@it.aoyama.ac.jp> References: <54D18760.8090100@qti.qualcomm.com> <2423dah4ipo7jhvjr3vq4alidnsk7qdt5v@hive.bjoern.hoehrmann.de> <54D190FB.9060609@qti.qualcomm.com> <54D1A2C7.8020301@qti.qualcomm.com> <1CC9F36F2D7AF58BD7353D80@JcK-HP8200.jck.com> <54D27694.7080300@qti.qualcomm.com> <54D3449B.10306@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-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: precis@ietf.org Subject: Re: [precis] One change before Last Call X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 15:59:00 -0000 --On Thursday, February 05, 2015 19:23 +0900 "\"Martin J. D=C3=BCrst\"" wrote: >... > I think the above should work. Giving that it's the most busy > time of the Japanese academic year, I haven't been able to > follow the discussion in as much detail as I would have > wanted, but I remember that quite some time ago, I was very > much concerned by phrases along the line of "only allow those > characters whose implications they fully understand". >=20 > Except maybe for two or three people on the Unicode Technical > Committee I know, I wouldn't want to claim that anybody knows > the implications of even a significant (in terms of size and > use) part of the Unicode repertoire. And for the average > implementer or system administrator, it's of course much less. > But we definitely don't want that to lead to a situation where > we go back to (some time) last century and ASCII only. Martin, I don't see how you get from there to "ASCII only". First, there are a lot of people in the world who don't "understand the implications of" Latin Script, even the basic undecorated Latin characters and even though they might use them. I think that, while it may require some effort on their part, it is reasonable to expect implementers and system administrators who establish rules for identifiers to take responsibility for understanding the use and possible risks associated with the characters of their own scripts, especially the subset of those characters that are relevant to their own languages. =20 I recognize that makes it hard to design software systems that are somehow internationally script-insensitive where identifiers are concerned, but I think we have to live with that as the price of the diversity of human languages and writing systems. It may also imply a need for software implementations that are far more rule-driven, possibly with locally-tailorable rules for individual scripts, languages, and context, rather than an approach that is construed as "this magic table of characters is ok". Again, that may be the price of the diversity of human writing system and, by looking at tables and global profiles, we may just be in denial about that diversity and its implications. None of the above is made any easier by Unicode decisions, however justified by the same diversity issues, pushing us from design principles that apply to all of the coding system, to design principles that are different on a per-script basis, to specific and exception-driven rules such as "normalization does all of the right comparison things within the Latin script except for the following code points for which decomposition is appropriate under some circumstances but not others" or "there are case matching rules that are universally applicable except for certain specific locales and code points, where special treatment is needed". It may be that we have been in denial, that the whole concept of identifiers without language context is unworkable for at least some protocols, and that we should be thinking of an "internationalized identifier" as a tuple with a string and language identifier. Comparisons would then depend, not on catenation and bit-by-bit comparison but on=20 consideration of the language identifier based on RFC 4647 and then interpretation and comparison of the string based on that information. That suggests that we should finish the PRECIS work based on current documents rather than looking for a more prefect solution (or textual phrasing) now. However, it does also suggest that, for at least some purposes, the PRECIS work may be a waypoint rather than a final answer. john From nobody Thu Feb 5 08:25:00 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585BD1A884B for ; Thu, 5 Feb 2015 08:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.601 X-Spam-Level: X-Spam-Status: No, score=-4.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bU6S9yWAZDf for ; Thu, 5 Feb 2015 08:24:57 -0800 (PST) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A58231A8761 for ; Thu, 5 Feb 2015 08:24:56 -0800 (PST) Received: by mail-ig0-f179.google.com with SMTP id l13so14008459iga.0 for ; Thu, 05 Feb 2015 08:24:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=q5Sm+vkCEe6ks74/sEWjGg69Yi6lwRjcBoMbIMBkrsw=; b=ffWWtgps19cgfqfWzH0OaJkxMg7W+XPzaPu3JhuMriJB1FU0Fv/26dDr4B3gVa7eMQ C74lBO/73rT9Sz3UUknOXVlQVo/DvYTBTqVShu5uDCDmp72H4kVAmTSaQbeh2TrFdkit bO6nQShzlOgsUOGiu+sqyiBi2uYErCX/FBjr66TaR3zC4W2+myU39LxeIL2SZ6ib/YJJ Q+XBJDy20UZlst2fyt3R1zz4gmpQpqIHPptXBifIXPhaVrmy8rCjcX6iLnOvlGBDBDTi sQgWPY5KZX/xi11f1trSdSr4KKmoX3Z/yJyIYDFTW4d+xddRu8PVNfudrHlJ7zNwuA/o FPaA== X-Gm-Message-State: ALoCoQm1h42kkO4s6FK1sVzrChrSL1Y8LdxyVCSDl6ECTGdt6ENNZ31kEmMlZHjmlZ5TbgsPJj+K X-Received: by 10.107.159.16 with SMTP id i16mr5286568ioe.81.1423153494709; Thu, 05 Feb 2015 08:24:54 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id p15sm2656291ioe.44.2015.02.05.08.24.53 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Feb 2015 08:24:53 -0800 (PST) Message-ID: <54D39954.1000806@andyet.net> Date: Thu, 05 Feb 2015 09:24:52 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Pete Resnick References: <54D18760.8090100@qti.qualcomm.com> <2423dah4ipo7jhvjr3vq4alidnsk7qdt5v@hive.bjoern.hoehrmann.de> <54D190FB.9060609@qti.qualcomm.com> <54D1A2C7.8020301@qti.qualcomm.com> <1CC9F36F2D7AF58BD7353D80@JcK-HP8200.jck.com> <54D27694.7080300@qti.qualcomm.com> <20150204203246.GA1889@crankycanuck.ca> <54D284AE.8080707@andyet.net> <54D28578.9000900@qti.qualcomm.com> <54D2898E.1020400@andyet.net> <54D3113D.208@qti.qualcomm.com> In-Reply-To: <54D3113D.208@qti.qualcomm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Andrew Sullivan , Bjoern Hoehrmann , precis@ietf.org Subject: Re: [precis] One change before Last Call X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 16:24:58 -0000 On 2/4/15 11:44 PM, Pete Resnick wrote: > On 2/4/15 3:05 PM, Peter Saint-Andre - &yet wrote: >> I am thinking that this new text would be best in the Interoperability >> Considerations section. Does that seem right? > > I think that's reasonable. Perhaps split it, and make "13.1 General > Considerations" and "13.2 ???". It's a bit separate, so I don't know > that it should just be added as a paragraph, but I don't have a good > subsection title. I'll leave it to the authors. Here is what I have in my working copy. Please note that to improve readability I broke up some of the sentences in the long paragraph we all agreed to. Please review. ### 13. Interoperability Considerations 13.1. Encoding Although strings that are consumed in PRECIS-based application protocols are often encoded using UTF-8 [RFC3629], the exact encoding is a matter for the application protocol that uses PRECIS, not for the PRECIS framework. 13.2. Character Sets It is known that some existing systems are unable to support the full Unicode character set, or even any characters outside the ASCII range. If two (or more) applications need to interoperate when exchanging data (e.g., for the purpose of authenticating a username or password), they will naturally need to have in common at least one coded character set (as defined by [RFC6365]). Establishing such a baseline is a matter for the application protocol that uses PRECIS, not for the PRECIS framework. 13.3. Unicode Versions Changes to the properties of Unicode code points can occur as the Unicode Standard is modified from time to time. For example, three code points underwent changes in their GeneralCategory between Unicode 5.2 (current at the time IDNA2008 was originally published) and Unicode 6.0, as described in [RFC6452]. Implementers might need to be aware that the treatment of these characters differs depending on which version of Unicode is available on the system that is using IDNA2008 or PRECIS. Other such differences might arise between the version of Unicode current at the time of this writing (7.0) and future versions. 13.4. Potential Changes to Handling of Certain Unicode Code Points As part of the review of Unicode 7.0 for IDNA, a question was raised about a newly-added code point that led to a re-analysis of the Normalization Rules used by IDNA and inherited by this document (Section 5.2.4). Some of the general issues are described in [IAB-Statement] and pursued in more detail in [I-D.klensin-idna-5892upd-unicode70]. At the time of writing, these issues have yet to be settled. However, implementers need to be aware that this specification is likely to be updated in the future to address these issues. The potential changes include: o The range of characters in the LetterDigits category (Section 4.2.1 and Section 9.1) might be narrowed. o Some characters with special properties that are now allowed might be excluded. o More "Additional Mapping Rules" (Section 5.2.2) might be defined. o Alternative normalization methods might be added. Nevertheless, implementations and deployments that are sensitive to the advice given in this specification are unlikely to run into significant problems as a consequence of these issues or potential changes - specifically the advice to use the more restrictive IdentifierClass whenever possible, or if using the FreeformClass to allow only a restricted set of characters, particularly avoiding characters whose implications they do not actually understand. ### From nobody Thu Feb 5 09:32:37 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A1B1A0469 for ; Thu, 5 Feb 2015 09:32:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.011 X-Spam-Level: X-Spam-Status: No, score=-9.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7hQh0Hq7zKA for ; Thu, 5 Feb 2015 09:32:33 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27A521A1A90 for ; Thu, 5 Feb 2015 09:32:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1423157553; x=1454693553; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Cd+D/1hM3RkI/1dHqgyrNz1K5O1Efb3krkdhFcK4pxA=; b=ce6PTS+t/8t/BMcNfN6pZC0DbPEEp7rpyxk3Pd5goO3g6wR3aVH1c6ZQ fhafcg35yLUrMIX4Ff+oOgrtCLvurjzBLb358ZqbVsThGeUze5Fjuay/v jOpIYJi1q9yOyVEWEkL5zv6rwi2a9HBqrOpj+rAgh1pAUM4jPn9hQDqFj M=; X-IronPort-AV: E=McAfee;i="5600,1067,7702"; a="102100830" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Feb 2015 09:32:32 -0800 X-IronPort-AV: E=Sophos;i="5.09,524,1418112000"; d="scan'208";a="899235091" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 05 Feb 2015 09:32:32 -0800 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 5 Feb 2015 09:32:31 -0800 Message-ID: <54D3A92D.3060305@qti.qualcomm.com> Date: Thu, 5 Feb 2015 11:32:29 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Peter Saint-Andre - &yet References: <54D18760.8090100@qti.qualcomm.com> <2423dah4ipo7jhvjr3vq4alidnsk7qdt5v@hive.bjoern.hoehrmann.de> <54D190FB.9060609@qti.qualcomm.com> <54D1A2C7.8020301@qti.qualcomm.com> <1CC9F36F2D7AF58BD7353D80@JcK-HP8200.jck.com> <54D27694.7080300@qti.qualcomm.com> <20150204203246.GA1889@crankycanuck.ca> <54D284AE.8080707@andyet.net> <54D28578.9000900@qti.qualcomm.com> <54D2898E.1020400@andyet.net> <54D3113D.208@qti.qualcomm.com> <54D39954.1000806@andyet.net> In-Reply-To: <54D39954.1000806@andyet.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01B.na.qualcomm.com (10.85.0.82) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Cc: Andrew Sullivan , Bjoern Hoehrmann , precis@ietf.org Subject: Re: [precis] One change before Last Call X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 17:32:36 -0000 Looks good to me. pr On 2/5/15 10:24 AM, Peter Saint-Andre - &yet wrote: > On 2/4/15 11:44 PM, Pete Resnick wrote: >> On 2/4/15 3:05 PM, Peter Saint-Andre - &yet wrote: >>> I am thinking that this new text would be best in the Interoperability >>> Considerations section. Does that seem right? >> >> I think that's reasonable. Perhaps split it, and make "13.1 General >> Considerations" and "13.2 ???". It's a bit separate, so I don't know >> that it should just be added as a paragraph, but I don't have a good >> subsection title. I'll leave it to the authors. > > Here is what I have in my working copy. Please note that to improve > readability I broke up some of the sentences in the long paragraph we > all agreed to. Please review. > > ### > > 13. Interoperability Considerations > > 13.1. Encoding > > Although strings that are consumed in PRECIS-based application > protocols are often encoded using UTF-8 [RFC3629], the exact encoding > is a matter for the application protocol that uses PRECIS, not for > the PRECIS framework. > > 13.2. Character Sets > > It is known that some existing systems are unable to support the full > Unicode character set, or even any characters outside the ASCII > range. If two (or more) applications need to interoperate when > exchanging data (e.g., for the purpose of authenticating a username > or password), they will naturally need to have in common at least one > coded character set (as defined by [RFC6365]). Establishing such a > baseline is a matter for the application protocol that uses PRECIS, > not for the PRECIS framework. > > 13.3. Unicode Versions > > Changes to the properties of Unicode code points can occur as the > Unicode Standard is modified from time to time. For example, three > code points underwent changes in their GeneralCategory between > Unicode 5.2 (current at the time IDNA2008 was originally published) > and Unicode 6.0, as described in [RFC6452]. Implementers might need > to be aware that the treatment of these characters differs depending > on which version of Unicode is available on the system that is using > IDNA2008 or PRECIS. Other such differences might arise between the > version of Unicode current at the time of this writing (7.0) and > future versions. > > 13.4. Potential Changes to Handling of Certain Unicode Code Points > > As part of the review of Unicode 7.0 for IDNA, a question was raised > about a newly-added code point that led to a re-analysis of the > Normalization Rules used by IDNA and inherited by this document > (Section 5.2.4). Some of the general issues are described in > [IAB-Statement] and pursued in more detail in > [I-D.klensin-idna-5892upd-unicode70]. > > At the time of writing, these issues have yet to be settled. > However, implementers need to be aware that this specification is > likely to be updated in the future to address these issues. The > potential changes include: > > o The range of characters in the LetterDigits category > (Section 4.2.1 and Section 9.1) might be narrowed. > > o Some characters with special properties that are now allowed might > be excluded. > > o More "Additional Mapping Rules" (Section 5.2.2) might be defined. > > o Alternative normalization methods might be added. > > Nevertheless, implementations and deployments that are sensitive to > the advice given in this specification are unlikely to run into > significant problems as a consequence of these issues or potential > changes - specifically the advice to use the more restrictive > IdentifierClass whenever possible, or if using the FreeformClass to > allow only a restricted set of characters, particularly avoiding > characters whose implications they do not actually understand. > > ### > > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Thu Feb 5 09:41:41 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3504B1A0A85 for ; Thu, 5 Feb 2015 09:41:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbnFu3n1-5Uv for ; Thu, 5 Feb 2015 09:41:24 -0800 (PST) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E4A41A0377 for ; Thu, 5 Feb 2015 09:41:24 -0800 (PST) Received: by mail-ig0-f176.google.com with SMTP id hl2so45941589igb.3 for ; Thu, 05 Feb 2015 09:41:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0ejC6TVuovcGVU0COByOAwF7ElsVc0GoECEAdmiaLbc=; b=fnvLV2NQU5i8sDo+T+Y5l3qBfAs9Sfz5f21W0CmJn7S+H7wpphLOdo9eQTvg5B89LI M8rEdIg7SAQVTCZANWD3bToZJnqF+jOFB6nSCewY91uZ3lv+cGUac5uVOuuxaEQCJyPe Nf6JAERNIN7Eem2q/FXBd7tbphysQSmQJ7kPlviI9nxnufWuuUw03emXqRBZx0WKJsuS 2GPN8GhZNvohh00m3BlsNlWw9LPdbACuUfKcs7ElpunaA8xVVWqoOijzFggOcR8IbhOK 3ykdSaE3Kk8yOQYQ2HBptz1eDdUOJBm3t2vBhfdjEYjv2mtWEWElS2GC8CIjSwK4SkDJ o5Jw== X-Gm-Message-State: ALoCoQnN0wB2q9c9MRr6LP+BncKYwhwLkD31kcMqZF3uL90oeBodvujs1t77/SBGUP4y1GkIiw0k X-Received: by 10.50.119.9 with SMTP id kq9mr10335308igb.36.1423158083611; Thu, 05 Feb 2015 09:41:23 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id b6sm2824249igb.15.2015.02.05.09.41.22 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Feb 2015 09:41:23 -0800 (PST) Message-ID: <54D3AB41.5030602@andyet.net> Date: Thu, 05 Feb 2015 10:41:21 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Pete Resnick References: <54D18760.8090100@qti.qualcomm.com> <2423dah4ipo7jhvjr3vq4alidnsk7qdt5v@hive.bjoern.hoehrmann.de> <54D190FB.9060609@qti.qualcomm.com> <54D1A2C7.8020301@qti.qualcomm.com> <1CC9F36F2D7AF58BD7353D80@JcK-HP8200.jck.com> <54D27694.7080300@qti.qualcomm.com> <20150204203246.GA1889@crankycanuck.ca> <54D284AE.8080707@andyet.net> <54D28578.9000900@qti.qualcomm.com> <54D2898E.1020400@andyet.net> <54D3113D.208@qti.qualcomm.com> <54D39954.1000806@andyet.net> <54D3A92D.3060305@qti.qualcomm.com> In-Reply-To: <54D3A92D.3060305@qti.qualcomm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Andrew Sullivan , Bjoern Hoehrmann , precis@ietf.org Subject: Re: [precis] One change before Last Call X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 17:41:28 -0000 On 2/5/15 10:32 AM, Pete Resnick wrote: > Looks good to me. OK, I shall submit -22. Peter From nobody Thu Feb 5 09:48:14 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D531A87DB; Thu, 5 Feb 2015 09:48:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64ik2TzmX9Ry; Thu, 5 Feb 2015 09:48:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A70391A897D; Thu, 5 Feb 2015 09:47:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150205174751.25312.70373.idtracker@ietfa.amsl.com> Date: Thu, 05 Feb 2015 09:47:51 -0800 Archived-At: Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-framework-22.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 17:48:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Preparation and Comparison of Internationalized Strings Working Group of the IETF. Title : PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols Authors : Peter Saint-Andre Marc Blanchet Filename : draft-ietf-precis-framework-22.txt Pages : 38 Date : 2015-02-05 Abstract: Application protocols using Unicode characters in protocol strings need to properly handle such strings in order to enforce internationalization rules for strings placed in various protocol slots (such as addresses and identifiers) and to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation, enforcement, and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode characters and thus is agile with respect to versions of Unicode. As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454). This document obsoletes RFC 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-22 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-framework-22 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 5 09:48:23 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4DC01A87DB; Thu, 5 Feb 2015 09:48:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgIARKjAbO3M; Thu, 5 Feb 2015 09:48:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC2BB1A03A0; Thu, 5 Feb 2015 09:47:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: precis-chairs@ietf.org, draft-ietf-precis-framework@ietf.org, precis@ietf.org, presnick@qti.qualcomm.com X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150205174751.25312.27200.idtracker@ietfa.amsl.com> Date: Thu, 05 Feb 2015 09:47:51 -0800 Archived-At: Subject: [precis] New Version Notification - draft-ietf-precis-framework-22.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 17:48:13 -0000 A new version (-22) has been submitted for draft-ietf-precis-framework: http://www.ietf.org/internet-drafts/draft-ietf-precis-framework-22.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-framework/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-framework-22 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. IETF Secretariat. From nobody Thu Feb 5 11:04:22 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08FA81A8A46; Thu, 5 Feb 2015 11:04:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcDCvkrP8gR9; Thu, 5 Feb 2015 11:04:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B91E41A1A95; Thu, 5 Feb 2015 11:04:16 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.10.2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150205190416.30430.82185.idtracker@ietfa.amsl.com> Date: Thu, 05 Feb 2015 11:04:16 -0800 Archived-At: Cc: precis@ietf.org Subject: [precis] Last Call: (PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols) to Proposed Standard X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 19:04:19 -0000 The IESG has received a request from the Preparation and Comparison of Internationalized Strings WG (precis) to consider the following document: - 'PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols' as Proposed Standard This is a second Last Call. Even though this document has already been through IESG Evaluation and was approved pending an RFC Editor note to address some comments, significant enough issues were raised and changes were made that a new Last Call and IESG Evaluation is prudent. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-02-19. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Application protocols using Unicode characters in protocol strings need to properly handle such strings in order to enforce internationalization rules for strings placed in various protocol slots (such as addresses and identifiers) and to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation, enforcement, and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode characters and thus is agile with respect to versions of Unicode. As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454). This document obsoletes RFC 3454. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-precis-framework/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-precis-framework/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Feb 6 09:32:37 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A131A7013 for ; Fri, 6 Feb 2015 09:32:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5tvKPI4r5xK for ; Fri, 6 Feb 2015 09:32:28 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 386E51A6FEC for ; Fri, 6 Feb 2015 09:32:28 -0800 (PST) Received: from kuwa.viagenie.ca (kuwa.viagenie.ca [206.123.31.98]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A1E644122F for ; Fri, 6 Feb 2015 12:32:29 -0500 (EST) From: Marc Blanchet Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <08E45702-32A3-44DA-B0A6-349C41CBDFF5@viagenie.ca> Date: Fri, 6 Feb 2015 12:32:27 -0500 To: precis@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [precis] WGLC on draft-ietf-precis-nickname X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 17:32:32 -0000 Hello, this is a 2 weeks WGLC on draft-ietf-precis-nickname, ending on = February 20th 2015, 23h59 UTC. Please send support, comments, = suggestions, modifications to the list and to the authors = (draft-ietf-precis-nickname@tools.ietf.org). Those who read the document = and support it without modifications, please indicate so to the mailing = list. The assigned shepherd of the document is Joe Hildebrand. Marc, co-chair precis wg.= From nobody Fri Feb 6 09:32:49 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B731A70FD for ; Fri, 6 Feb 2015 09:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CxgLyKBoI4e for ; Fri, 6 Feb 2015 09:32:32 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 573311A6FEC for ; Fri, 6 Feb 2015 09:32:32 -0800 (PST) Received: from kuwa.viagenie.ca (kuwa.viagenie.ca [206.123.31.98]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D91CE4122F for ; Fri, 6 Feb 2015 12:32:33 -0500 (EST) From: Marc Blanchet Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 6 Feb 2015 12:32:31 -0500 To: precis@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [precis] WGLC on draft-ietf-precis-saslprepbis X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 17:32:33 -0000 Hello, this is a 2 weeks WGLC on draft-ietf-precis-saslprepbis, ending on = February 20th 2015, 23h59 UTC. Please send support, comments, = suggestions, modifications to the list and to the authors = (draft-ietf-precis-saslprepbis@tools.ietf.org). Those who read the = document and support it without modifications, please indicate so to the = mailing list. The assigned shepherd of the document is Matthew Miller. Please note that xmpp-6122bis which depends on saslprepbis will be = co-WGLC with xmpp wg after the saslprepbis precis WGLC is done. Marc, co-chair precis wg.= From nobody Sat Feb 7 04:11:45 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEA51A1B9C for ; Sat, 7 Feb 2015 04:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.899 X-Spam-Level: ** X-Spam-Status: No, score=2.899 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1ieuFXmkqX6 for ; Sat, 7 Feb 2015 04:10:59 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 185E41A1B16 for ; Sat, 7 Feb 2015 04:10:59 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 336E232E579; Sat, 7 Feb 2015 21:10:14 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 2db8_6771_3b88b5cc_df76_433f_8ca1_06c6f829e8ce; Sat, 07 Feb 2015 21:10:13 +0900 Received: from [133.2.249.69] (unknown [133.2.249.69]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 0DB6FBF4DE; Sat, 7 Feb 2015 21:10:13 +0900 (JST) Message-ID: <54D600A3.1070900@it.aoyama.ac.jp> Date: Sat, 07 Feb 2015 21:10:11 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: John C Klensin , Pete Resnick References: <54D18760.8090100@qti.qualcomm.com> <2423dah4ipo7jhvjr3vq4alidnsk7qdt5v@hive.bjoern.hoehrmann.de> <54D190FB.9060609@qti.qualcomm.com> <54D1A2C7.8020301@qti.qualcomm.com> <1CC9F36F2D7AF58BD7353D80@JcK-HP8200.jck.com> <54D27694.7080300@qti.qualcomm.com> <54D3449B.10306@it.aoyama.ac.jp> <916E45ADE98041A7C3A959D7@JcK-HP8200.jck.com> In-Reply-To: <916E45ADE98041A7C3A959D7@JcK-HP8200.jck.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Cc: precis@ietf.org Subject: Re: [precis] One change before Last Call X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2015 12:11:01 -0000 On 2015/02/06 00:58, John C Klensin wrote: > --On Thursday, February 05, 2015 19:23 +0900 "\"Martin J. > D=C3=BCrst\"" wrote: >> Except maybe for two or three people on the Unicode Technical >> Committee I know, I wouldn't want to claim that anybody knows >> the implications of even a significant (in terms of size and >> use) part of the Unicode repertoire. And for the average >> implementer or system administrator, it's of course much less. >> But we definitely don't want that to lead to a situation where >> we go back to (some time) last century and ASCII only. > > Martin, > > I don't see how you get from there to "ASCII only". First, > there are a lot of people in the world who don't "understand the > implications of" Latin Script, even the basic undecorated Latin > characters and even though they might use them. I think that, > while it may require some effort on their part, it is reasonable > to expect implementers and system administrators who establish > rules for identifiers to take responsibility for understanding > the use and possible risks associated with the characters of > their own scripts, especially the subset of those characters > that are relevant to their own languages. Hello John - You are right that not all people who use a script=20 understand it. I could give some specific examples. But they usually=20 think they understand it, so that will lead to the same outcome=20 regarding what we write. Also, you are correct that not all implementors=20 and system administrators are from the Latin writing parts of the world.=20 But a good majority is, and has a huge influence on the rest of the=20 world, and once one is in a defensive mindset, it's easy to come to the=20 conclusion "let's use ASCII, that has worked for decades, that can't be=20 wrong (and even if it is, nobody can be blamed/fired for choosing it)."=20 So "ASCII only" was somewhat of a simplification, but not a big one. > I recognize that makes it hard to design software systems that > are somehow internationally script-insensitive where identifiers > are concerned, but I think we have to live with that as the > price of the diversity of human languages and writing systems. > It may also imply a need for software implementations that are > far more rule-driven, possibly with locally-tailorable rules for > individual scripts, languages, and context, rather than an > approach that is construed as "this magic table of characters is > ok". Again, that may be the price of the diversity of human > writing system and, by looking at tables and global profiles, we > may just be in denial about that diversity and its implications. I agree, at least in theory. > None of the above is made any easier by Unicode decisions, > however justified by the same diversity issues, pushing us from > design principles that apply to all of the coding system, to > design principles that are different on a per-script basis, to > specific and exception-driven rules such as "normalization does > all of the right comparison things within the Latin script > except for the following code points for which decomposition is > appropriate under some circumstances but not others" or "there > are case matching rules that are universally applicable except > for certain specific locales and code points, where special > treatment is needed". I spent quite a bit of my time in colleague to learn Kanji. Quite a bit=20 later, I spent some time to analyse Kanji shapes in an attempt to create=20 some software for font design. I published a few papers, but didn't get=20 much farther. But one thing I learned was that although Kanji were built=20 up highly regularly, once you had to account for them in their full=20 numbers, there was always some kind of edge case or exception that broke=20 (or confirmed, as the saying goes) the rules. What you talk about above shows that the same applies to Unicode=20 overall: Even with a very strong attempt of keeping everything in line=20 with simple rules, there will always be some corner case or exception. > It may be that we have been in denial, that the whole concept of > identifiers without language context is unworkable for at least > some protocols, and that we should be thinking of an > "internationalized identifier" as a tuple with a string and > language identifier. Comparisons would then depend, not on > catenation and bit-by-bit comparison but on > consideration of the language identifier based on RFC 4647 and > then interpretation and comparison of the string based on that > information. I think we have very good reasons to have rejected this approach=20 virtually since the first moment we thought about internationalized=20 identifiers. Human eyesight doesn't see invisible BCP 47 'color' painted=20 over text, and people don't think that way. > That suggests that we should finish the PRECIS work based on > current documents rather than looking for a more prefect > solution (or textual phrasing) now. However, it does also > suggest that, for at least some purposes, the PRECIS work may be > a waypoint rather than a final answer. As I tried to explain, I just wanted to make sure we don't throw out the=20 baby with the bathwater. The new text is fine with me. Regards, Martin. From nobody Sun Feb 8 01:51:20 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E1F1A890B for ; Sun, 8 Feb 2015 01:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKliyOWU5QJw for ; Sun, 8 Feb 2015 01:50:24 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 34C5C1A8903 for ; Sun, 8 Feb 2015 01:50:24 -0800 (PST) Received: from [10.129.193.29] (unknown [223.197.192.22]) by jazz.viagenie.ca (Postfix) with ESMTPSA id DDB4B4021C for ; Sun, 8 Feb 2015 04:50:24 -0500 (EST) From: Marc Blanchet Content-Type: multipart/alternative; boundary="Apple-Mail=_EEA2C047-297B-4656-B1A4-B99C631EA8B3" Message-Id: <92C08BE5-9B20-4A6E-8448-6F6652A47EA4@viagenie.ca> Date: Sun, 8 Feb 2015 17:50:22 +0800 To: precis@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [precis] LUCID BOF X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 09:50:26 -0000 --Apple-Mail=_EEA2C047-297B-4656-B1A4-B99C631EA8B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, I submitted just at the very last minute last friday a proposal for a = BOF, described below. Credits to Dave Thaler for the name of the BOF = (LUCID). My first proposal was RIP (Revision of IDNA and Precis).=20 Regards, Marc. Name: Locale-free UniCode? = Identifiers (LUCID) Description: IAB has recently issued a statement about issues found by = the use of some class of code points in the IDNA protocol and also = applies to any identifier. The IAB expects that the IETF investigate = ways to address this problem. Work could be done in existing wg such as = precis or elsewhere. The purpose of the BOF is to define a plan.=20 Agenda: something like: 1) Problem statement and scope 2) possible ways = to address the problem 3) next steps in IETF. Status: WG Forming Responsible AD: Barry Leiba BoF proponents: Marc Blanchet <=E2=80=8Bmarc.blanchet@viagenie.ca = > BoF chairs: TBD Number of people expected to attend: 40 Length of session (1, 1.5, 2, or 2.5 hours): 1 hour Conflicts to avoid (whole Areas and/or WGs): precis, apparea Does it require Meetecho? Yes Links to the mailing list, draft charter if any, relevant = Internet-Drafts, etc. Mailing List: =E2=80=8B=E2=80=8Bidna-update@alvestrand.no = (temporarily) Draft charter: =E2=80=8BNone yet. Relevant documents: = =E2=80=8Bhttps://www.iab.org/documents/correspondence-reports-documents/20= 15-2/iab-statement-on-identifiers-and-unicode-7-0-0/ = draft-klensin-idna-5892upd-unicode7 = 0 --Apple-Mail=_EEA2C047-297B-4656-B1A4-B99C631EA8B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello,
 I submitted just at the very last = minute last friday a proposal for a BOF, described below. Credits to = Dave Thaler for the name of the BOF (LUCID). My first proposal was RIP = (Revision of IDNA and Precis). 

Regards, Marc.

  • Name: = Locale-free UniCode? Identifiers (LUCID)
  • Description: IAB has recently issued a statement about issues = found by the use of some class of code points in the IDNA protocol and = also applies to any identifier. The IAB expects that the IETF = investigate ways to address this problem. Work could be done in existing = wg such as precis or elsewhere. The purpose of the BOF is to define a = plan. 
  • Agenda: something like: 1) Problem = statement and scope 2) possible ways to address the problem 3) next = steps in IETF.
  • Status: WG Forming
  • Responsible AD: Barry Leiba
  • BoF = proponents: Marc Blanchet <=E2=80=8Bmarc.blanchet@viagenie.ca>
  • BoF chairs: TBD
  • Number of people expected = to attend: 40
  • Length of session (1, 1.5, 2, or 2.5 = hours): 1 hour
  • Conflicts to avoid (whole Areas and/or = WGs): precis, apparea
  • Does it require Meetecho? = Yes
  • Links to the mailing list, draft charter if any, = relevant Internet-Drafts, etc.
  • Mailing List: =E2=80=8B<= a class=3D"mail-link" href=3D"mailto:idna-update@alvestrand.no" = style=3D"color: rgb(68, 0, 136); border-bottom-width: 0px;">=E2=80=8Bidna-update@alvestrand.no (temporaril= y)
  • Draft charter: =E2=80=8BNone yet.
  • Relevant documents:

= --Apple-Mail=_EEA2C047-297B-4656-B1A4-B99C631EA8B3-- From nobody Mon Feb 9 09:35:46 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89BEC1A1AC6 for ; Mon, 9 Feb 2015 09:20:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ke-8d6YBh6y6 for ; Mon, 9 Feb 2015 09:20:30 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B1811A1B4C for ; Mon, 9 Feb 2015 09:20:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1423502425; x=1455038425; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=nK1kLgdTbJF6E/UHTf59IB+owtOQwoj6Armz/Otk0Y4=; b=UsE/Ah7oe3Secrk8tjnSr98+wr3Tovw/UMTdYwHh7zvxeDyceBjydEb7 Cj7JlDyH6olljLTMlidZtaBdh3d3s7ly71jp0GOS6tvGh6gy2KwDXaO35 9ufrqHaVoJRvQixAS5q6RfYzl1wY8XJHMRPAhUWC7dNHJ3MCHzqtxlqZx c=; X-IronPort-AV: E=McAfee;i="5600,1067,7707"; a="102699112" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Feb 2015 09:20:24 -0800 X-IronPort-AV: E=Sophos;i="5.09,544,1418112000"; d="scan'208";a="847845825" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 09 Feb 2015 09:20:23 -0800 Received: from presnick-mac.local (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 9 Feb 2015 09:20:22 -0800 Message-ID: <54D8EC54.8020203@qti.qualcomm.com> Date: Mon, 9 Feb 2015 11:20:20 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Peter Saint-Andre - &yet References: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se> <54851FAD.4040009@andyet.net> In-Reply-To: <54851FAD.4040009@andyet.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (10.85.0.81) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Cc: precis@ietf.org Subject: [precis] Directionality rule (Was: Review of current document draft-ietf-precis-framework-20) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 17:20:33 -0000 Crap. Somehow I missed this discussion back in December, and didn't notice it before I sent out Last Call. When I went to put in my new ballot, I saw the change. On 12/7/14 9:49 PM, Peter Saint-Andre - &yet wrote: >>> 5.2.5. Directionality Rule >>> >>> >>> The directionality rule of a profile specifies how to treat >>> strings containing left-to-right (LTR) and right-to-left (RTL) >>> characters (see Unicode Standard Annex #9 [ UAX9 ]). A profile >>> usually specifies a directionality rule that restricts strings to >>> be entirely LTR >>> strings or entirely RTL strings and defines the allowable >>> sequences of characters in LTR and RTL strings. Possible rules >>> include, but are not limited to, (a) considering any string that >>> contains a right- to-left code point to be a right-to-left string, >>> or (b) applying the "Bidi Rule" from [ RFC5893 ]. >> >> One can not restrict to only LTR or RTL as some code points are >> neutral regarding directionality. >> >> See RFC5893. This was one of the mistakes in IDNA2003. > > I think you're right that the foregoing text is not quite correct. > > And in any case, as John Klensin reiterated at the mic in a recent > PRECIS WG session, if we define something other than the Bidi Rule > then we'll likely get it wrong. I think that text predates John's > comments and hasn't been updated.. While I agree that the text that I had proposed earlier is not correct as it stands for the reason Patrik identifies, setting it back to: The directionality rule of a profile specifies how to treat strings that contain right-to-left (RTL) characters (see Unicode Standard Annex #9 [UAX9]). In general this document recommends applying the "Bidi Rule" from [RFC5893] to strings that contain RTL characters. (i.e., what was there before the AD Evaluation) was not correct. There was, I thought, agreement on the problem I was pointing out, and text inserted to address it. Encouraging the use of 5893 is a bad thing outside of the DNS. As we discussed at the time, the only reason that the 5893 Bidi Rule is so restrictive is because the (a) IDNA is already extremely restrictive in the characters it allows and (b) for DNS purposes, they wanted to make the display of labels around "."s more sane. Recommending 5893 it in other contexts is far too restrictive. Let me make another attempt to correct the above text without getting the bit about "only LTR or RTL" wrong: The directionality rule of a profile specifies how to treat strings containing combinations of characters with different directionality (e.g., left-to-right (LTR) characters, right-to-left (RTL) characters, and/or neutral directionality characters; see Unicode Standard Annex #9 [ UAX9 ]). A profile usually specifies a directionality rule that restricts strings to contain combinations of either entirely LTR and neutral characters or entirely RTL and neutral characters. A directionality rule can also define the allowable sequences of characters in such strings. The "Bidi Rule" from [RFC5893] is a particularly restrictive example of such a directionality rule. I am not wedded to the above, but what I would hate to see was this document go out the door with 5893 as the *recommendation*. I am not about to hold up the document because of this, but if we can come up with text that does not recommend 5893, it would make me very happy. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Mon Feb 9 10:20:12 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F471A1B92 for ; Mon, 9 Feb 2015 10:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wh19YS2Az0fs for ; Mon, 9 Feb 2015 10:16:49 -0800 (PST) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D9B11A1B5E for ; Mon, 9 Feb 2015 10:16:49 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id h15so18196362igd.4 for ; Mon, 09 Feb 2015 10:16:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KCVygkLN8sDESt20FKmtlMy/Ynz9iyFSN5sILm2gonY=; b=mclhR/5qj2qv0QMxgH3HVyaZvGLEmp++NGNUZfBa/i6zj2okNzEthUwZQE5882UwgW 3HWdXjxsnsNj9aaqjRsncxLVYSoP/GcILuuXCjzUK9sxH1UNnUpjYY+kejbtXh/AV2zP UhCQXdysUuVPkrcWD0KV4aPLtEdkoPp3WfMiHgYZvT2LRJL1XNZRZ9FeRFW04ZwUGZPF t504WYimx5BTzXKAIzfU3/PbKiPE5SZzpRxbFBVyqRQCXzUeyrThFLTL7+HUQS6n9OXI F97UeXm0XoBlzPjm/QrkY/BgNXeaybir70nNpX2/B/0JYpoZRAV21VNhKa47nu6VnB7D DETg== X-Gm-Message-State: ALoCoQljWc278L2766LdBj0IXCFNUIrN8ANIkkfEpL+ECicsHrnNLrNTdPjpm/KZOgFZ7T/iQYrT X-Received: by 10.107.7.93 with SMTP id 90mr13485009ioh.69.1423505808807; Mon, 09 Feb 2015 10:16:48 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id f37sm5474855iod.20.2015.02.09.10.16.47 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Feb 2015 10:16:48 -0800 (PST) Message-ID: <54D8F98F.4050309@andyet.net> Date: Mon, 09 Feb 2015 11:16:47 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Pete Resnick References: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se> <54851FAD.4040009@andyet.net> <54D8EC54.8020203@qti.qualcomm.com> In-Reply-To: <54D8EC54.8020203@qti.qualcomm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: precis@ietf.org Subject: Re: [precis] Directionality rule (Was: Review of current document draft-ietf-precis-framework-20) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 18:16:51 -0000 On 2/9/15 10:20 AM, Pete Resnick wrote: > Crap. Somehow I missed this discussion back in December, and didn't > notice it before I sent out Last Call. When I went to put in my new > ballot, I saw the change. > > On 12/7/14 9:49 PM, Peter Saint-Andre - &yet wrote: >>>> 5.2.5. Directionality Rule >>>> >>>> >>>> The directionality rule of a profile specifies how to treat >>>> strings containing left-to-right (LTR) and right-to-left (RTL) >>>> characters (see Unicode Standard Annex #9 [ UAX9 ]). A profile >>>> usually specifies a directionality rule that restricts strings to >>>> be entirely LTR >>>> strings or entirely RTL strings and defines the allowable >>>> sequences of characters in LTR and RTL strings. Possible rules >>>> include, but are not limited to, (a) considering any string that >>>> contains a right- to-left code point to be a right-to-left string, >>>> or (b) applying the "Bidi Rule" from [ RFC5893 ]. >>> >>> One can not restrict to only LTR or RTL as some code points are >>> neutral regarding directionality. >>> >>> See RFC5893. This was one of the mistakes in IDNA2003. >> >> I think you're right that the foregoing text is not quite correct. >> >> And in any case, as John Klensin reiterated at the mic in a recent >> PRECIS WG session, if we define something other than the Bidi Rule >> then we'll likely get it wrong. I think that text predates John's >> comments and hasn't been updated.. > > While I agree that the text that I had proposed earlier is not correct > as it stands for the reason Patrik identifies, setting it back to: > > The directionality rule of a profile specifies how to treat strings > that contain right-to-left (RTL) characters (see Unicode Standard > Annex #9 [UAX9]). In general this document recommends applying the > "Bidi Rule" from [RFC5893] to strings that contain RTL characters. > > (i.e., what was there before the AD Evaluation) was not correct. There > was, I thought, agreement on the problem I was pointing out, and text > inserted to address it. Encouraging the use of 5893 is a bad thing > outside of the DNS. I think John Klensin made a good point at the mic at a semi-recent meeting (London?) that, if we try to define a new bidirectionality rule, we are likely to do it wrong. > As we discussed at the time, the only reason that > the 5893 Bidi Rule is so restrictive is because the (a) IDNA is already > extremely restrictive in the characters it allows and (b) for DNS > purposes, they wanted to make the display of labels around "."s more > sane. Recommending 5893 it in other contexts is far too restrictive. Let > me make another attempt to correct the above text without getting the > bit about "only LTR or RTL" wrong: > > The directionality rule of a profile specifies how to treat strings > containing combinations of characters with different directionality > (e.g., left-to-right (LTR) characters, right-to-left (RTL) > characters, and/or neutral directionality characters; see Unicode > Standard Annex #9 [ UAX9 ]). A profile usually specifies a > directionality rule that restricts strings to contain combinations of > either entirely LTR and neutral characters or entirely RTL and > neutral characters. A directionality rule can also define the > allowable sequences of characters in such strings. The "Bidi Rule" > from [RFC5893] is a particularly restrictive example of such a > directionality rule. > > I am not wedded to the above, but what I would hate to see was this > document go out the door with 5893 as the *recommendation*. What I would hate to see is leaving directionality handling up to the profiles without much guidance about what to do. > I am not > about to hold up the document because of this, but if we can come up > with text that does not recommend 5893, it would make me very happy. Agreed on the goal, I think. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Mon Feb 9 12:40:52 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01FBB1A87BE for ; Mon, 9 Feb 2015 11:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72E7kTCajxqR for ; Mon, 9 Feb 2015 11:56:36 -0800 (PST) Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F75C1A6F15 for ; Mon, 9 Feb 2015 11:56:15 -0800 (PST) Received: by mail-ig0-f172.google.com with SMTP id l13so18835633iga.5 for ; Mon, 09 Feb 2015 11:56:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=BPNM+Qt4SBtkb9BJ21qUa/J7V3OhCmOfhYGJSq2Y7Hc=; b=S1O5c6GzUF5G+WsifPpT9YmulpSUWTiGcWkFN0VpzM+TdmbKie4UDJcLqA+X0q5fXk jpTT7OcWJalwqmd4F8w20hiKVp3BvjpSxYIQQInzoclDIzDa0t6Oj2roegbZNHoQKfov fWZDWo3Z5yEaAO8qaCKHTPcwSVNAGSlAO4LgfG0aZbha1NsK6HnFQiyiSRVN6hfivMhu umgvAz3Ce49IXY2EJtUw2eSzWQKSd/uGRT9VyjO3SVDpflUh5vikXFOLnW2Bklcw/1cN NKjyX6QtndVZOGNJ9Xh58XjaDDiJRA3Pq/Lb5g1pHJE2o1ixUGCYKoFqHokqZ5JTFHrj NlNQ== X-Gm-Message-State: ALoCoQklsWghWBkwaTci+cR+bBkhffD0nJJq4iUHiBf/WPgTs/h3FcUZjPXrPg7WQryEYE0r0ufc X-Received: by 10.43.178.134 with SMTP id ow6mr12326745icc.66.1423511774770; Mon, 09 Feb 2015 11:56:14 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id 199sm6994584ioe.14.2015.02.09.11.56.13 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Feb 2015 11:56:14 -0800 (PST) Message-ID: <54D910DC.1080003@andyet.net> Date: Mon, 09 Feb 2015 12:56:12 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Pete Resnick References: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se> <54851FAD.4040009@andyet.net> <54D8EC54.8020203@qti.qualcomm.com> <54D8F98F.4050309@andyet.net> In-Reply-To: <54D8F98F.4050309@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: precis@ietf.org Subject: Re: [precis] Directionality rule (Was: Review of current document draft-ietf-precis-framework-20) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 19:56:39 -0000 On 2/9/15 11:16 AM, Peter Saint-Andre - &yet wrote: > On 2/9/15 10:20 AM, Pete Resnick wrote: >> Crap. Somehow I missed this discussion back in December, and didn't >> notice it before I sent out Last Call. When I went to put in my new >> ballot, I saw the change. >> >> On 12/7/14 9:49 PM, Peter Saint-Andre - &yet wrote: >>>>> 5.2.5. Directionality Rule >>>>> >>>>> >>>>> The directionality rule of a profile specifies how to treat >>>>> strings containing left-to-right (LTR) and right-to-left (RTL) >>>>> characters (see Unicode Standard Annex #9 [ UAX9 ]). A profile >>>>> usually specifies a directionality rule that restricts strings to >>>>> be entirely LTR >>>>> strings or entirely RTL strings and defines the allowable >>>>> sequences of characters in LTR and RTL strings. Possible rules >>>>> include, but are not limited to, (a) considering any string that >>>>> contains a right- to-left code point to be a right-to-left string, >>>>> or (b) applying the "Bidi Rule" from [ RFC5893 ]. >>>> >>>> One can not restrict to only LTR or RTL as some code points are >>>> neutral regarding directionality. >>>> >>>> See RFC5893. This was one of the mistakes in IDNA2003. >>> >>> I think you're right that the foregoing text is not quite correct. >>> >>> And in any case, as John Klensin reiterated at the mic in a recent >>> PRECIS WG session, if we define something other than the Bidi Rule >>> then we'll likely get it wrong. I think that text predates John's >>> comments and hasn't been updated.. >> >> While I agree that the text that I had proposed earlier is not correct >> as it stands for the reason Patrik identifies, setting it back to: >> >> The directionality rule of a profile specifies how to treat strings >> that contain right-to-left (RTL) characters (see Unicode Standard >> Annex #9 [UAX9]). In general this document recommends applying the >> "Bidi Rule" from [RFC5893] to strings that contain RTL characters. >> >> (i.e., what was there before the AD Evaluation) was not correct. There >> was, I thought, agreement on the problem I was pointing out, and text >> inserted to address it. Encouraging the use of 5893 is a bad thing >> outside of the DNS. > > I think John Klensin made a good point at the mic at a semi-recent > meeting (London?) that, if we try to define a new bidirectionality rule, > we are likely to do it wrong. > >> As we discussed at the time, the only reason that >> the 5893 Bidi Rule is so restrictive is because the (a) IDNA is already >> extremely restrictive in the characters it allows and (b) for DNS >> purposes, they wanted to make the display of labels around "."s more >> sane. Recommending 5893 it in other contexts is far too restrictive. Let >> me make another attempt to correct the above text without getting the >> bit about "only LTR or RTL" wrong: >> >> The directionality rule of a profile specifies how to treat strings >> containing combinations of characters with different directionality >> (e.g., left-to-right (LTR) characters, right-to-left (RTL) >> characters, and/or neutral directionality characters; see Unicode >> Standard Annex #9 [ UAX9 ]). A profile usually specifies a >> directionality rule that restricts strings to contain combinations of >> either entirely LTR and neutral characters or entirely RTL and >> neutral characters. A directionality rule can also define the >> allowable sequences of characters in such strings. The "Bidi Rule" >> from [RFC5893] is a particularly restrictive example of such a >> directionality rule. >> >> I am not wedded to the above, but what I would hate to see was this >> document go out the door with 5893 as the *recommendation*. > > What I would hate to see is leaving directionality handling up to the > profiles without much guidance about what to do. Further thoughts... If I read your proposed text correctly, you are saying three things: 1. A profile needs to define which directionality rule applies. 2. A profile can define its own directionality rule. 3. A profile can/might/may/should use the following rule: A string MUST contain LTR characters and neutral characters only or contain RTL characters and neutral characters only, but MUST NOT contain both LTR and RTL characters. (Does that rule have a name?) 4. The directionality rule defined by a particular profile may specify further restrictions, or may use a more restrictive rule (such as the Bidi Rule). I agree with (1). I think (2) is a bad idea for the reasons John explained. I think (3) is an acceptable rule and I think we might want to give profiles a choice between that and the Bidi Rule (thus discouraging new directionality rules). I think (4) is a bad idea if it assumes (2). Peter From nobody Mon Feb 9 13:24:27 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3281A88D3 for ; Mon, 9 Feb 2015 12:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zo6_Ih0yoVc5 for ; Mon, 9 Feb 2015 12:42:41 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E63E61A88CE for ; Mon, 9 Feb 2015 12:42:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1423514562; x=1455050562; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ElfiwuX6nVJdSWU9aIA+fOvJ4i8h524t1Rjb1y7kvFQ=; b=gT929Tq6gQx5ty6kUv+2TT8/0CbgV1wtS0lpPDrJZPztt86fYjKoHgzw TK5ZEidLxwOrPwY9dv1VtJY7OS7dbSXOU/kns09d/UOM+xxrtdTiZajbN leB4XJn/pK+eqXcrcXpEwqTVdhE1XHtcuby2uebgfWj7y0F4Lf8Gkity8 s=; X-IronPort-AV: E=McAfee;i="5600,1067,7707"; a="102728095" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Feb 2015 12:42:41 -0800 X-IronPort-AV: E=Sophos;i="5.09,545,1418112000"; d="scan'208";a="901873257" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 09 Feb 2015 12:42:40 -0800 Received: from presnick-mac.local (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 9 Feb 2015 12:42:39 -0800 Message-ID: <54D91BA8.6000705@qti.qualcomm.com> Date: Mon, 9 Feb 2015 14:42:16 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Peter Saint-Andre - &yet References: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se> <54851FAD.4040009@andyet.net> <54D8EC54.8020203@qti.qualcomm.com> <54D8F98F.4050309@andyet.net> <54D910DC.1080003@andyet.net> In-Reply-To: <54D910DC.1080003@andyet.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01D.na.qualcomm.com (10.85.0.84) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Cc: precis@ietf.org Subject: Re: [precis] Directionality rule (Was: Review of current document draft-ietf-precis-framework-20) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 20:42:43 -0000 On 2/9/15 1:56 PM, Peter Saint-Andre - &yet wrote: >> On 2/9/15 10:20 AM, Pete Resnick wrote: >> >>> The directionality rule of a profile specifies how to treat strings >>> containing combinations of characters with different directionality >>> (e.g., left-to-right (LTR) characters, right-to-left (RTL) >>> characters, and/or neutral directionality characters; see Unicode >>> Standard Annex #9 [ UAX9 ]). A profile usually specifies a >>> directionality rule that restricts strings to contain >>> combinations of >>> either entirely LTR and neutral characters or entirely RTL and >>> neutral characters. A directionality rule can also define the >>> allowable sequences of characters in such strings. The "Bidi Rule" >>> from [RFC5893] is a particularly restrictive example of such a >>> directionality rule. >>> >>> I am not wedded to the above, but what I would hate to see was this >>> document go out the door with 5893 as the *recommendation*. > > Further thoughts... > > If I read your proposed text correctly, you are saying three things: > > 1. A profile needs to define which directionality rule applies. Yep. I wish we didn't have to say that (because this is about display, not processing), but I am definitely in the rough about being able to say "mixed-direction is fun; have at it!". > 2. A profile can define its own directionality rule. Well, we have given that ability, but I don't think it's a good idea for a profile to do so. SHOULD NOT. > 3. A profile can/might/may/should use the following rule: > > A string MUST contain LTR characters and neutral characters only or > contain RTL characters and neutral characters only, but MUST NOT > contain both LTR and RTL characters. As Klensin points out to me out of band, I screwed that up too, since some digits and punctuation are LTR but would certainly violate the Principle of Least Astonishment if we disallowed them alongside RTL characters. So at the very least, I am going to chew on this with John for a bit and see if there *is* some simple formulation of a directionality rule short of 5893. > (Does that rule have a name?) "Pete's lousy attempt to formulate a simple rule"? Consider this on hold. > 4. The directionality rule defined by a particular profile may specify > further restrictions, or may use a more restrictive rule (such as the > Bidi Rule). Same as 2 above. We've given them the ability to do so, but it would be a really bad idea if they did. SHOULD NOT. > I agree with (1). I think (2) is a bad idea for the reasons John > explained. I think (3) is an acceptable rule and I think we might want > to give profiles a choice between that and the Bidi Rule (thus > discouraging new directionality rules). I think (4) is a bad idea if > it assumes (2). Yep. This might turn out that I'm convinced there is nothing better to say than "use 5893". That will cause me to weep into my beer. But give me a bit to chat with Klensin and we'll see if we can come up with sanity. (*Sigh*) pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Mon Feb 9 15:14:16 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07381A8A13 for ; Mon, 9 Feb 2015 14:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFWJyyWgx0VY for ; Mon, 9 Feb 2015 14:53:47 -0800 (PST) Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com [209.85.213.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCED91A8940 for ; Mon, 9 Feb 2015 14:53:46 -0800 (PST) Received: by mail-ig0-f182.google.com with SMTP id h15so19849357igd.3 for ; Mon, 09 Feb 2015 14:53:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=PAUcz8PepAL82+SxY95MvdJpQojtdbcCT07Cqq4X+hs=; b=Koet26Ay8NH/KGj3FA5BLzc4LHCKY8eTC1Pg21t+8Bpgwe9Vd4MWBIZWsV/sn9i/Dj naeIap1il3dCSiB2M7Y99ngLBj+/l2/+DjbV9JNvNxbCIPWxVc4KQ3GbljxNwBm+Rc3q Od4dD+dcf+WchEfy5YZk1Ix+fJRx3OVcikLm/7H09AzHJH4FDdAIbHIsKJMSukouxSFR XPsRC9tPVnx4PFt21qZmNeGan5itxMXs8b1ZgxYYVs3xXk/SAJWCT5lgJPXGTp6u2RLW Plw9dMhGG3H3qAqSeH81ZqqXU+ZQ03sQ3oD5M7k1C4My4Zwv1ssb2CZFXMOg4uBrnVyc EQhw== X-Gm-Message-State: ALoCoQlSXXTkhL5r7R28GaWesLvu8QtdP1SYnGg4ItOkrEVgOoii4mWtaxkli6iLIYMLFEQR11vr X-Received: by 10.50.4.40 with SMTP id h8mr14739429igh.34.1423522425275; Mon, 09 Feb 2015 14:53:45 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id m5sm6551067ige.5.2015.02.09.14.53.44 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Feb 2015 14:53:44 -0800 (PST) Message-ID: <54D93A77.9060102@andyet.net> Date: Mon, 09 Feb 2015 15:53:43 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Pete Resnick References: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se> <54851FAD.4040009@andyet.net> <54D8EC54.8020203@qti.qualcomm.com> <54D8F98F.4050309@andyet.net> <54D910DC.1080003@andyet.net> <54D91BA8.6000705@qti.qualcomm.com> In-Reply-To: <54D91BA8.6000705@qti.qualcomm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: precis@ietf.org Subject: Re: [precis] Directionality rule (Was: Review of current document draft-ietf-precis-framework-20) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 22:53:48 -0000 On 2/9/15 1:42 PM, Pete Resnick wrote: > This might turn out that I'm convinced there is nothing better to say > than "use 5893". That's where we ended up the last time we looked into the problem. > That will cause me to weep into my beer. Sorry. > But give me a > bit to chat with Klensin and we'll see if we can come up with sanity. I agree that the Bidi Rule from RFC 5893 is designed for use with DNS labels, and that it's not a perfect fit for PRECIS strings. But it might be the best we can do right now. Peter From nobody Wed Feb 11 13:33:25 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22AA51A1C05 for ; Wed, 11 Feb 2015 13:33:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQNSipkVTVM3 for ; Wed, 11 Feb 2015 13:33:19 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09F611A1A04 for ; Wed, 11 Feb 2015 13:33:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1423690399; x=1455226399; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=zPcgIjM2DJi46Bg99GvOnj6EyfEAk/ZiHrvsenB2tA0=; b=pAA78x7VyNnRooZq/NVeClkbnENjuySXta8eGZIcL3COYW2aktk/hUUf cUTce360/U6skgicNlgrNoCfzUCgLqt7fDikIT900FyZzjipyF0XcHlxe L+Q7hUPsfqXw0K5TCOyY9fihmimyjLN9Ab31Wl5zcYLD2yN8+LEMNMDCb I=; X-IronPort-AV: E=McAfee;i="5600,1067,7709"; a="195107378" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Feb 2015 13:33:18 -0800 X-IronPort-AV: E=Sophos;i="5.09,560,1418112000"; d="scan'208";a="849625123" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 11 Feb 2015 13:33:18 -0800 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 11 Feb 2015 13:33:17 -0800 Message-ID: <54DBCA9B.3050900@qti.qualcomm.com> Date: Wed, 11 Feb 2015 15:33:15 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Peter Saint-Andre - &yet References: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se> <54851FAD.4040009@andyet.net> <54D8EC54.8020203@qti.qualcomm.com> <54D8F98F.4050309@andyet.net> <54D910DC.1080003@andyet.net> <54D91BA8.6000705@qti.qualcomm.com> <54D93A77.9060102@andyet.net> In-Reply-To: <54D93A77.9060102@andyet.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01D.na.qualcomm.com (10.85.0.84) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Cc: precis@ietf.org Subject: Re: [precis] Directionality rule (Was: Review of current document draft-ietf-precis-framework-20) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 21:33:22 -0000 On 2/9/15 4:53 PM, Peter Saint-Andre - &yet wrote: > On 2/9/15 1:42 PM, Pete Resnick wrote: > >> But give me a bit to chat with Klensin and we'll see if we can come >> up with sanity. > > I agree that the Bidi Rule from RFC 5893 is designed for use with DNS > labels, and that it's not a perfect fit for PRECIS strings. But it > might be the best we can do right now. OK, here is some text that I worked on with John. We think this has the desirable properties that it is both as close to correct as we're going to get *and* what the WG intended. This is meant to be a replacement for all of the text in 5.2.5: The directionality rule of a profile specifies how to treat strings containing what are often called "right-to-left" (RTL) characters. RTL characters come from scripts that are normally written from right to left and are considered by Unicode to, themselves, have right to left directionality. Strings containing RTL characters often also contain "left-to-right" (LTR) characters, such as numerals, as well as characters without directional properties. Consequently, such strings are known as "bidirectional strings". Using bidirectional strings in different layout contexts may yield display results that, while predictable to those who understand the display rules, may be counter-intuitive to casual users. Therefore some profiles may wish to restrict their use by specifying a directionality rule. The PRECIS framework does not directly address how to deal with bidirectional strings, since there is currently no widely accepted and implemented solution for the safe display of arbitrary bidirectional strings beyond the general Unicode bidirectional specification [UAX9]. Rules for management and display of bidirectional strings have been defined for domain name labels and similar identifiers in the "Bidi Rule" from [RFC5893]. If a profile really needs to specify a directionality rule, unless a great deal of careful research into the problems of displaying bidirectional text is done (which is outside of the scope of this framework), this document generally recommends using the "Bidi Rule" from [RFC5893] for profiles based on IdentifierClass, and for profiles based on FreeformClass or other situations in which IdentifierClass is not appropriate, that consideration be given to using UAX #9 directly. What do you think? pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Wed Feb 11 13:44:39 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71F91A1AD2 for ; Wed, 11 Feb 2015 13:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTx43QEz6e9V for ; Wed, 11 Feb 2015 13:44:36 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47DB51A0039 for ; Wed, 11 Feb 2015 13:44:36 -0800 (PST) Received: from netb ([82.113.99.181]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M5MIN-1XOL9k0yj9-00zXXh; Wed, 11 Feb 2015 22:44:33 +0100 From: Bjoern Hoehrmann To: Pete Resnick Date: Wed, 11 Feb 2015 22:44:32 +0100 Message-ID: <8uinda9tsm756uhr24pmuc1n2450b5v4fk@hive.bjoern.hoehrmann.de> References: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se> <54851FAD.4040009@andyet.net> <54D8EC54.8020203@qti.qualcomm.com> <54D8F98F.4050309@andyet.net> <54D910DC.1080003@andyet.net> <54D91BA8.6000705@qti.qualcomm.com> <54D93A77.9060102@andyet.net> <54DBCA9B.3050900@qti.qualcomm.com> In-Reply-To: <54DBCA9B.3050900@qti.qualcomm.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:RJWMF+hLbzCnAc4eS9jMFkHKzTSWK/8nhiILJ4VDAOchElGe9k3 qsPBWNtWn/OxKq7MuijWYqJybuGXdZME6xiZBxXQdb8xx+OAZSxZlktI2qkGDOf3UJ9kn/U CLswX/NmC0v1QX2mZ8z7L/cb6IMHS6A49F4S76oieHi+EqrUpY6yIJDOqFiBY/R4amww59B Wfsb4CJHG3ftFS92b7Myw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: precis@ietf.org, Peter Saint-Andre - &yet Subject: Re: [precis] Directionality rule (Was: Review of current document draft-ietf-precis-framework-20) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 21:44:38 -0000 * Pete Resnick wrote: >OK, here is some text that I worked on with John. We think this has the >desirable properties that it is both as close to correct as we're going >to get *and* what the WG intended. This is meant to be a replacement for >all of the text in 5.2.5: > > The directionality rule of a profile specifies how to treat strings > containing what are often called "right-to-left" (RTL) characters. > RTL characters come from scripts that are normally written from right > to left and are considered by Unicode to, themselves, have right to > left directionality. Strings containing RTL characters often also > contain "left-to-right" (LTR) characters, such as numerals, as well > as characters without directional properties. Consequently, such > strings are known as "bidirectional strings". Using bidirectional > strings in different layout contexts may yield display results that, > while predictable to those who understand the display rules, may be > counter-intuitive to casual users. Therefore some profiles may wish > to restrict their use by specifying a directionality rule. > > The PRECIS framework does not directly address how to deal with > bidirectional strings, since there is currently no widely accepted > and implemented solution for the safe display of arbitrary > bidirectional strings beyond the general Unicode bidirectional > specification [UAX9]. Rules for management and display of > bidirectional strings have been defined for domain name labels and > similar identifiers in the "Bidi Rule" from [RFC5893]. If a profile > really needs to specify a directionality rule, unless a great deal of > careful research into the problems of displaying bidirectional text > is done (which is outside of the scope of this framework), this > document generally recommends using the "Bidi Rule" from [RFC5893] > for profiles based on IdentifierClass, and for profiles based on > FreeformClass or other situations in which IdentifierClass is not > appropriate, that consideration be given to using UAX #9 directly. I am not happy with "this document generally recommends"; it's not clear if this is the recommendation or if the recommendation is elswhere; it's also not clear if this a RFC 2119 RECOMMENDED or something weaker, made worse by "generally" and also the preceding "unless". Should be easy to rephrase, but I do not have a good idea right now. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/ From nobody Wed Feb 11 16:14:38 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9098A1A1A69 for ; Wed, 11 Feb 2015 16:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.21 X-Spam-Level: X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TZrGlwgy48O for ; Wed, 11 Feb 2015 16:14:31 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BCC81A874C for ; Wed, 11 Feb 2015 16:14:31 -0800 (PST) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YLhQE-0000IP-0Z; Wed, 11 Feb 2015 19:14:22 -0500 Date: Wed, 11 Feb 2015 19:14:16 -0500 From: John C Klensin To: Bjoern Hoehrmann , Pete Resnick Message-ID: In-Reply-To: <8uinda9tsm756uhr24pmuc1n2450b5v4fk@hive.bjoern.hoehrmann.de> References: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se> <54851FAD.4040009@andyet.net> <54D8EC54.8020203@qti.qualcomm.com> <54D8F98F.4050309@andyet.net> <54D910DC.1080003@andyet.net> <54D91BA8.6000705@qti.qualcomm.com> <54D93A77.9060102@andyet.net> <54DBCA9B.3050900@qti.qualcomm.com> <8uinda9tsm756uhr24pmuc1n2450b5v4fk@hive.bjoern.hoehrmann.de> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: precis@ietf.org, Peter Saint-Andre - &yet Subject: Re: [precis] Directionality rule (Was: Review of current document draft-ietf-precis-framework-20) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 00:14:35 -0000 --On Wednesday, February 11, 2015 22:44 +0100 Bjoern Hoehrmann wrote: > This is meant to be a replacement for=20 >> all of the text in 5.2.5: >>=20 >> The directionality rule of a profile specifies how to >> treat strings containing what are often called >> "right-to-left" (RTL) characters. RTL characters come from >... >> The PRECIS framework does not directly address how to deal >> with bidirectional strings, since there is currently no >> widely accepted and implemented solution for the safe >> display of arbitrary bidirectional strings beyond the >> general Unicode bidirectional specification [UAX9]. Rules >... > I am not happy with "this document generally recommends"; it's > not clear if this is the recommendation or if the > recommendation is elswhere; it's also not clear if this a RFC > 2119 RECOMMENDED or something weaker, made worse by > "generally" and also the preceding "unless". Should be easy to > rephrase, but I do not have a good idea right now. Bj=C3=B6rn, Let my try to explain this from the perspective of someone who has been greatly concerned with multiple aspects of the PRECIS work (I assume no one how has been following this list or the WG will be surprised by that), but who is now trying to work with Pete, the document authors, and the WG co-chairs to get this wrapped up. Let me also do so, at least in part, less from the perspective of the IETF's i18n efforts and more from that of someone who was expected to be able to at least partially get around in multiple languages from a rather tender age -- languages that were, by my great good (or bad) luck, written in three separate scripts, one of which is written right to left. For at least the last several centuries, no calligrapher and probably no "ordinary" reader or writer of a given script has been particularly troubled by its directionality properties. One just writes it as it is written, whether that is left to right, right to left, top to bottom, or some variation on what is sometimes called serpentine. However, when these things are coded for computer systems in some set of "uniform" rules, things get complicated. We have to worry about order of bits or bytes in transmission, storage order, potentially the difference between storage order and rendering order, and all sorts of subtle variations on characters that may result from what is next to them along some dimension. =20 The result is that the Unicode Bidi rules are very complex, to the point that I often suspect that only a few people completely understand them and that some of those may not understand all of them three months in a row. Certainly the observation that UAX #9 has been revised several times, presumably to make it more comprehensible and clarify fine points and edge cases, contributes to a "I hope this time they got it right" sensation. It would be easy to cast blame for this in Unicode's direction but, as with a lot of other aspects of Unicode, I believe that a different "universal" character set, constructed with a different set of rules, would simply favor different tradeoffs and exhibit a different set of problems/ difficulties. Now back to PRECIS and the text Pete posted. First, one of the fundamental problems with the WG, at least IMO, is that there have been a lot of participants, probably a considerable majority, who have been unwilling to dig deeply into this and other complex issues, concentrating instead on making sure their own favorite language or script could be accommodated in some reasonable way or on a "please just tell me what to do; I don't want to have to understand it or think about it... as long as it doesn't mess up my deployed implementations" style of requirement. =20 Second, while this is up to Pete, the WG, and its leadership it is getting late enough in the process that "I am not happy with" --in the absence of specific suggestions -- is not very helpful. We need to at least understand what you would like done, not just that you don't like what is there (or proposed). =20 If you (and, others if they agree with you), merely want the statement to be very clear that it is referring to Section 5.2.5 and that is all that is going to be said as far as PRECIS is concerned, I imagine we (particular Peter and Marc) can figure out how to do that even though all the ways I can think of at the moment would sound pretty pedantic. If your problem (or desire) is a stronger and more specific recommendation, then there are a couple of problems. There are families and layers of peculiar and/or edge cases. I think it is reasonably unlikely that a user or implementer who regularly reads and writes a particular RTL script and has sufficient wisdom and maturity to be sensible and conservative about identifiers rather than trying to figure out what "weird stuff" might work is going to encounter or generate them. As long as one avoids those cases, both RFC 5893 and UAX #9 do about what a reasonable person with experience with the relevant scripts on computer systems is going to expect. On the other hand, if one wants to discuss the edge cases, it isn't going to be possible to do it in a few paragraphs (RFC 5893 and UAX #9 are relatively long documents for a reason) and I have doubts that the WG will be able to come up with informed consensus ("rough" or otherwise) that anything that is said is right. So "general recommendation" covers most of the likely and important cases. If one wants to get into the edges, one will quickly end up on one's own and, unless one is really an expert with the things, with a fairly high likelihood of ending up in a rather large mess. =20 And that, IMO, is what the proposed text says. best, john From nobody Wed Feb 11 16:40:19 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0461A874E for ; Wed, 11 Feb 2015 16:40:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frJtdr0qObIW for ; Wed, 11 Feb 2015 16:40:12 -0800 (PST) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFC4A1A874C for ; Wed, 11 Feb 2015 16:40:12 -0800 (PST) Received: by iecrl12 with SMTP id rl12so5980650iec.4 for ; Wed, 11 Feb 2015 16:40:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KES+bLqtGBGXLPXFAEXN8vBWxL/Ghr9dbU96PjEpXhA=; b=ibQ9+/0gxH0SVvmJbz9WKv5RGFzK5UFdOssl0SrKoeicMlv/371ZLW/8lFNsSm7ij4 bBJVQZqxxTb1LPsSEq1MjNMMBQ5C59ulG5EKbFnbyeWnkmduR3OjIdgtgNYQIY4MDwnV iHOFur68k1tQHX2mh7mjVtzjUFptSU+sgtZ7LvR+C2VCUCoKS0Ct37nfYFzj3UyESBsk cTpSAzyLHd0aSGQ1Y3sYq9Ca/yuK50Jo0DyydmWCuJK/8xKdZI44mYQwYKy9GisghbUC 9+u8+q3FK6MwgES/AOLwK9SQTYhinwoA+uysrU5/wuR95cJNnhlXNeIts0BN9UcgiqNF 0H+Q== X-Gm-Message-State: ALoCoQkDcUmBTwsZBYc9PmVQ2Fms+BpnBUQJamz7MFEbRAecqoUQtcGoqqPhk941i49JX2CpnQk5 X-Received: by 10.107.7.93 with SMTP id 90mr1651016ioh.69.1423701611162; Wed, 11 Feb 2015 16:40:11 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id t5sm187258ign.12.2015.02.11.16.40.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Feb 2015 16:40:10 -0800 (PST) Message-ID: <54DBF669.8080403@andyet.net> Date: Wed, 11 Feb 2015 17:40:09 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Pete Resnick References: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se> <54851FAD.4040009@andyet.net> <54D8EC54.8020203@qti.qualcomm.com> <54D8F98F.4050309@andyet.net> <54D910DC.1080003@andyet.net> <54D91BA8.6000705@qti.qualcomm.com> <54D93A77.9060102@andyet.net> <54DBCA9B.3050900@qti.qualcomm.com> In-Reply-To: <54DBCA9B.3050900@qti.qualcomm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: precis@ietf.org Subject: Re: [precis] Directionality rule (Was: Review of current document draft-ietf-precis-framework-20) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 00:40:16 -0000 On 2/11/15 2:33 PM, Pete Resnick wrote: > On 2/9/15 4:53 PM, Peter Saint-Andre - &yet wrote: >> On 2/9/15 1:42 PM, Pete Resnick wrote: >> >>> But give me a bit to chat with Klensin and we'll see if we can come >>> up with sanity. >> >> I agree that the Bidi Rule from RFC 5893 is designed for use with DNS >> labels, and that it's not a perfect fit for PRECIS strings. But it >> might be the best we can do right now. > > OK, here is some text that I worked on with John. We think this has the > desirable properties that it is both as close to correct as we're going > to get *and* what the WG intended. This is meant to be a replacement for > all of the text in 5.2.5: > > The directionality rule of a profile specifies how to treat strings > containing what are often called "right-to-left" (RTL) characters. > RTL characters come from scripts that are normally written from right > to left and are considered by Unicode to, themselves, have right to > left directionality. Strings containing RTL characters often also > contain "left-to-right" (LTR) characters, such as numerals, as well > as characters without directional properties. Consequently, such > strings are known as "bidirectional strings". Using bidirectional > strings in different layout contexts may yield display results that, > while predictable to those who understand the display rules, may be > counter-intuitive to casual users. Therefore some profiles may wish > to restrict their use by specifying a directionality rule. > > The PRECIS framework does not directly address how to deal with > bidirectional strings, since there is currently no widely accepted > and implemented solution for the safe display of arbitrary > bidirectional strings beyond the general Unicode bidirectional > specification [UAX9]. Rules for management and display of > bidirectional strings have been defined for domain name labels and > similar identifiers in the "Bidi Rule" from [RFC5893]. If a profile > really needs to specify a directionality rule, unless a great deal of > careful research into the problems of displaying bidirectional text > is done (which is outside of the scope of this framework), this > document generally recommends using the "Bidi Rule" from [RFC5893] > for profiles based on IdentifierClass, and for profiles based on > FreeformClass or other situations in which IdentifierClass is not > appropriate, that consideration be given to using UAX #9 directly. > > What do you think? I think it's good up until the last sentence, which is convoluted. But the tone is right and we might even want to borrow some text from Section 3 of RFC 5895. ;-) A possible refactoring... OLD If a profile really needs to specify a directionality rule, unless a great deal of careful research into the problems of displaying bidirectional text is done (which is outside of the scope of this framework), this document generally recommends using the "Bidi Rule" from [RFC5893] for profiles based on IdentifierClass, and for profiles based on FreeformClass or other situations in which IdentifierClass is not appropriate, that consideration be given to using UAX #9 directly. NEW The authors of a profile might think that they need to define a new directionality rule of their own. This is not a good idea, even if the authors have done a great deal of careful research into the problems of displaying bidirectional text. Instead, this document recommends the following: o For profiles based on the IdentifierClass, it is best to use the "Bidi Rule" from the IDNA2008 specification on right-to-left scripts [RFC5893]. o For profiles based on FreeformClass (or in situations where IdentifierClass is not appropriate), it is best to follow the recommendations of Unicode Standard Annex #9 [UAX9] directly. Peter From nobody Wed Feb 11 17:10:51 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 551861A88B4 for ; Wed, 11 Feb 2015 17:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcLJFE9GoHDO for ; Wed, 11 Feb 2015 17:10:30 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 097D61A88AD for ; Wed, 11 Feb 2015 17:10:29 -0800 (PST) Received: from mx1.yitter.info (116-193.icannmeeting.org [199.91.193.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 5847B8A035 for ; Thu, 12 Feb 2015 01:10:27 +0000 (UTC) Date: Thu, 12 Feb 2015 09:10:18 +0800 From: Andrew Sullivan To: precis@ietf.org Message-ID: <20150212011017.GA6759@mx1.yitter.info> References: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se> <54851FAD.4040009@andyet.net> <54D8EC54.8020203@qti.qualcomm.com> <54D8F98F.4050309@andyet.net> <54D910DC.1080003@andyet.net> <54D91BA8.6000705@qti.qualcomm.com> <54D93A77.9060102@andyet.net> <54DBCA9B.3050900@qti.qualcomm.com> <54DBF669.8080403@andyet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54DBF669.8080403@andyet.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [precis] Directionality rule (Was: Review of current document draft-ietf-precis-framework-20) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 01:10:32 -0000 I like this proposed change better. A On Wed, Feb 11, 2015 at 05:40:09PM -0700, Peter Saint-Andre - &yet wrote: > On 2/11/15 2:33 PM, Pete Resnick wrote: > >On 2/9/15 4:53 PM, Peter Saint-Andre - &yet wrote: > >>On 2/9/15 1:42 PM, Pete Resnick wrote: > >> > >>>But give me a bit to chat with Klensin and we'll see if we can come > >>>up with sanity. > >> > >>I agree that the Bidi Rule from RFC 5893 is designed for use with DNS > >>labels, and that it's not a perfect fit for PRECIS strings. But it > >>might be the best we can do right now. > > > >OK, here is some text that I worked on with John. We think this has the > >desirable properties that it is both as close to correct as we're going > >to get *and* what the WG intended. This is meant to be a replacement for > >all of the text in 5.2.5: > > > > The directionality rule of a profile specifies how to treat strings > > containing what are often called "right-to-left" (RTL) characters. > > RTL characters come from scripts that are normally written from right > > to left and are considered by Unicode to, themselves, have right to > > left directionality. Strings containing RTL characters often also > > contain "left-to-right" (LTR) characters, such as numerals, as well > > as characters without directional properties. Consequently, such > > strings are known as "bidirectional strings". Using bidirectional > > strings in different layout contexts may yield display results that, > > while predictable to those who understand the display rules, may be > > counter-intuitive to casual users. Therefore some profiles may wish > > to restrict their use by specifying a directionality rule. > > > > The PRECIS framework does not directly address how to deal with > > bidirectional strings, since there is currently no widely accepted > > and implemented solution for the safe display of arbitrary > > bidirectional strings beyond the general Unicode bidirectional > > specification [UAX9]. Rules for management and display of > > bidirectional strings have been defined for domain name labels and > > similar identifiers in the "Bidi Rule" from [RFC5893]. If a profile > > really needs to specify a directionality rule, unless a great deal of > > careful research into the problems of displaying bidirectional text > > is done (which is outside of the scope of this framework), this > > document generally recommends using the "Bidi Rule" from [RFC5893] > > for profiles based on IdentifierClass, and for profiles based on > > FreeformClass or other situations in which IdentifierClass is not > > appropriate, that consideration be given to using UAX #9 directly. > > > >What do you think? > > I think it's good up until the last sentence, which is convoluted. But the > tone is right and we might even want to borrow some text from Section 3 of > RFC 5895. ;-) > > A possible refactoring... > > OLD > If a profile > really needs to specify a directionality rule, unless a great deal of > careful research into the problems of displaying bidirectional text > is done (which is outside of the scope of this framework), this > document generally recommends using the "Bidi Rule" from [RFC5893] > for profiles based on IdentifierClass, and for profiles based on > FreeformClass or other situations in which IdentifierClass is not > appropriate, that consideration be given to using UAX #9 directly. > > NEW > The authors of a profile might think that they need to define a new > directionality rule of their own. This is not a good idea, even if > the authors have done a great deal of careful research into the > problems of displaying bidirectional text. Instead, this document > recommends the following: > > o For profiles based on the IdentifierClass, it is best to use the > "Bidi Rule" from the IDNA2008 specification on right-to-left > scripts [RFC5893]. > > o For profiles based on FreeformClass (or in situations where > IdentifierClass is not appropriate), it is best to follow the > recommendations of Unicode Standard Annex #9 [UAX9] directly. > > Peter > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Feb 11 17:38:51 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 743CF1A89F6 for ; Wed, 11 Feb 2015 17:38:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqn1pPX8jn60 for ; Wed, 11 Feb 2015 17:38:47 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C01161A89B1 for ; Wed, 11 Feb 2015 17:38:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1423705129; x=1455241129; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=TfD89xByUHMcscrIcAjPBXPQ7hc/2k+ItKuoMmlISio=; b=dIkEZcWCdSec/V1faGXazcnDSoShT7jASUGbe2/z243Lff2LgDI5O74l RVID/B18OP6/uOxj3GtWLnnPYtia0x6X8OXtGusmlEUU2j6/4ph9g8WoQ Dn5+X1jwgE6/lH8rH9HSyuAhj4vQiYLXcwoh04xoQ/QHGeiw+0KJBmCjN 4=; X-IronPort-AV: E=McAfee;i="5600,1067,7709"; a="83115221" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Feb 2015 17:38:48 -0800 X-IronPort-AV: E=Sophos;i="5.09,562,1418112000"; d="scan'208";a="903646080" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 11 Feb 2015 17:38:47 -0800 Received: from presnick-mac.local (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 11 Feb 2015 17:38:45 -0800 Message-ID: <54DC0422.8090201@qti.qualcomm.com> Date: Wed, 11 Feb 2015 19:38:42 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Peter Saint-Andre - &yet References: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se> <54851FAD.4040009@andyet.net> <54D8EC54.8020203@qti.qualcomm.com> <54D8F98F.4050309@andyet.net> <54D910DC.1080003@andyet.net> <54D91BA8.6000705@qti.qualcomm.com> <54D93A77.9060102@andyet.net> <54DBCA9B.3050900@qti.qualcomm.com> <54DBF669.8080403@andyet.net> In-Reply-To: <54DBF669.8080403@andyet.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01H.na.qualcomm.com (10.85.0.34) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Cc: precis@ietf.org Subject: Re: [precis] Directionality rule (Was: Review of current document draft-ietf-precis-framework-20) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 01:38:50 -0000 On 2/11/15 6:40 PM, Peter Saint-Andre - &yet wrote: > On 2/11/15 2:33 PM, Pete Resnick wrote: > > I think it's good up until the last sentence, which is convoluted. But > the tone is right and we might even want to borrow some text from > Section 3 of RFC 5895. ;-) > > A possible refactoring... > > OLD > If a profile > really needs to specify a directionality rule, unless a great deal of > careful research into the problems of displaying bidirectional text > is done (which is outside of the scope of this framework), this > document generally recommends using the "Bidi Rule" from [RFC5893] > for profiles based on IdentifierClass, and for profiles based on > FreeformClass or other situations in which IdentifierClass is not > appropriate, that consideration be given to using UAX #9 directly. > > NEW > The authors of a profile might think that they need to define a new > directionality rule of their own. This is not a good idea, even if > the authors have done a great deal of careful research into the > problems of displaying bidirectional text. Instead, this document > recommends the following: > > o For profiles based on the IdentifierClass, it is best to use the > "Bidi Rule" from the IDNA2008 specification on right-to-left > scripts [RFC5893]. > > o For profiles based on FreeformClass (or in situations where > IdentifierClass is not appropriate), it is best to follow the > recommendations of Unicode Standard Annex #9 [UAX9] directly. This misses an essential bit: The original sentence *does not* recommend using 5893 or UAX9, where your refactoring does. What I presented says, "*If* you think you need a directionality rule (and you probably don't), *then* use 5893 or UAX9." And even then, it says that if you're basing on IdentifierClass *and* you really need a directionality rule, we *generally* recommend 5893. If you're using FreeformClass *and* you think (for some completely insane reason) that you need a special directionality rule, you should give *consideration* to UAX9. If you want to refactor but still capture that, I'm OK. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Wed Feb 11 17:40:27 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888AE1A89B5 for ; Wed, 11 Feb 2015 17:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsVT39pDPyQg for ; Wed, 11 Feb 2015 17:40:23 -0800 (PST) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE5681A1AD3 for ; Wed, 11 Feb 2015 17:40:23 -0800 (PST) Received: by mail-ig0-f176.google.com with SMTP id hl2so799119igb.3 for ; Wed, 11 Feb 2015 17:40:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=BkgRY73FADSgqhzuLnVKMouMvL9n4WFhiuOJER5jId4=; b=K862HYlwHIxtl6ZN5Ol6k1spuqsV6it2rtyMPd5d7XvjGpgFaP4fQkuZgzSVDWJCPo DHqHw/bzp94yP60yFMahAGMxWk+FgKTJTY+Qs3t/yX54TmMP1vFoVTBcEl9S0icD2Lnv aCTBJ4ZrtXFlasJ1E9/K9jxaXlqlLMH4eevPyA5PgGEUZD7NvoqfEIY0aQyexvaNetmI Y7/55NfH9IeOgtedcXULeco1+RkwzlPlcn6W9A8XIa82A9H3F1kXS2ncDpJ4+VvW3uC1 81j1lUz5IHJS1DhZnbY1+6XxUadGqLpi3seL/K7ucUNqqqLe9mHZj4okK59Xl+byjHID Bimg== X-Gm-Message-State: ALoCoQlUVH03PBP3uw/XxH/+oXNqZEFRi6gswmx83TW38rsoA4q4oQ+QlA8S1L+V0hGxH4eTVErZ X-Received: by 10.107.148.7 with SMTP id w7mr1870870iod.73.1423705223136; Wed, 11 Feb 2015 17:40:23 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id mi3sm285785igb.13.2015.02.11.17.40.22 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Feb 2015 17:40:22 -0800 (PST) Message-ID: <54DC0485.2000708@andyet.net> Date: Wed, 11 Feb 2015 18:40:21 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Andrew Sullivan , precis@ietf.org References: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se> <54851FAD.4040009@andyet.net> <54D8EC54.8020203@qti.qualcomm.com> <54D8F98F.4050309@andyet.net> <54D910DC.1080003@andyet.net> <54D91BA8.6000705@qti.qualcomm.com> <54D93A77.9060102@andyet.net> <54DBCA9B.3050900@qti.qualcomm.com> <54DBF669.8080403@andyet.net> <20150212011017.GA6759@mx1.yitter.info> In-Reply-To: <20150212011017.GA6759@mx1.yitter.info> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [precis] Directionality rule (Was: Review of current document draft-ietf-precis-framework-20) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 01:40:25 -0000 On 2/11/15 6:10 PM, Andrew Sullivan wrote: > I like this proposed change better. So, putting it all together and tweaking a few words here and there... ### 5.2.5. Directionality Rule The directionality rule of a profile specifies how to treat strings containing what are often called "right-to-left" (RTL) characters (see Unicode Standard Annex #9 [UAX9]). RTL characters come from scripts that are normally written from right to left and are considered by Unicode to, themselves, have right to left directionality. Strings containing RTL characters often also contain "left-to-right" (LTR) characters, such as numerals, as well as characters without directional properties. Consequently, such strings are known as "bidirectional strings". Using bidirectional strings in different layout contexts can yield display results that, while predictable to those who understand the display rules, are counter-intuitive to casual users. Therefore some profiles might wish to restrict the use of bidirectional strings by specifying a directionality rule. The PRECIS framework does not directly address how to deal with bidirectional strings, since there is currently no widely accepted and implemented solution for the safe display of arbitrary bidirectional strings beyond the Unicode bidirectional algorithm [UAX9]. However, rules for management and display of bidirectional strings have been defined for domain name labels and similar identifiers in the "Bidi Rule" specified in the IDNA2008 specification on right-to-left scripts [RFC5893]. The authors of a profile might believe that they need to define a new directionality rule of their own. This is not a good idea, even if the authors have done a great deal of careful research into the problems of displaying bidirectional strings. Instead, this document recommends the following: o For profiles based on the IdentifierClass, it is best to use the "Bidi Rule" specified in [RFC5893]. o For profiles based on the FreeformClass (or in situations where the IdentifierClass is not appropriate), it is best to follow the Unicode bidirectional algorithm [UAX9] directly. ### From nobody Wed Feb 11 17:43:02 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF2C1A89FF for ; Wed, 11 Feb 2015 17:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucFyolkZDiYr for ; Wed, 11 Feb 2015 17:42:58 -0800 (PST) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36B371A8A05 for ; Wed, 11 Feb 2015 17:42:58 -0800 (PST) Received: by mail-ig0-f169.google.com with SMTP id hl2so2250854igb.0 for ; Wed, 11 Feb 2015 17:42:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2ylG2uJCzEXG5afcMGGg7zMjczpJVBydJNIbV+wKwjA=; b=Jh3QDlAk2TxhrCz9TI4xzjmKQzAJ8tHeogQnK9kQX3affdggm7vjXRJrLw/pqW+fSr uLf6z417UwkKhUb4jE33R6DsKlDxLQjTb5I/rT/H563jCBhJk/J1lXxXhMF9UEzBOtmL PxpeWMBroKUXse+dGOlQANIq2LSauSy0DDR+CwwTqMI39JYtoems3564w4nYnRpZWeG1 2KhBjE48V6zvOnkcpXk6uQw7qJJvwtM6u8xlUsY62egpI/il8+4sm8geDRk6Wp9iMZC7 JPqSfS0WK/4UqodbPM5rad+4LpdNEe/nXYNYXCw+Zz5jUiT848do2e7gGoLtdtJMBbae +7kQ== X-Gm-Message-State: ALoCoQmk9wrLmPZ4Z5FuY6pjrC/sFKbhVwCE1B6vGAdAz+/z0U6DioWmNKia85oSYVPurgWnx0Ij X-Received: by 10.50.254.4 with SMTP id ae4mr1114572igd.10.1423705377609; Wed, 11 Feb 2015 17:42:57 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id c4sm288766igt.19.2015.02.11.17.42.56 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Feb 2015 17:42:57 -0800 (PST) Message-ID: <54DC0520.6020601@andyet.net> Date: Wed, 11 Feb 2015 18:42:56 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Pete Resnick References: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se> <54851FAD.4040009@andyet.net> <54D8EC54.8020203@qti.qualcomm.com> <54D8F98F.4050309@andyet.net> <54D910DC.1080003@andyet.net> <54D91BA8.6000705@qti.qualcomm.com> <54D93A77.9060102@andyet.net> <54DBCA9B.3050900@qti.qualcomm.com> <54DBF669.8080403@andyet.net> <54DC0422.8090201@qti.qualcomm.com> In-Reply-To: <54DC0422.8090201@qti.qualcomm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: precis@ietf.org Subject: Re: [precis] Directionality rule (Was: Review of current document draft-ietf-precis-framework-20) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 01:43:01 -0000 On 2/11/15 6:38 PM, Pete Resnick wrote: > On 2/11/15 6:40 PM, Peter Saint-Andre - &yet wrote: >> On 2/11/15 2:33 PM, Pete Resnick wrote: >> >> I think it's good up until the last sentence, which is convoluted. But >> the tone is right and we might even want to borrow some text from >> Section 3 of RFC 5895. ;-) >> >> A possible refactoring... >> >> OLD >> If a profile >> really needs to specify a directionality rule, unless a great deal of >> careful research into the problems of displaying bidirectional text >> is done (which is outside of the scope of this framework), this >> document generally recommends using the "Bidi Rule" from [RFC5893] >> for profiles based on IdentifierClass, and for profiles based on >> FreeformClass or other situations in which IdentifierClass is not >> appropriate, that consideration be given to using UAX #9 directly. >> >> NEW >> The authors of a profile might think that they need to define a new >> directionality rule of their own. This is not a good idea, even if >> the authors have done a great deal of careful research into the >> problems of displaying bidirectional text. Instead, this document >> recommends the following: >> >> o For profiles based on the IdentifierClass, it is best to use the >> "Bidi Rule" from the IDNA2008 specification on right-to-left >> scripts [RFC5893]. >> >> o For profiles based on FreeformClass (or in situations where >> IdentifierClass is not appropriate), it is best to follow the >> recommendations of Unicode Standard Annex #9 [UAX9] directly. > > This misses an essential bit: The original sentence *does not* recommend > using 5893 or UAX9, where your refactoring does. What I presented says, > "*If* you think you need a directionality rule (and you probably don't), > *then* use 5893 or UAX9." Ah, you want the optative mood. :-) > And even then, it says that if you're basing > on IdentifierClass *and* you really need a directionality rule, we > *generally* recommend 5893. If you're using FreeformClass *and* you > think (for some completely insane reason) that you need a special > directionality rule, you should give *consideration* to UAX9. > > If you want to refactor but still capture that, I'm OK. OK, let me scribble here... Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed Feb 11 18:01:03 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D89351A8A48 for ; Wed, 11 Feb 2015 18:01:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwjWvvBrO-qm for ; Wed, 11 Feb 2015 18:00:58 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A97CB1A1AB2 for ; Wed, 11 Feb 2015 18:00:46 -0800 (PST) Received: from netb ([82.113.121.96]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MOwY7-1YH4dl0icp-006Liq; Thu, 12 Feb 2015 03:00:32 +0100 From: Bjoern Hoehrmann To: John C Klensin Date: Thu, 12 Feb 2015 03:00:29 +0100 Message-ID: References: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se> <54851FAD.4040009@andyet.net> <54D8EC54.8020203@qti.qualcomm.com> <54D8F98F.4050309@andyet.net> <54D910DC.1080003@andyet.net> <54D91BA8.6000705@qti.qualcomm.com> <54D93A77.9060102@andyet.net> <54DBCA9B.3050900@qti.qualcomm.com> <8uinda9tsm756uhr24pmuc1n2450b5v4fk@hive.bjoern.hoehrmann.de> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:cbwHkrvRtqJVlzRREWSBt4jxqEnpjEJw4U+2fwHw7nBs0eH4gPt jsNEkJDGisjzzxr9CqHIx93CZRKKho9HEDCAL2wQHyITkUSFkpi/i7YfjAAXWJ4wjA1Zssl fPTjs93HFZZASf4Yy5iNnPlEQXKdSgK4QdAk2T+jZdomCIDu1MWOBWOxwKNZqEQoSnrLsfY tgfM9xLHKna5BVsyF98Pg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: Pete Resnick , precis@ietf.org, Peter Saint-Andre - &yet Subject: Re: [precis] Directionality rule (Was: Review of current document draft-ietf-precis-framework-20) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 02:01:03 -0000 * John C Klensin wrote: >--On Wednesday, February 11, 2015 22:44 +0100 Bjoern Hoehrmann > wrote: >> I am not happy with "this document generally recommends"; it's >> not clear if this is the recommendation or if the >> recommendation is elswhere; it's also not clear if this a RFC >> 2119 RECOMMENDED or something weaker, made worse by >> "generally" and also the preceding "unless". Should be easy to >> rephrase, but I do not have a good idea right now. >Second, while this is up to Pete, the WG, and its leadership it >is getting late enough in the process that "I am not happy with" >--in the absence of specific suggestions -- is not very helpful. >We need to at least understand what you would like done, not >just that you don't like what is there (or proposed). The text "unless X this document generally recommends Y" is confusing. Consider: S This document recommends Y (see section P). P Y is RECOMMENDED [RFC2119]. Contrast with: S This document recommends Y. The latter case may be the result of intentionally removing the SHOULD- level requirement and forgetting to update a section re-stating it. Similarily, compare S Y is RECOMMENDED. and S This document recommends Y. In the latter case, did the authors deliberately decide to use a lower case non-keyword, or did they just phrase "Y is RECOMMENDED" poorly? Compare S Unless X, Y is RECOMMENDED. and S Unless X, Y is REQUIRED. Some would argue the two cases are essentially equivalent because RFC 2119 essentially defines "RECOMMENDED" as "REQUIRED unless". Others would argue "RECOMMENDED" is used to allow exceptions beyond "X". Compare S Unless X, Y is generally RECOMMENDED. S Unless X, Y is RECOMMENDED. Some would argue "generally" is used to allow exceptions beyond "X" while others would disagree. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/ From nobody Wed Feb 11 18:01:49 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621E21A8A25 for ; Wed, 11 Feb 2015 18:01:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IG-3ShGAfT2R for ; Wed, 11 Feb 2015 18:01:37 -0800 (PST) Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 499B21A8A52 for ; Wed, 11 Feb 2015 18:01:20 -0800 (PST) Received: by mail-ig0-f175.google.com with SMTP id hn18so870560igb.2 for ; Wed, 11 Feb 2015 18:01:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jbdM0mD2hfBoMJa3A/vaL9m0vvQ1MpRKXGpsi4KudZY=; b=AJm9VVbMLNzD5yx3z8fGHz/DA9JbuWAFQ6x3UlH6lpx/TsNMesHY/Z88ROYVhBV17u u+FsWyXmKoHcNpQj8I4g1f4hfXZAqM5Xg8OCiBuIuKpiVTd8YEVg5AKvwHj7tEAvHTad kSytTxVS3ruJHSb1ZwMdyZRI9XBVBTngOsgZ+7BW/xnaP9yc+rrCxiD2hXRX0fP6UqdN wq0lq6mxpgtX08c/IOgByrBSOq82jZ9ovETOOiADcPF5P/LKGkNCaZxsCGal6XGH5Nyt i87MycIl85luEDKJNPleFh7Y6gmjot+eOVDe0GOajl1IyHHT0yO95c8gP0Duc/icOH+M Eacg== X-Gm-Message-State: ALoCoQmV526bDJsRBfnQfTeBn4Gp4E0vH4bOfRY5SsT7Jq1IMiw6IRtf6lRm9MkjHXKUo8UDK8Ak X-Received: by 10.43.74.201 with SMTP id yx9mr6181810icb.96.1423706479782; Wed, 11 Feb 2015 18:01:19 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id mi3sm316963igb.13.2015.02.11.18.01.11 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Feb 2015 18:01:15 -0800 (PST) Message-ID: <54DC0903.5080204@andyet.net> Date: Wed, 11 Feb 2015 18:59:31 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Pete Resnick References: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se> <54851FAD.4040009@andyet.net> <54D8EC54.8020203@qti.qualcomm.com> <54D8F98F.4050309@andyet.net> <54D910DC.1080003@andyet.net> <54D91BA8.6000705@qti.qualcomm.com> <54D93A77.9060102@andyet.net> <54DBCA9B.3050900@qti.qualcomm.com> <54DBF669.8080403@andyet.net> <54DC0422.8090201@qti.qualcomm.com> <54DC0520.6020601@andyet.net> In-Reply-To: <54DC0520.6020601@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: precis@ietf.org Subject: Re: [precis] Directionality rule (Was: Review of current document draft-ietf-precis-framework-20) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 02:01:47 -0000 On 2/11/15 6:42 PM, Peter Saint-Andre - &yet wrote: > On 2/11/15 6:38 PM, Pete Resnick wrote: >> On 2/11/15 6:40 PM, Peter Saint-Andre - &yet wrote: >>> On 2/11/15 2:33 PM, Pete Resnick wrote: >>> >>> I think it's good up until the last sentence, which is convoluted. But >>> the tone is right and we might even want to borrow some text from >>> Section 3 of RFC 5895. ;-) >>> >>> A possible refactoring... >>> >>> OLD >>> If a profile >>> really needs to specify a directionality rule, unless a great deal of >>> careful research into the problems of displaying bidirectional text >>> is done (which is outside of the scope of this framework), this >>> document generally recommends using the "Bidi Rule" from [RFC5893] >>> for profiles based on IdentifierClass, and for profiles based on >>> FreeformClass or other situations in which IdentifierClass is not >>> appropriate, that consideration be given to using UAX #9 directly. >>> >>> NEW >>> The authors of a profile might think that they need to define a new >>> directionality rule of their own. This is not a good idea, even if >>> the authors have done a great deal of careful research into the >>> problems of displaying bidirectional text. Instead, this document >>> recommends the following: >>> >>> o For profiles based on the IdentifierClass, it is best to use the >>> "Bidi Rule" from the IDNA2008 specification on right-to-left >>> scripts [RFC5893]. >>> >>> o For profiles based on FreeformClass (or in situations where >>> IdentifierClass is not appropriate), it is best to follow the >>> recommendations of Unicode Standard Annex #9 [UAX9] directly. >> >> This misses an essential bit: The original sentence *does not* recommend >> using 5893 or UAX9, where your refactoring does. What I presented says, >> "*If* you think you need a directionality rule (and you probably don't), >> *then* use 5893 or UAX9." > > Ah, you want the optative mood. :-) > >> And even then, it says that if you're basing >> on IdentifierClass *and* you really need a directionality rule, we >> *generally* recommend 5893. If you're using FreeformClass *and* you >> think (for some completely insane reason) that you need a special >> directionality rule, you should give *consideration* to UAX9. >> >> If you want to refactor but still capture that, I'm OK. > > OK, let me scribble here... How's this? The authors of a profile might believe that they need to define a new directionality rule of their own. Because of the complexity of the issues involved, such a belief is almost always misguided, even if the authors have done a great deal of careful research into the problems of displaying bidirectional strings. This document suggests that profile authors who are thinking about defining a new directionality rule think again, and instead consider using the "Bidi Rule" [RFC5893] (for profiles based on the IdentifierClass) or following the Unicode bidirectional algorithm [UAX9] directly (for profiles based on the FreeformClass or in situations where the IdentifierClass is not appropriate). One thing that bothers me here is that we're not providing actionable guidance to the vast majority of non-delusional profile authors. Are we saying that it's not a good idea to say anything about directionality at all? Peter From nobody Thu Feb 12 07:50:17 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1051A9172 for ; Thu, 12 Feb 2015 07:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekiBW45FYvWG for ; Thu, 12 Feb 2015 07:50:12 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 980D51A888A for ; Thu, 12 Feb 2015 07:50:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1423756212; x=1455292212; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=dkcYaL+Za4wVQLMA4GmPXO52FyXplg8bar2+RL69Rc4=; b=PlI7jEo0M3RQbpg19aW0n+ZscPRYL1fP52BmFSEn0KWuAhB+AeunMX2p +zZgTy5ulHpwMf5RWxh5yyGSU/pF+Ku/ztMN+XcELpIvpRXqqRUGmTL4c 3NEkcDrlsNEe7DuBzYdg48ueVMuTXDdUC4VsH6DUHVipnEKMZ9ry4HM8b Q=; X-IronPort-AV: E=McAfee;i="5600,1067,7709"; a="83152728" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Feb 2015 07:50:12 -0800 X-IronPort-AV: E=Sophos;i="5.09,565,1418112000"; d="scan'208";a="850226799" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 12 Feb 2015 07:50:13 -0800 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 12 Feb 2015 07:50:11 -0800 Message-ID: <54DCCBB2.1090601@qti.qualcomm.com> Date: Thu, 12 Feb 2015 09:50:10 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Peter Saint-Andre - &yet References: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se> <54851FAD.4040009@andyet.net> <54D8EC54.8020203@qti.qualcomm.com> <54D8F98F.4050309@andyet.net> <54D910DC.1080003@andyet.net> <54D91BA8.6000705@qti.qualcomm.com> <54D93A77.9060102@andyet.net> <54DBCA9B.3050900@qti.qualcomm.com> <54DBF669.8080403@andyet.net> <54DC0422.8090201@qti.qualcomm.com> <54DC0520.6020601@andyet.net> <54DC0903.5080204@andyet.net> In-Reply-To: <54DC0903.5080204@andyet.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01E.na.qualcomm.com (10.85.0.31) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Cc: precis@ietf.org Subject: Re: [precis] Directionality rule (Was: Review of current document draft-ietf-precis-framework-20) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 15:50:15 -0000 On 2/11/15 7:59 PM, Peter Saint-Andre - &yet wrote: > One thing that bothers me here is that we're not providing actionable > guidance to the vast majority of non-delusional profile authors. Are > we saying that it's not a good idea to say anything about > directionality at all? In my mind there are two possibilities that a profile author ends up with: 1. My application doesn't care whether the strings I'm using appear differently in different contexts. If a string looks one way to a person on a LTR system and a different way to a person on an RTL system, that's fine. I don't care what order the characters appear (for instance, if numerals appear before or after punctuation). or: 2. I want my strings to appear consistently. Numerals appearing on one side of a dot on an LTR system and on the other side of a dot on an RTL system would be a really bad thing. If 1, your profile should say, "Directionality Rule: None". If 2, then you want "Directionality Rule: Something", and unless you have some magic specialized knowledge (that you don't, trust us), you want "Directionality Rule: 5893". And, BTW, you had better be basing things on IdentifierClass; 5893 is *not* sane if you're basing on FreeformClass, and you probably meant to give answer #1 above. Do we agree that the above is what the WG is saying? If so, does the text capture that? pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Thu Feb 12 10:09:01 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE731A07BD for ; Thu, 12 Feb 2015 10:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yh02JYLXjA4N for ; Thu, 12 Feb 2015 10:08:44 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45AB31A1B13 for ; Thu, 12 Feb 2015 10:08:25 -0800 (PST) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YLyBa-0002DQ-GB; Thu, 12 Feb 2015 13:08:22 -0500 Date: Thu, 12 Feb 2015 13:08:17 -0500 From: John C Klensin To: Peter Saint-Andre - &yet , Pete Resnick Message-ID: <46C6F7ABEBCC650C90B227E9@JcK-HP8200.jck.com> In-Reply-To: <54DC0903.5080204@andyet.net> References: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se> <54851FAD.4040009@andyet.net> <54D8EC54.8020203@qti.qualcomm.com> <54D8F98F.4050309@andyet.net> <54D910DC.1080003@andyet.net> <54D91BA8.6000705@qti.qualcomm.com> <54D93A77.9060102@andyet.net> <54DBCA9B.3050900@qti.qualcomm.com> <54DBF669.8080403@andyet.net> <54DC0422.8090201@qti.qualcomm.com> <54DC0520.6020601@andyet.net> <54DC0903.5080204@andyet.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: precis@ietf.org Subject: Re: [precis] Directionality rule (Was: Review of current document draft-ietf-precis-framework-20) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 18:08:53 -0000 --On Wednesday, February 11, 2015 18:59 -0700 Peter Saint-Andre - &yet wrote: >... > How's this? > The authors of a profile might believe that they need to > define a new directionality rule of their own. Because of the > complexity of the issues involved, such a belief is almost > always misguided, even if the authors have done a great deal > of careful research into the problems of displaying > bidirectional strings. This document suggests that profile > authors who are thinking about defining a new directionality > rule think again, and instead consider using the "Bidi Rule" > [RFC5893] (for profiles based on the IdentifierClass) or > following the Unicode bidirectional algorithm [UAX9] directly > (for profiles based on the FreeformClass or in situations > where the IdentifierClass is not appropriate). Wfm. > One thing that bothers me here is that we're not providing > actionable guidance to the vast majority of non-delusional > profile authors. Are we saying that it's not a good idea to > say anything about directionality at all? I think I don't understand what you are saying/ asking for. It seems to me that every version of the statement posted to the list in the last 24 hours has said things that come down to: (1) Directionality can be tricky. (not actionable, but important context) (2) If you have something identifier-like, use 5893 unless you know better. (3) If you have something more free form-like, use UAX #9 unless you know better. (4) If you think you know better, you are probably wrong; see above. (2) and (3) are, AFAICT, about as actionable as things get, representing clear statement of the character of "if then do this..." The "unless you know better" statements and (4) is a warning about (2) and (3) to avoid our getting too normative about situations we can't anticipate The only substantive difference I've seen in the various statements is whether the equivalent to (3) suggests saying as little as possible about FreeformClass. I'd rather we didn't, but the above could be restated in 2119-speak as: (2) If you have something identifier-like, you SHOULD use 5893. (3) If you have something more free form-like, you SHOULD use UAX #9. (1) and (4) Directionality is tricky. If you have specific knowledge of the characters or script(s) you are using that the contexts in which they are used, you MAY invent your own techniques and specifications, as allowed by the above. However, there is considerable experience to indicate that you should not do so unless it is also absolutely necessary because you are likely to get it wrong and, even if you don't, adopting rules different from 5893 or UAX 9 is likely to confuse and irritate users. john From nobody Thu Feb 12 13:11:06 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F841A1B2A for ; Thu, 12 Feb 2015 13:10:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnDwO-cI7-Cf for ; Thu, 12 Feb 2015 13:10:52 -0800 (PST) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC62E1A0AFE for ; Thu, 12 Feb 2015 13:10:51 -0800 (PST) Received: by iecat20 with SMTP id at20so15035471iec.12 for ; Thu, 12 Feb 2015 13:10:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6OueiGkdbmRT2lH9TmS6ri9W1203HBVtgO6gzHGUMDE=; b=U5SY0mGbQeR1AESnrr9V+9XFPKTJAlel83HalywsIQNGsf/T5D6zdoktkz8NCpRRgN 9ldzFm3VgA6iPRfij58Fs0L2sK3Kr4//3eFtUKljDRrsUn2VJ007jMksOOzSgt2r49M4 Ao8maoPV+nihrHBP0CthYI0z7Yk9pcX322SYvipaoE3vWprIBzCeh+S+gQYkwEOBMge5 T9FqFWbXIjvjQx0fBa+nFXS8m4k+hJFzDp/c7KOThRPFEdvh5g4d9iZOK7J8wJFd1eFD 1oZG9MbNJJ4jDj8aI8fCoWmrxgda+17DeI83n34N6lJRMTc96RhAJErEvbCtf0THngwx UfXg== X-Gm-Message-State: ALoCoQlvTkmGITWfYyD3eD881lE+HSSfA1Nr+j9nDNZsaag+BDhznMxOUaDtPAeIPfPw2vtLWARP X-Received: by 10.50.30.130 with SMTP id s2mr6543856igh.11.1423775451164; Thu, 12 Feb 2015 13:10:51 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id sd7sm1891216igb.20.2015.02.12.13.10.50 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Feb 2015 13:10:50 -0800 (PST) Message-ID: <54DD16D9.50804@andyet.net> Date: Thu, 12 Feb 2015 14:10:49 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Pete Resnick References: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se> <54851FAD.4040009@andyet.net> <54D8EC54.8020203@qti.qualcomm.com> <54D8F98F.4050309@andyet.net> <54D910DC.1080003@andyet.net> <54D91BA8.6000705@qti.qualcomm.com> <54D93A77.9060102@andyet.net> <54DBCA9B.3050900@qti.qualcomm.com> <54DBF669.8080403@andyet.net> <54DC0422.8090201@qti.qualcomm.com> <54DC0520.6020601@andyet.net> <54DC0903.5080204@andyet.net> <54DCCBB2.1090601@qti.qualcomm.com> In-Reply-To: <54DCCBB2.1090601@qti.qualcomm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: precis@ietf.org Subject: Re: [precis] Directionality rule (Was: Review of current document draft-ietf-precis-framework-20) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 21:10:54 -0000 On 2/12/15 8:50 AM, Pete Resnick wrote: > On 2/11/15 7:59 PM, Peter Saint-Andre - &yet wrote: >> One thing that bothers me here is that we're not providing actionable >> guidance to the vast majority of non-delusional profile authors. Are >> we saying that it's not a good idea to say anything about >> directionality at all? > > In my mind there are two possibilities that a profile author ends up with: > > 1. My application doesn't care whether the strings I'm using appear > differently in different contexts. If a string looks one way to a person > on a LTR system and a different way to a person on an RTL system, that's > fine. I don't care what order the characters appear (for instance, if > numerals appear before or after punctuation). > > or: > > 2. I want my strings to appear consistently. Numerals appearing on one > side of a dot on an LTR system and on the other side of a dot on an RTL > system would be a really bad thing. > > If 1, your profile should say, "Directionality Rule: None". > > If 2, then you want "Directionality Rule: Something", and unless you > have some magic specialized knowledge (that you don't, trust us), you > want "Directionality Rule: 5893". And, BTW, you had better be basing > things on IdentifierClass; 5893 is *not* sane if you're basing on > FreeformClass, and you probably meant to give answer #1 above. > > Do we agree that the above is what the WG is saying? That seems reasonable. > If so, does the text capture that? Not quite. We capture the conclusions but not the reasoning. Let me see if I can formulate some text... Peter From nobody Thu Feb 12 13:39:59 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3EE1A1B96 for ; Thu, 12 Feb 2015 13:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ysOFvCq3ZGY for ; Thu, 12 Feb 2015 13:39:55 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6C1F1A1B65 for ; Thu, 12 Feb 2015 13:39:54 -0800 (PST) Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1CLdqxL015048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Feb 2015 16:39:53 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com t1CLdqxL015048 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1423777193; bh=/DsEZVTAI56EKWG2pOMAgAIQSU4=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=i/pLY+vKP3TDTj7ZQeQ1xvMZ778sUsfjbrCtg2xmnAVpbHowD0Vejkjkd2dExHaPY g2c2wnLb8WHzZfjZh+cAPRQ0/5/2rCJEZC+eoj4rGsge8CD2EgK9DkW05vpFzjcTJH SNrKSOGflU9612FE+Q07R20QAMPnIH9FZ8d0Kg20= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com t1CLdqxL015048 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd05.lss.emc.com (RSA Interceptor); Thu, 12 Feb 2015 16:39:38 -0500 Received: from mxhub02.corp.emc.com (mxhub02.corp.emc.com [10.254.141.104]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1CLdaBJ003488 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Feb 2015 16:39:39 -0500 Received: from MXHUB204.corp.emc.com (10.253.68.30) by mxhub02.corp.emc.com (10.254.141.104) with Microsoft SMTP Server (TLS) id 8.3.327.1; Thu, 12 Feb 2015 16:39:35 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.236]) by MXHUB204.corp.emc.com ([10.253.68.30]) with mapi id 14.03.0195.001; Thu, 12 Feb 2015 16:39:04 -0500 From: "Black, David" To: John C Klensin Thread-Topic: [precis] Directionality rule (Was: Review of current document draft-ietf-precis-framework-20) Thread-Index: AQHQRIzcncKxLPuVSkyKdaThVMVzQpzo89mAgAAbxwCAAAzfAIAAJLqAgAMOLoCAADQ4gIAAEFwAgAABLwCAAASigIABDqyA///lWQA= Date: Thu, 12 Feb 2015 21:39:04 +0000 Message-ID: References: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se> <54851FAD.4040009@andyet.net> <54D8EC54.8020203@qti.qualcomm.com> <54D8F98F.4050309@andyet.net> <54D910DC.1080003@andyet.net> <54D91BA8.6000705@qti.qualcomm.com> <54D93A77.9060102@andyet.net> <54DBCA9B.3050900@qti.qualcomm.com> <54DBF669.8080403@andyet.net> <54DC0422.8090201@qti.qualcomm.com> <54DC0520.6020601@andyet.net> <54DC0903.5080204@andyet.net> <46C6F7ABEBCC650C90B227E9@JcK-HP8200.jck.com> In-Reply-To: <46C6F7ABEBCC650C90B227E9@JcK-HP8200.jck.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.129] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "precis@ietf.org" Subject: Re: [precis] Directionality rule (Was: Review of current document draft-ietf-precis-framework-20) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 21:39:58 -0000 > (1) Directionality can be tricky. (not actionable, but > important context) > (2) If you have something identifier-like, use 5893 unless you > know better. > (3) If you have something more free form-like, use UAX #9 unless > you know better. > (4) If you think you know better, you are probably wrong; see > above. +1 - I like that listing of principles. Items (2) and (3) look like they could be stated with "SHOULD" although I could live with weaker wording. In contrast, I think the text for (4) ought to definitely say "SHOULD NOT define a new directionality rule" and that ought to be called out in the IANA Considerations for the profiles registry in section 11.3 as important guidance to the designated expert reviewer(s). Thanks, --David > -----Original Message----- > From: precis [mailto:precis-bounces@ietf.org] On Behalf Of John C Klensin > Sent: Thursday, February 12, 2015 1:08 PM > To: Peter Saint-Andre - &yet; Pete Resnick > Cc: precis@ietf.org > Subject: Re: [precis] Directionality rule (Was: Review of current documen= t > draft-ietf-precis-framework-20) >=20 >=20 >=20 > --On Wednesday, February 11, 2015 18:59 -0700 Peter Saint-Andre > - &yet wrote: >=20 > >... > > How's this? >=20 > > The authors of a profile might believe that they need to > > define a new directionality rule of their own. Because of the > > complexity of the issues involved, such a belief is almost > > always misguided, even if the authors have done a great deal > > of careful research into the problems of displaying > > bidirectional strings. This document suggests that profile > > authors who are thinking about defining a new directionality > > rule think again, and instead consider using the "Bidi Rule" > > [RFC5893] (for profiles based on the IdentifierClass) or > > following the Unicode bidirectional algorithm [UAX9] directly > > (for profiles based on the FreeformClass or in situations > > where the IdentifierClass is not appropriate). >=20 > Wfm. >=20 > > One thing that bothers me here is that we're not providing > > actionable guidance to the vast majority of non-delusional > > profile authors. Are we saying that it's not a good idea to > > say anything about directionality at all? >=20 > I think I don't understand what you are saying/ asking for. It > seems to me that every version of the statement posted to the > list in the last 24 hours has said things that come down to: >=20 > (1) Directionality can be tricky. (not actionable, but > important context) > (2) If you have something identifier-like, use 5893 unless you > know better. > (3) If you have something more free form-like, use UAX #9 unless > you know better. > (4) If you think you know better, you are probably wrong; see > above. >=20 > (2) and (3) are, AFAICT, about as actionable as things get, > representing clear statement of the character of "if > then do this..." The "unless you know better" statements and > (4) is a warning about (2) and (3) to avoid our getting too > normative about situations we can't anticipate >=20 > The only substantive difference I've seen in the various > statements is whether the equivalent to (3) suggests saying as > little as possible about FreeformClass. >=20 > I'd rather we didn't, but the above could be restated in > 2119-speak as: >=20 > (2) If you have something identifier-like, you SHOULD use 5893. > (3) If you have something more free form-like, you SHOULD use > UAX #9. > (1) and (4) Directionality is tricky. If you have specific > knowledge of the characters or script(s) you are using that the > contexts in which they are used, you MAY invent your own > techniques and specifications, as allowed by the above. > However, there is considerable experience to indicate that you > should not do so unless it is also absolutely necessary because > you are likely to get it wrong and, even if you don't, adopting > rules different from 5893 or UAX 9 is likely to confuse and > irritate users. >=20 > john >=20 > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis From nobody Thu Feb 12 13:48:47 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0301A1A31 for ; Thu, 12 Feb 2015 13:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pjykCPBd4eL for ; Thu, 12 Feb 2015 13:48:43 -0800 (PST) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BCF51A028A for ; Thu, 12 Feb 2015 13:48:43 -0800 (PST) Received: by mail-ig0-f173.google.com with SMTP id a13so6822691igq.0 for ; Thu, 12 Feb 2015 13:48:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Yalxer/Gl4OlMYQy8Zq89dXRPwthX59AwvtpyOp4ysU=; b=jHbwyUuTTXHOIBMV2TY4xlmotqcJcTOOK3/QTvuVT/BQCgy5eLLp0vsEyfoEIi4xYK XjlJCTY+nHKkrOjjLxL3iD4IF/axaKd5yytfN6g4YPY7zsp6Bit97HSrDFsjycGfSf/7 m9HmSVDQL/iFMtawZCcrK0qzcQj+qK5Prs+AvMWPMDiA6BQ/7NNtt/oF9ax1B1jL8ZHG D9ocDfBpQtrnYSH/yR3pHBsbr52j/FRbF+pd+o6C/x9h8onTmPDV9IKg/ursm3JGLbtQ y1v7dTc6ZTggblUrHJetODXGWjDcey/685ZcxIDjGXZ1jSilJOmt61FjKKAcY+Ya2ooN gFyw== X-Gm-Message-State: ALoCoQnmxqXPEDMUjm93Mq2bTHIKxQ+ItVeUM4jD8ndGuL1xtoztK7EYxyAbNF5wPWIIjPY6bOWD X-Received: by 10.42.223.194 with SMTP id il2mr10934434icb.94.1423777722898; Thu, 12 Feb 2015 13:48:42 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id 30sm1057488iok.15.2015.02.12.13.48.41 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Feb 2015 13:48:42 -0800 (PST) Message-ID: <54DD1FB9.8040309@andyet.net> Date: Thu, 12 Feb 2015 14:48:41 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Pete Resnick References: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se> <54851FAD.4040009@andyet.net> <54D8EC54.8020203@qti.qualcomm.com> <54D8F98F.4050309@andyet.net> <54D910DC.1080003@andyet.net> <54D91BA8.6000705@qti.qualcomm.com> <54D93A77.9060102@andyet.net> <54DBCA9B.3050900@qti.qualcomm.com> <54DBF669.8080403@andyet.net> <54DC0422.8090201@qti.qualcomm.com> <54DC0520.6020601@andyet.net> <54DC0903.5080204@andyet.net> <54DCCBB2.1090601@qti.qualcomm.com> <54DD16D9.50804@andyet.net> In-Reply-To: <54DD16D9.50804@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: precis@ietf.org Subject: Re: [precis] Directionality rule (Was: Review of current document draft-ietf-precis-framework-20) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 21:48:45 -0000 On 2/12/15 2:10 PM, Peter Saint-Andre - &yet wrote: > On 2/12/15 8:50 AM, Pete Resnick wrote: >> On 2/11/15 7:59 PM, Peter Saint-Andre - &yet wrote: >>> One thing that bothers me here is that we're not providing actionable >>> guidance to the vast majority of non-delusional profile authors. Are >>> we saying that it's not a good idea to say anything about >>> directionality at all? >> >> In my mind there are two possibilities that a profile author ends up >> with: >> >> 1. My application doesn't care whether the strings I'm using appear >> differently in different contexts. If a string looks one way to a person >> on a LTR system and a different way to a person on an RTL system, that's >> fine. I don't care what order the characters appear (for instance, if >> numerals appear before or after punctuation). >> >> or: >> >> 2. I want my strings to appear consistently. Numerals appearing on one >> side of a dot on an LTR system and on the other side of a dot on an RTL >> system would be a really bad thing. >> >> If 1, your profile should say, "Directionality Rule: None". >> >> If 2, then you want "Directionality Rule: Something", and unless you >> have some magic specialized knowledge (that you don't, trust us), you >> want "Directionality Rule: 5893". And, BTW, you had better be basing >> things on IdentifierClass; 5893 is *not* sane if you're basing on >> FreeformClass, and you probably meant to give answer #1 above. >> >> Do we agree that the above is what the WG is saying? > > That seems reasonable. > >> If so, does the text capture that? > > Not quite. We capture the conclusions but not the reasoning. Let me see > if I can formulate some text... Here you go... ### 5.2.5. Directionality Rule The directionality rule of a profile specifies how to treat strings containing what are often called "right-to-left" (RTL) characters (see Unicode Standard Annex #9 [UAX9]). RTL characters come from scripts that are normally written from right to left and are considered by Unicode to, themselves, have right to left directionality. Strings containing RTL characters often also contain "left-to-right" (LTR) characters, such as numerals, as well as characters without directional properties. Consequently, such strings are known as "bidirectional strings". Presenting bidirectional strings in different layout systems (e.g., a user interface that is configured to handle primarily an RTL script vs. an interface that is configured to handle primarily an LTR script) can yield display results that, while predictable to those who understand the display rules, are counter-intuitive to casual users. In particular, the same bidirectional string (in PRECIS terms) might not be presented in the same way to users of those different layout systems, even though they are consistent within any particular layout system. In some applications, these presentation differences might be considered problematic and thus the application designers might wish to restrict the use of bidirectional strings by specifying a directionality rule. In other applications, these presentation differences might not be considered problematic (this especially tends to be true of more "free-form" strings) and thus no directionality rule is needed. The PRECIS framework does not directly address how to deal with bidirectional strings across all string classes and profiles, and does not define any new directionality rules, since at present there is no widely accepted and implemented solution for the safe display of arbitrary bidirectional strings beyond the Unicode bidirectional algorithm [UAX9]. Although rules for management and display of bidirectional strings have been defined for domain name labels and similar identifiers through the "Bidi Rule" specified in the IDNA2008 specification on right-to-left scripts [RFC5893], those rules are quite restrictive and are not necessarily applicable to all bidirectional strings. The authors of a PRECIS profile might believe that they need to define a new directionality rule of their own. Because of the complexity of the issues involved, such a belief is almost always misguided, even if the authors have done a great deal of careful research into the challenges of displaying bidirectional strings. This document strongly suggests that profile authors who are thinking about defining a new directionality rule think again, and instead consider using the "Bidi Rule" [RFC5893] (for profiles based on the IdentifierClass) or following the Unicode bidirectional algorithm [UAX9] directly (for profiles based on the FreeformClass or in situations where the IdentifierClass is not appropriate). ### From nobody Thu Feb 12 14:22:39 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F23A1A044D for ; Thu, 12 Feb 2015 14:22:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id doOtYJtBNQkh for ; Thu, 12 Feb 2015 14:22:32 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 570F91A039C for ; Thu, 12 Feb 2015 14:22:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1423779752; x=1455315752; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=LbwYElvDqrfv7UIXvFRDr2iDzABDZua66vKdZTbXb/c=; b=xrZUFFH4EETimnHipBwyPZOitrK5IKmWO64I629CZ6f0+QMoOdPS7AlH +xmpaFYrpBHj3Uwi7Dc4yKsZMYnnfXZ1nPGNUykjnA2It1Nj4hIQ/0PUa geRxmarIimvQCApHOuvxO1QwsRz6FIIy+7RniwY+XyZtiF671t5ojS/jl 4=; X-IronPort-AV: E=McAfee;i="5600,1067,7710"; a="83985551" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Feb 2015 14:22:31 -0800 X-IronPort-AV: E=Sophos;i="5.09,567,1418112000"; d="scan'208";a="813770732" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 12 Feb 2015 14:22:31 -0800 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 12 Feb 2015 14:22:30 -0800 Message-ID: <54DD27A4.2080701@qti.qualcomm.com> Date: Thu, 12 Feb 2015 16:22:28 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Peter Saint-Andre - &yet References: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se> <54851FAD.4040009@andyet.net> <54D8EC54.8020203@qti.qualcomm.com> <54D8F98F.4050309@andyet.net> <54D910DC.1080003@andyet.net> <54D91BA8.6000705@qti.qualcomm.com> <54D93A77.9060102@andyet.net> <54DBCA9B.3050900@qti.qualcomm.com> <54DBF669.8080403@andyet.net> <54DC0422.8090201@qti.qualcomm.com> <54DC0520.6020601@andyet.net> <54DC0903.5080204@andyet.net> <54DCCBB2.1090601@qti.qualcomm.com> <54DD16D9.50804@andyet.net> <54DD1FB9.8040309@andyet.net> In-Reply-To: <54DD1FB9.8040309@andyet.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (10.85.0.81) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Cc: precis@ietf.org Subject: Re: [precis] Directionality rule (Was: Review of current document draft-ietf-precis-framework-20) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 22:22:35 -0000 I don't think I could do any better than the below. Thanks. pr On 2/12/15 3:48 PM, Peter Saint-Andre - &yet wrote: > ### > > 5.2.5. Directionality Rule > > The directionality rule of a profile specifies how to treat strings > containing what are often called "right-to-left" (RTL) characters > (see Unicode Standard Annex #9 [UAX9]). RTL characters come from > scripts that are normally written from right to left and are > considered by Unicode to, themselves, have right to left > directionality. Strings containing RTL characters often also contain > "left-to-right" (LTR) characters, such as numerals, as well as > characters without directional properties. Consequently, such > strings are known as "bidirectional strings". > > Presenting bidirectional strings in different layout systems (e.g., a > user interface that is configured to handle primarily an RTL script > vs. an interface that is configured to handle primarily an LTR > script) can yield display results that, while predictable to those > who understand the display rules, are counter-intuitive to casual > users. In particular, the same bidirectional string (in PRECIS > terms) might not be presented in the same way to users of those > different layout systems, even though they are consistent within any > particular layout system. In some applications, these presentation > differences might be considered problematic and thus the application > designers might wish to restrict the use of bidirectional strings by > specifying a directionality rule. In other applications, these > presentation differences might not be considered problematic (this > especially tends to be true of more "free-form" strings) and thus no > directionality rule is needed. > > The PRECIS framework does not directly address how to deal with > bidirectional strings across all string classes and profiles, and > does not define any new directionality rules, since at present there > is no widely accepted and implemented solution for the safe display > of arbitrary bidirectional strings beyond the Unicode bidirectional > algorithm [UAX9]. Although rules for management and display of > bidirectional strings have been defined for domain name labels and > similar identifiers through the "Bidi Rule" specified in the IDNA2008 > specification on right-to-left scripts [RFC5893], those rules are > quite restrictive and are not necessarily applicable to all > bidirectional strings. > > The authors of a PRECIS profile might believe that they need to > define a new directionality rule of their own. Because of the > complexity of the issues involved, such a belief is almost always > misguided, even if the authors have done a great deal of careful > research into the challenges of displaying bidirectional strings. > This document strongly suggests that profile authors who are thinking > about defining a new directionality rule think again, and instead > consider using the "Bidi Rule" [RFC5893] (for profiles based on the > IdentifierClass) or following the Unicode bidirectional algorithm > [UAX9] directly (for profiles based on the FreeformClass or in > situations where the IdentifierClass is not appropriate). > > ### > -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Thu Feb 12 15:05:25 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA2CE1A008F for ; Thu, 12 Feb 2015 15:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elWSOFGmGyu9 for ; Thu, 12 Feb 2015 15:05:16 -0800 (PST) Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCCCE1A0A85 for ; Thu, 12 Feb 2015 15:05:15 -0800 (PST) Received: by mail-ig0-f178.google.com with SMTP id hl2so7203829igb.5 for ; Thu, 12 Feb 2015 15:05:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=If3+6XKl7KVRREA74hcKCoxuRBKYh+wDF/gMz6emTWU=; b=BtroHJRGzbGQF3q/8+gyFStFlzU08wNCE8MOCArMdLTtrzPQ+mQBLgIEWCWJx5WKyh WXiOWPiDDNJWxZfk7ARlfW25J9iDqCrIyhkngoaVTZjhgR/SzNWZHwmX3pNqcInc7B0/ YPUtreVAoX1VrqxBhXNjQUldt+bcW9wFbik3WVjdU/gZ/O0aLVitpFjYUN2f+z/DwsGO mPQIag6+VDsGsX9d2w9+IeDLyIMZU3JgYIpvhrCCPFQ6Fc/J0JZdI40KyzgF7CXNHRnC +Gfu4Lu5AFN4tFGPLd9SmpxKfkH9by5H6BwxOyFnwqQ0oBpT6c5FCNHM7W8q7qCRRtgg kN6g== X-Gm-Message-State: ALoCoQkRVUl3bZQglruE3LsMBIswwkSIZZlKS2wsjnsiXfaY7pgIxCCU6tmRNjvjwiiR1SpTNr/r X-Received: by 10.50.107.36 with SMTP id gz4mr7129563igb.25.1423782315163; Thu, 12 Feb 2015 15:05:15 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id d1sm2087084igr.20.2015.02.12.15.05.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Feb 2015 15:05:14 -0800 (PST) Message-ID: <54DD31A9.7000707@andyet.net> Date: Thu, 12 Feb 2015 16:05:13 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Pete Resnick References: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se> <54851FAD.4040009@andyet.net> <54D8EC54.8020203@qti.qualcomm.com> <54D8F98F.4050309@andyet.net> <54D910DC.1080003@andyet.net> <54D91BA8.6000705@qti.qualcomm.com> <54D93A77.9060102@andyet.net> <54DBCA9B.3050900@qti.qualcomm.com> <54DBF669.8080403@andyet.net> <54DC0422.8090201@qti.qualcomm.com> <54DC0520.6020601@andyet.net> <54DC0903.5080204@andyet.net> <54DCCBB2.1090601@qti.qualcomm.com> <54DD16D9.50804@andyet.net> <54DD1FB9.8040309@andyet.net> <54DD27A4.2080701@qti.qualcomm.com> In-Reply-To: <54DD27A4.2080701@qti.qualcomm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: precis@ietf.org Subject: Re: [precis] Directionality rule (Was: Review of current document draft-ietf-precis-framework-20) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 23:05:22 -0000 Thanks. Re-reading, I think "even though they are consistent" needs to be "even though the presentation is consistent"... On 2/12/15 3:22 PM, Pete Resnick wrote: > I don't think I could do any better than the below. Thanks. > > pr > > On 2/12/15 3:48 PM, Peter Saint-Andre - &yet wrote: >> ### >> >> 5.2.5. Directionality Rule >> >> The directionality rule of a profile specifies how to treat strings >> containing what are often called "right-to-left" (RTL) characters >> (see Unicode Standard Annex #9 [UAX9]). RTL characters come from >> scripts that are normally written from right to left and are >> considered by Unicode to, themselves, have right to left >> directionality. Strings containing RTL characters often also contain >> "left-to-right" (LTR) characters, such as numerals, as well as >> characters without directional properties. Consequently, such >> strings are known as "bidirectional strings". >> >> Presenting bidirectional strings in different layout systems (e.g., a >> user interface that is configured to handle primarily an RTL script >> vs. an interface that is configured to handle primarily an LTR >> script) can yield display results that, while predictable to those >> who understand the display rules, are counter-intuitive to casual >> users. In particular, the same bidirectional string (in PRECIS >> terms) might not be presented in the same way to users of those >> different layout systems, even though they are consistent within any >> particular layout system. In some applications, these presentation >> differences might be considered problematic and thus the application >> designers might wish to restrict the use of bidirectional strings by >> specifying a directionality rule. In other applications, these >> presentation differences might not be considered problematic (this >> especially tends to be true of more "free-form" strings) and thus no >> directionality rule is needed. >> >> The PRECIS framework does not directly address how to deal with >> bidirectional strings across all string classes and profiles, and >> does not define any new directionality rules, since at present there >> is no widely accepted and implemented solution for the safe display >> of arbitrary bidirectional strings beyond the Unicode bidirectional >> algorithm [UAX9]. Although rules for management and display of >> bidirectional strings have been defined for domain name labels and >> similar identifiers through the "Bidi Rule" specified in the IDNA2008 >> specification on right-to-left scripts [RFC5893], those rules are >> quite restrictive and are not necessarily applicable to all >> bidirectional strings. >> >> The authors of a PRECIS profile might believe that they need to >> define a new directionality rule of their own. Because of the >> complexity of the issues involved, such a belief is almost always >> misguided, even if the authors have done a great deal of careful >> research into the challenges of displaying bidirectional strings. >> This document strongly suggests that profile authors who are thinking >> about defining a new directionality rule think again, and instead >> consider using the "Bidi Rule" [RFC5893] (for profiles based on the >> IdentifierClass) or following the Unicode bidirectional algorithm >> [UAX9] directly (for profiles based on the FreeformClass or in >> situations where the IdentifierClass is not appropriate). >> >> ### >> > > -- Peter Saint-Andre https://andyet.com/ From nobody Thu Feb 12 16:10:40 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 606011A014C for ; Thu, 12 Feb 2015 16:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dhOn0nhGjVh for ; Thu, 12 Feb 2015 16:10:34 -0800 (PST) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5B8A1A00FF for ; Thu, 12 Feb 2015 16:10:34 -0800 (PST) Received: by mail-ig0-f173.google.com with SMTP id a13so7467763igq.0 for ; Thu, 12 Feb 2015 16:10:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=UUaxteD4sOuqEhaYHC6XdHZblCBg6+Y7QRMecBAR/7U=; b=V500WA6Tv/74Vo6KYNqDrf7zRJbRJC8cmv3mz9mVjPqyOLUq9jL8fQxKG9tkXDsIf9 Lo+OBGFItd5hMf0oPb/MKrIIuSQGmkTfKvtc+Lmw4v4AsBaQNU4jvYSS1eCJ7LyR0yD2 MUG19ur6G8TaOVl7UXM6A4jAUs7FL0O7n+pN3g2QTwMuTz/hIFV7Sr2hfEpmLVkH3iC2 wvTZuV6vh3IQVeRZpisRwt6txZMOs9QY4Mlvt4be5BRNwZCT/j5ypXAWKk81CuM+OUgp tEDmYK0OrTi2QKjxmPKFKyfBpz+juwtyQRHOsJlWbYw0Q3snMt1Su1k0W9LMt4CLkNUX vTlg== X-Gm-Message-State: ALoCoQk3gZwvFPAEUihsTZyvBuaolUOWXGzvMLEsHXgMM6PJqUPcrzfc/B9ilD0v6+PmY63o6qnj X-Received: by 10.107.28.129 with SMTP id c123mr8518803ioc.26.1423786234164; Thu, 12 Feb 2015 16:10:34 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id j77sm3410554ioj.30.2015.02.12.16.10.33 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Feb 2015 16:10:33 -0800 (PST) Message-ID: <54DD40F8.1080805@andyet.net> Date: Thu, 12 Feb 2015 17:10:32 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "precis@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [precis] directionality in precis-nickname X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 00:10:36 -0000 The discussion of directionality rules makes me realize that the precis-nickname document is wrong in using the Bidi Rule, and that it it would be best for the document to specify no directionality rule. Peter From nobody Mon Feb 16 07:18:47 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 770B71A88AE for ; Mon, 16 Feb 2015 07:18:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVtUuThEkfXt for ; Mon, 16 Feb 2015 07:18:38 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 29A921A88B2 for ; Mon, 16 Feb 2015 07:18:08 -0800 (PST) Received: from h194.viagenie.ca (h194.viagenie.ca [206.123.31.194]) by jazz.viagenie.ca (Postfix) with ESMTPSA id BD23146A66 for ; Mon, 16 Feb 2015 10:18:09 -0500 (EST) From: Marc Blanchet Content-Type: multipart/alternative; boundary="Apple-Mail=_C6DC390B-6F88-46E2-B759-11B855229F89" Message-Id: <60FC75DF-052C-4924-B3C3-A4F15EE96EFD@viagenie.ca> Date: Mon, 16 Feb 2015 10:18:05 -0500 To: precis@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [precis] lucid mailing list up X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 15:18:43 -0000 --Apple-Mail=_C6DC390B-6F88-46E2-B759-11B855229F89 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, the lucid mailing list is up. Here is the description: The IAB has published a statement about issues with the use of certain = types of Unicode code points in the IDNA protocol. The IAB expects the = IETF to investigate ways to=20 address this problem. This mailing list is the place to discuss this=20 issue.=20 https://www.ietf.org/mailman/listinfo/lucid = The intent is also to prepare the BOF scheduled for IETF Dallas. Regards, Marc.= --Apple-Mail=_C6DC390B-6F88-46E2-B759-11B855229F89 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello,
 the lucid mailing list is up. = Here is the description:
The IAB = has published a statement  about issues with the use of certain = types of Unicode code points in  the IDNA protocol. The IAB expects = the IETF to investigate ways to 
address this = problem. This mailing list is the place to discuss this 
issue. 

https://www.ietf.org/mailman/listinfo/lucid

The intent is also to = prepare the BOF scheduled for IETF Dallas.

Regards, Marc.
= --Apple-Mail=_C6DC390B-6F88-46E2-B759-11B855229F89-- From nobody Tue Feb 17 11:03:26 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505181A1A6F; Tue, 17 Feb 2015 11:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUSLXo23fLv8; Tue, 17 Feb 2015 11:03:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 806EA1A9079; Tue, 17 Feb 2015 11:03:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150217190318.13405.67917.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 11:03:18 -0800 Archived-At: Cc: precis-chairs@ietf.org, draft-ietf-precis-framework@ietf.org, precis@ietf.org Subject: [precis] Spencer Dawkins' No Objection on draft-ietf-precis-framework-22: (with COMMENT) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 19:03:24 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-precis-framework-22: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-precis-framework/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A nit: b. Comparing two output strings to determine if they equivalent, ^are typically through octet-for-octet matching to test for "bit- string identity" (e.g., to make an access decision for purposes of authentication or authorization as further described in [RFC6943]). From nobody Tue Feb 17 12:07:59 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D8E1A1B36 for ; Tue, 17 Feb 2015 12:07:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4-qa1w9Mtcz for ; Tue, 17 Feb 2015 12:07:56 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4016A1A6EF9 for ; Tue, 17 Feb 2015 12:07:53 -0800 (PST) Received: from h114.viagenie.ca (h114.viagenie.ca [206.123.31.114]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B4A6D40380 for ; Tue, 17 Feb 2015 15:07:54 -0500 (EST) From: Marc Blanchet Content-Type: multipart/alternative; boundary="Apple-Mail=_8F5196DF-1883-4062-965E-9C7DF50C74B1" Date: Tue, 17 Feb 2015 15:07:52 -0500 References: To: precis@ietf.org Message-Id: <088AC870-1A8F-4A9E-BDF6-40C86165AADC@viagenie.ca> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [precis] Fwd: WGLC on draft-ietf-precis-saslprepbis X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 20:07:58 -0000 --Apple-Mail=_8F5196DF-1883-4062-965E-9C7DF50C74B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 reminder: Ends Feb 20th. Marc. > D=C3=A9but du message r=C3=A9exp=C3=A9di=C3=A9 : >=20 > De: Marc Blanchet > Date: 6 f=C3=A9vrier 2015 12:32:31 UTC=E2=88=925 > =C3=80: precis@ietf.org > Objet: [precis] WGLC on draft-ietf-precis-saslprepbis >=20 > Hello, > this is a 2 weeks WGLC on draft-ietf-precis-saslprepbis, ending on = February 20th 2015, 23h59 UTC. Please send support, comments, = suggestions, modifications to the list and to the authors = (draft-ietf-precis-saslprepbis@tools.ietf.org). Those who read the = document and support it without modifications, please indicate so to the = mailing list. The assigned shepherd of the document is Matthew Miller. > Please note that xmpp-6122bis which depends on saslprepbis will be = co-WGLC with xmpp wg after the saslprepbis precis WGLC is done. >=20 > Marc, co-chair precis wg. > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis --Apple-Mail=_8F5196DF-1883-4062-965E-9C7DF50C74B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 reminder: Ends Feb 20th.

Marc.

D=C3=A9but= du message r=C3=A9exp=C3=A9di=C3=A9 :

De: = Marc Blanchet <marc.blanchet@viagenie.ca>
Date: = 6 f=C3=A9vrier 2015 12:32:31 = UTC=E2=88=925
=C3=80: = precis@ietf.org
Objet: = [precis] WGLC on = draft-ietf-precis-saslprepbis

Hello,
this is a 2 weeks WGLC = on draft-ietf-precis-saslprepbis, ending on February 20th 2015, 23h59 = UTC.  Please send support, comments, suggestions, modifications to = the list and to the authors (draft-ietf-precis-saslprepbis@tools.ietf.org). Those who = read the document and support it without modifications, please indicate = so to the mailing list. The assigned shepherd of the document is Matthew = Miller.
Please note that xmpp-6122bis which depends on = saslprepbis will be co-WGLC with xmpp wg after the saslprepbis precis = WGLC is done.

Marc, co-chair precis wg.
_______________________________________________
precis mailing list
precis@ietf.org
https://www.ietf.org/mailman/listinfo/precis

= --Apple-Mail=_8F5196DF-1883-4062-965E-9C7DF50C74B1-- From nobody Tue Feb 17 12:08:06 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB78B1A1F70 for ; Tue, 17 Feb 2015 12:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULB85_Y-VqEF for ; Tue, 17 Feb 2015 12:08:02 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5FC1A1B36 for ; Tue, 17 Feb 2015 12:08:02 -0800 (PST) Received: from h114.viagenie.ca (h114.viagenie.ca [206.123.31.114]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B0E3947576 for ; Tue, 17 Feb 2015 15:08:03 -0500 (EST) From: Marc Blanchet Content-Type: multipart/alternative; boundary="Apple-Mail=_1D1D7BAF-349E-467B-A3C0-E56EB4FDA27F" Date: Tue, 17 Feb 2015 15:08:01 -0500 References: <08E45702-32A3-44DA-B0A6-349C41CBDFF5@viagenie.ca> To: precis@ietf.org Message-Id: <109FE5BE-EA63-4BDA-AF77-2516646AA6BC@viagenie.ca> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [precis] Fwd: WGLC on draft-ietf-precis-nickname X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 20:08:06 -0000 --Apple-Mail=_1D1D7BAF-349E-467B-A3C0-E56EB4FDA27F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 reminder: Ends Feb 20th. Marc. > D=C3=A9but du message r=C3=A9exp=C3=A9di=C3=A9 : >=20 > De: Marc Blanchet > Date: 6 f=C3=A9vrier 2015 12:32:27 UTC=E2=88=925 > =C3=80: precis@ietf.org > Objet: [precis] WGLC on draft-ietf-precis-nickname >=20 > Hello, > this is a 2 weeks WGLC on draft-ietf-precis-nickname, ending on = February 20th 2015, 23h59 UTC. Please send support, comments, = suggestions, modifications to the list and to the authors = (draft-ietf-precis-nickname@tools.ietf.org). Those who read the document = and support it without modifications, please indicate so to the mailing = list. The assigned shepherd of the document is Joe Hildebrand. >=20 > Marc, co-chair precis wg. > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis --Apple-Mail=_1D1D7BAF-349E-467B-A3C0-E56EB4FDA27F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 reminder: Ends Feb 20th.

Marc.


D=C3=A9but du message = r=C3=A9exp=C3=A9di=C3=A9 :

De: = Marc Blanchet <marc.blanchet@viagenie.ca>
Date: = 6 f=C3=A9vrier 2015 12:32:27 = UTC=E2=88=925
=C3=80: = precis@ietf.org
Objet: = [precis] WGLC on = draft-ietf-precis-nickname

Hello,
this is a 2 weeks WGLC = on draft-ietf-precis-nickname, ending on February 20th 2015, 23h59 UTC. =  Please send support, comments, suggestions, modifications to the = list and to the authors (draft-ietf-precis-nickname@tools.ietf.org). Those who = read the document and support it without modifications, please indicate = so to the mailing list. The assigned shepherd of the document is Joe = Hildebrand.

Marc, co-chair precis wg.
_______________________________________________
precis mailing list
precis@ietf.org
https://www.ietf.org/mailman/listinfo/precis

= --Apple-Mail=_1D1D7BAF-349E-467B-A3C0-E56EB4FDA27F-- From nobody Thu Feb 19 00:09:37 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176851A88E6; Thu, 19 Feb 2015 00:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeX2cnPRSOAt; Thu, 19 Feb 2015 00:09:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C23D11A88D2; Thu, 19 Feb 2015 00:09:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219080933.27783.26980.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 00:09:33 -0800 Archived-At: Cc: iesg-secretary@ietf.org Subject: [precis] Last Call Expired: X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 08:09:35 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-precis-framework/ IETF Last Call has ended, and the state has been changed to Waiting for AD Go-Ahead. From nobody Thu Feb 19 07:56:04 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F421A9121; Thu, 19 Feb 2015 07:56:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlVIY3b0WOui; Thu, 19 Feb 2015 07:55:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1D11A913A; Thu, 19 Feb 2015 07:55:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219155535.30626.95546.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 07:55:35 -0800 Archived-At: Cc: precis-chairs@ietf.org, draft-ietf-precis-framework@ietf.org, precis@ietf.org Subject: [precis] Stephen Farrell's No Objection on draft-ietf-precis-framework-22: (with COMMENT) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 15:56:01 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-precis-framework-22: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-precis-framework/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Last time this came around I had the comments below. While Barry no longer has a DISCUSS, I'd still be interested in chatting a bit about these. (Apologies that I've not had time to re-read the draft though, so feel free to just tell me these comments are OBE if that's the case.) " - I agree with Bary's discuss - it seems weird to not have the initial registries in hand when the RFC is being issued. People will, I guess, implement from Appendix A here anyway, so why not either delete this and get the registry in place, or else make Appendix A be the initial registry content. 7.7: This uses the empty set, which is puzzling. I think you mean that this set is to be populated by the DE in the IANA registries but if so, saying so would be good. 10.5: This says that a) its all too hard but also b) "Nevertheless, specifications for application protocols that use this framework MUST describe how confusable characters can be abused to compromise the security of systems that use the protocol in question, along with any protocol-specific suggestions for overcoming those threats." That seems like a 6919 MUST (but we know you won't) to me. Is that a good plan? 10.6: Prompted by the secdir review, it might be worth a few words on password hashing, which is very common. E.g. say that the canonical form is input to hashing and therefore just can't be mucked about with. (But say that nicely:-) " From nobody Thu Feb 19 08:24:04 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 312FD1A9110; Thu, 19 Feb 2015 08:24:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbQP7pBzo1rg; Thu, 19 Feb 2015 08:24:00 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 405461ABD35; Thu, 19 Feb 2015 08:23:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1424363018; x=1455899018; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=T1fKcCWD4HdD+pARTrYiOatPhqmMvqX23SaMdbdZGiY=; b=oNAxrnmz9rwjpkeHJOuQwiqOmhLC3OYxm/7ZsryEh1jMpzD9wccxI8Fz dePuemI0GX2pTTCwNQCNMRLlkKH8r8aDTLqibbo4HqTk/TqTpR5uULsek /sPCVdRiG5OFmoFzFzSpZh8uqSO2LieAg5xKgD1fgFMvnH7TRwDhFvAkJ g=; X-IronPort-AV: E=McAfee;i="5600,1067,7716"; a="84326068" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth02.qualcomm.com with ESMTP; 19 Feb 2015 08:23:37 -0800 X-IronPort-AV: E=Sophos;i="5.09,609,1418112000"; d="scan'208";a="32421211" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 19 Feb 2015 08:23:37 -0800 Received: from presnick-mac.local (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 19 Feb 2015 08:23:36 -0800 Message-ID: <54E60E07.8010408@qti.qualcomm.com> Date: Thu, 19 Feb 2015 10:23:35 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Stephen Farrell References: <20150219155535.30626.95546.idtracker@ietfa.amsl.com> In-Reply-To: <20150219155535.30626.95546.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01G.na.qualcomm.com (10.85.0.33) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Cc: precis-chairs@ietf.org, draft-ietf-precis-framework@ietf.org, The IESG , precis@ietf.org Subject: Re: [precis] Stephen Farrell's No Objection on draft-ietf-precis-framework-22: (with COMMENT) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 16:24:02 -0000 On 2/19/15 9:55 AM, Stephen Farrell wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > Last time this came around I had the comments below. > While Barry no longer has a DISCUSS, I'd still be > interested in chatting a bit about these. (Apologies > that I've not had time to re-read the draft though, so > feel free to just tell me these comments are OBE if > that's the case.) > > " > - I agree with Bary's discuss - it seems weird to not > have the initial registries in hand when the RFC is > being issued. People will, I guess, implement from > Appendix A here anyway, so why not either delete this > and get the registry in place, or else make Appendix A > be the initial registry content. > OBE. We changed the whole way this was done. > 7.7: This uses the empty set, which is puzzling. I think > you mean that this set is to be populated by the DE in > the IANA registries but if so, saying so would be good. > OBE. Section changed to make this clear. > 10.5: This says that a) its all too hard but also b) > "Nevertheless, specifications for application protocols > that use this framework MUST describe how confusable > characters can be abused to compromise the security of > systems that use the protocol in question, along with any > protocol-specific suggestions for overcoming those > threats." That seems like a 6919 MUST (but we know you > won't) to me. Is that a good plan? > Changed "MUST" to "are strongly encouraged to" > 10.6: Prompted by the secdir review, it might be worth a > few words on password hashing, which is very common. E.g. > say that the canonical form is input to hashing and > therefore just can't be mucked about with. (But say that > nicely:-) > Added: In protocols that provide passwords as input to a cryptographic algorithm such as a hash function, the client will need to perform proper preparation of the password before applying the algorithm, since the password is not available to the server in plaintext form. I hope that addresses everything. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Thu Feb 19 10:45:00 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F07B1A079D; Thu, 19 Feb 2015 10:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPuvuxxyp-5S; Thu, 19 Feb 2015 10:44:58 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0EB51A0158; Thu, 19 Feb 2015 10:44:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8F403BEEB; Thu, 19 Feb 2015 18:44:56 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vhmc2FGp2HJP; Thu, 19 Feb 2015 18:44:55 +0000 (GMT) Received: from [172.16.20.132] (unknown [216.127.117.38]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 92F1BBED3; Thu, 19 Feb 2015 18:44:53 +0000 (GMT) Message-ID: <54E62F24.3020503@cs.tcd.ie> Date: Thu, 19 Feb 2015 18:44:52 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Pete Resnick References: <20150219155535.30626.95546.idtracker@ietfa.amsl.com> <54E60E07.8010408@qti.qualcomm.com> In-Reply-To: <54E60E07.8010408@qti.qualcomm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: precis-chairs@ietf.org, draft-ietf-precis-framework@ietf.org, The IESG , precis@ietf.org Subject: Re: [precis] Stephen Farrell's No Objection on draft-ietf-precis-framework-22: (with COMMENT) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 18:44:59 -0000 All good thanks, S. On 19/02/15 16:23, Pete Resnick wrote: > On 2/19/15 9:55 AM, Stephen Farrell wrote: >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> Last time this came around I had the comments below. >> While Barry no longer has a DISCUSS, I'd still be >> interested in chatting a bit about these. (Apologies >> that I've not had time to re-read the draft though, so >> feel free to just tell me these comments are OBE if >> that's the case.) >> >> " >> - I agree with Bary's discuss - it seems weird to not >> have the initial registries in hand when the RFC is >> being issued. People will, I guess, implement from >> Appendix A here anyway, so why not either delete this >> and get the registry in place, or else make Appendix A >> be the initial registry content. >> > > OBE. We changed the whole way this was done. > >> 7.7: This uses the empty set, which is puzzling. I think >> you mean that this set is to be populated by the DE in >> the IANA registries but if so, saying so would be good. >> > > OBE. Section changed to make this clear. > >> 10.5: This says that a) its all too hard but also b) >> "Nevertheless, specifications for application protocols >> that use this framework MUST describe how confusable >> characters can be abused to compromise the security of >> systems that use the protocol in question, along with any >> protocol-specific suggestions for overcoming those >> threats." That seems like a 6919 MUST (but we know you >> won't) to me. Is that a good plan? >> > > Changed "MUST" to "are strongly encouraged to" > >> 10.6: Prompted by the secdir review, it might be worth a >> few words on password hashing, which is very common. E.g. >> say that the canonical form is input to hashing and >> therefore just can't be mucked about with. (But say that >> nicely:-) >> > > Added: > > In protocols that provide passwords as input to a cryptographic > algorithm such as a hash function, the client will need to perform > proper preparation of the password before applying the algorithm, > since the password is not available to the server in plaintext form. > > I hope that addresses everything. > > pr > From nobody Thu Feb 19 17:02:25 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE0A1A1AF9; Thu, 19 Feb 2015 17:02:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQp1tz65jc-6; Thu, 19 Feb 2015 17:02:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B55AD1A1B03; Thu, 19 Feb 2015 17:02:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150220010215.29182.99881.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 17:02:15 -0800 Archived-At: Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-framework-23.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 01:02:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Preparation and Comparison of Internationalized Strings Working Group of the IETF. Title : PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols Authors : Peter Saint-Andre Marc Blanchet Filename : draft-ietf-precis-framework-23.txt Pages : 39 Date : 2015-02-19 Abstract: Application protocols using Unicode characters in protocol strings need to properly handle such strings in order to enforce internationalization rules for strings placed in various protocol slots (such as addresses and identifiers) and to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation, enforcement, and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode characters and thus is agile with respect to versions of Unicode. As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454). This document obsoletes RFC 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-23 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-framework-23 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 19 17:02:33 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 892C91A1AF9; Thu, 19 Feb 2015 17:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StDGmgRVqIvu; Thu, 19 Feb 2015 17:02:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C775F1A1B05; Thu, 19 Feb 2015 17:02:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150220010215.29182.52313.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 17:02:15 -0800 Archived-At: Subject: [precis] New Version Notification - draft-ietf-precis-framework-23.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 01:02:24 -0000 A new version (-23) has been submitted for draft-ietf-precis-framework: http://www.ietf.org/internet-drafts/draft-ietf-precis-framework-23.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-framework/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-framework-23 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. IETF Secretariat. From nobody Thu Feb 19 17:56:42 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B331A1B23 for ; Thu, 19 Feb 2015 17:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34GjQOnpty97 for ; Thu, 19 Feb 2015 17:56:38 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FE471A1B1E for ; Thu, 19 Feb 2015 17:56:38 -0800 (PST) Received: from netb ([89.204.130.64]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lg6op-1XmqRX3mCh-00pcuJ for ; Fri, 20 Feb 2015 02:56:36 +0100 From: Bjoern Hoehrmann To: precis@ietf.org Date: Fri, 20 Feb 2015 02:56:35 +0100 Message-ID: <932dealvpln2o93rjru14adhk6lqp63184@hive.bjoern.hoehrmann.de> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:vWX6QzUl+ImKYERrYK0gbg3u/fNSSeo6//y4xGhbCnocio3BM6U DJdU/FXQ5ZlT0ynkIJCrmt4VD3slb27i2cHgOUWFcRk7nr/AtULWdeKjlPKdPZx7Clj/gN8 6+Kyn7zFyyMYErZ3mDfU9OR0ZsXv7Jm3WpjIE2kF1Xgp42Pw2rsenO6kMUasXNhEEOu40qd BTfbPAC8QHwP0CQKcov7w== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [precis] PRECIS breadcrumbs X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 01:56:41 -0000 Hi, Yesterday I tried to find out if the latest draft for HTTP Basic auth- entication allows colons in passwords. I eventually gave up; what I did: http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-06 has For the password, recipients MUST support all characters defined in the "OpaqueString" profile defined in in Section 4.2 of [PRECIS]. Went to http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-13 and when I searched for `OpaqueString` in the document the first hit beyond the ToC is: 4. Passwords 4.1. Definition This document specifies that a password is a string of Unicode code points [UNICODE], encoded using UTF-8 [RFC3629], and conformant to OpaqueString profile of the PRECIS FreeformClass specified below. This left me confused why `basicauth` references `OpaqueString` instead of "a password as defined in [PRECIS]" or something like that. Anyway... Since `OpaqueString` is said to be "specified below", I continued the search and the next hit is 4.2. OpaqueString Profile The definition of the OpaqueString profile is provided in the following sections, including detailed information about preparation, enforcement, and comparison (on the distinction between these actions, refer to [I-D.ietf-precis-framework]). 4.2.1. Preparation An entity that prepares a string according to this profile MUST ensure that the string consists only of Unicode code points that conform to the "FreeformClass" base string class defined in [I-D.ietf-precis-framework]. In addition, the string MUST be encoded as UTF-8 [RFC3629]. Since `basicauth` allows other character encodings than UTF-8, I have found the MUST requirement here somewhat irritating, but I assume that is resolved somewhere. In any case, I skipped the rather complicated rules that follow the quoted text above, since the definition of the `FreeformClass` is needed before I could apply the additional steps to find out if colons are allowed in `basicauth` passwords. The definition is in another document, so I went to http://tools.ietf.org/html/draft-ietf-precis-framework-21 and the first relevant hit there is FreeformClass: a sequence of letters, numbers, symbols, spaces, and other characters that is used for free-form strings, including passwords as well as display elements such as human-friendly nicknames for devices or for participants in a chatroom; the intent is that this class will allow nearly any Unicode character, with the result that expressiveness has been prioritized over safety for this class. Note well that protocol designers, application developers, service providers, and end users might not understand or be able to enter all of the characters that can be included in the FreeformClass - see Section 12.3 for details. I clicked the link to Section 12.3 but that turned out to be wrong. So instead I kept searching the document for `FreeformClass` and ended up in section 4.3 which has several pages of rules that define the class, most of which refer to other sections of the document, which in turn re- ference, among other things, various properties in the Unicode database, such as the general category of characters. The takeaway was that I would have to spend an afternoon or likely more time implementing all the rules before I could answer my rather simple question. Retracing my steps just now it might have been possible to see `ASCII7` listed as `valid` but I can't really be sure if `Disallowed` rules in 4.3.3. might override that, and in any case, I would have to go through the definition of `OpaqueString` to see whether the colon might be disallowed there even if `FreeformClass` allows it. The conclusion was that I would need a tool to tell if `OpaqueString` allows colons. I also wondered whether it would make sense to list at least the ASCII-range characters explicitly for the relevant class de- finitions (and shudder to think that they might change due to changes in Unicode); I am also not sure whether classes like `OpaqueString` correspond to repeated classes like [a-z]* or have more complicated restrictions (like U+1234 can occur in `OpaqueString` but not after U+ABCD). FWIW, -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/ From nobody Fri Feb 20 18:55:24 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7111A1A31; Fri, 20 Feb 2015 18:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoWsDbYYzcmX; Fri, 20 Feb 2015 18:55:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 002A51A1A34; Fri, 20 Feb 2015 18:55:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150221025516.4369.81176.idtracker@ietfa.amsl.com> Date: Fri, 20 Feb 2015 18:55:16 -0800 Archived-At: Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-nickname-15.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 02:55:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Preparation and Comparison of Internationalized Strings Working Group of the IETF. Title : Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames Author : Peter Saint-Andre Filename : draft-ietf-precis-nickname-15.txt Pages : 9 Date : 2015-02-20 Abstract: This document describes methods for handling Unicode strings representing nicknames. 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-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-nickname-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 20 18:57:01 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6CE1A1A33 for ; Fri, 20 Feb 2015 18:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f36iPyEXxImP for ; Fri, 20 Feb 2015 18:56:59 -0800 (PST) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F9031A1A31 for ; Fri, 20 Feb 2015 18:56:59 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id h15so7477519igd.4 for ; Fri, 20 Feb 2015 18:56:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=rE0VREnbCpURyBE7iU9rekOyLai3jb1wDq6gSt5/8OE=; b=B69eCOCl2paKTllsDmFesmSMLw8BoChujFxtbn/gEfjT3B9vQK6YekJ/Ijzsl5Nk39 eoHZ/O2qDmahzY5oU0tVK2eroCoS0Y4L9nZtoQuyzvYYb/kZRHZG2ombWLfmyJr0olZA rxkyEBj5JfvkLmaM2/mWSmoKcGH/VOF5ISz1wdQf06dcqfV7gFTaw/bHEAxyLH92P84t smWUMjJdHgBg91plC+BTvseNInj7iIhrf3sb/3B4a/g9cJWmjFGI4+gWXyIvfb1KyU+k OBbwaNwHF0in/T7SQOs0BSBcBHZsh2++V3fL4bOkUMUONUGgzznvNBRUsYsx268rH6sx Vl1w== X-Gm-Message-State: ALoCoQknN8OpBRQS3x9LpZBHKkBDWYnE64D83ODEzy8NyWz8f3f+hrwBZ1KM+WIlfy3g3AUFoXJr X-Received: by 10.107.9.213 with SMTP id 82mr1361461ioj.56.1424487418564; Fri, 20 Feb 2015 18:56:58 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id j128sm6863534ioe.26.2015.02.20.18.56.57 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Feb 2015 18:56:57 -0800 (PST) Message-ID: <54E7F3F8.2070309@andyet.net> Date: Fri, 20 Feb 2015 19:56:56 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: precis@ietf.org References: <20150221025516.4369.81176.idtracker@ietfa.amsl.com> In-Reply-To: <20150221025516.4369.81176.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [precis] I-D Action: draft-ietf-precis-nickname-15.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 02:57:01 -0000 As previously noted, corrected the directionality rule to be consistent with the framework. On 2/20/15 7:55 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Preparation and Comparison of Internationalized Strings Working Group of the IETF. > > Title : Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames > Author : Peter Saint-Andre > Filename : draft-ietf-precis-nickname-15.txt > Pages : 9 > Date : 2015-02-20 > > Abstract: > This document describes methods for handling Unicode strings > representing nicknames. > > > 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-15 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-nickname-15 > > > 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/ > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis > From nobody Mon Feb 23 11:15:29 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652BA1A6EDB; Mon, 23 Feb 2015 11:15:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZErjmASXAs3; Mon, 23 Feb 2015 11:15:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 293A01A6F20; Mon, 23 Feb 2015 11:15:07 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150223191507.25607.69068.idtracker@ietfa.amsl.com> Date: Mon, 23 Feb 2015 11:15:07 -0800 Archived-At: Cc: precis chair , precis mailing list , RFC Editor Subject: [precis] Protocol Action: 'PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols' to Proposed Standard (draft-ietf-precis-framework-23.txt) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 19:15:27 -0000 The IESG has approved the following document: - 'PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols' (draft-ietf-precis-framework-23.txt) as Proposed Standard This document is the product of the Preparation and Comparison of Internationalized Strings Working Group. The IESG contact persons are Pete Resnick and Barry Leiba. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-precis-framework/ Technical Summary Application protocols using Unicode characters 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 ("PRECIS") in a way that depends on the properties of Unicode characters and thus is agile with respect to versions of Unicode. Working Group Summary The WG spent some time deciding how many classes need to be defined and what kind of class is suitable for "profiling" for different purposes. In particular the discussion of use of spaces in Identifier class took a bit of time. But the WG converged at the end. This document went through two IETF Last Calls and two IESG Evaluations. At the end of the first Last Call, concerns were raised regarding how the term "profiles" was being used in the context of this document. Additionally, a good deal of the text was copied in from IDNA instead of importing definitions. The IESG also had concerns about how the IANA registry was to be created. The document was updated to address these issues. Additionally, the WG changed the discussion Directionality to address review comments received during the second Last Call. Finally, the IAB produced a statement regarding the issues discovered with the publication of Unicode version 7 (though the issue dates back well before that) that changed assumptions made during the development of IDNA. Because this document is based on IDNA, the same issues apply to this document. The WG addressed this in section 13.4 of the document. The IESG reviewed this section and, fully understanding that this might constitute a technical omission in the document, concluded that the explanation given in this section is sufficient and that the document was still worth publishing. Document Quality The approach used by the document is similar to IDNA 2008 approach (use of Unicode character properties for deciding what to do with characters) and thus wasn't controversial (save the discussion noted above regarding section 13.4). Several protocols intend to use the framework described in this document, and people from different working groups have been contributing to this work, including folks involved in iSCSI and RADIUS. Personnel The document shepherd is Alexey Melnikov. The responsible Area Director is Pete Resnick. From nobody Mon Feb 23 11:25:41 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F407A1A6ED9 for ; Mon, 23 Feb 2015 11:25:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nn33GE0-lcLu for ; Mon, 23 Feb 2015 11:25:37 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 53A561A3BA6 for ; Mon, 23 Feb 2015 11:25:37 -0800 (PST) Received: from kuwa.viagenie.ca (kuwa.viagenie.ca [206.123.31.98]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D851640D17 for ; Mon, 23 Feb 2015 14:25:38 -0500 (EST) From: Marc Blanchet Content-Type: multipart/alternative; boundary="Apple-Mail=_972D0C60-D63F-4C29-971D-84F5BE19742A" Date: Mon, 23 Feb 2015 14:25:36 -0500 References: <20150223191507.25607.69068.idtracker@ietfa.amsl.com> To: precis@ietf.org Message-Id: <21CBF387-7DA6-49A7-9B98-1A46C6E7789A@viagenie.ca> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [precis] Fwd: Protocol Action: 'PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols' to Proposed Standard (draft-ietf-precis-framework-23.txt) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 19:25:40 -0000 --Apple-Mail=_972D0C60-D63F-4C29-971D-84F5BE19742A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 congratulations to the whole working group for this multi-year work and = a special thanks to Peter. Regards, Marc. > D=C3=A9but du message r=C3=A9exp=C3=A9di=C3=A9 : >=20 > De: The IESG > =C3=80: "IETF-Announce" > Objet: Protocol Action: 'PRECIS Framework: Preparation, Enforcement, = and Comparison of Internationalized Strings in Application Protocols' to = Proposed Standard (draft-ietf-precis-framework-23.txt) > Date: 23 f=C3=A9vrier 2015 14:15:07 UTC=E2=88=925 > Cc: precis chair , precis mailing list = , RFC Editor > R=C3=A9pondre =C3=A0: ietf@ietf.org >=20 > The IESG has approved the following document: > - 'PRECIS Framework: Preparation, Enforcement, and Comparison of > Internationalized Strings in Application Protocols' > (draft-ietf-precis-framework-23.txt) as Proposed Standard >=20 > This document is the product of the Preparation and Comparison of > Internationalized Strings Working Group. >=20 > The IESG contact persons are Pete Resnick and Barry Leiba. >=20 > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-precis-framework/ >=20 >=20 >=20 >=20 > Technical Summary >=20 > Application protocols using Unicode characters 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 ("PRECIS") in a way that depends on the > properties of Unicode characters and thus is agile with respect to > versions of Unicode. >=20 > Working Group Summary >=20 > The WG spent some time deciding how many classes need to be defined > and what kind of class is suitable for "profiling" for different > purposes. In particular the discussion of use of spaces in = Identifier > class took a bit of time. But the WG converged at the end. >=20 > This document went through two IETF Last Calls and two IESG > Evaluations. At the end of the first Last Call, concerns were raised > regarding how the term "profiles" was being used in the context of > this document. Additionally, a good deal of the text was copied in > from IDNA instead of importing definitions. The IESG also had > concerns about how the IANA registry was to be created. The document > was updated to address these issues. Additionally, the WG changed = the > discussion Directionality to address review comments received during > the second Last Call. Finally, the IAB produced a statement = regarding > the issues discovered with the publication of Unicode version 7 > (though the issue dates back well before that) that changed > assumptions made during the development of IDNA. Because this > document is based on IDNA, the same issues apply to this document. > The WG addressed this in section 13.4 of the document. The IESG > reviewed this section and, fully understanding that this might > constitute a technical omission in the document, concluded that the > explanation given in this section is sufficient and that the = document > was still worth publishing. >=20 > Document Quality >=20 > The approach used by the document is similar to IDNA 2008 approach > (use of Unicode character properties for deciding what to do with > characters) and thus wasn't controversial (save the discussion noted > above regarding section 13.4). >=20 > Several protocols intend to use the framework described in this > document, and people from different working groups have been > contributing to this work, including folks involved in iSCSI and > RADIUS. >=20 >=20 > Personnel >=20 > The document shepherd is Alexey Melnikov. > The responsible Area Director is Pete Resnick. --Apple-Mail=_972D0C60-D63F-4C29-971D-84F5BE19742A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 congratulations to the whole working group for this = multi-year work and a special thanks to Peter.

Regards, Marc.

D=C3=A9but= du message r=C3=A9exp=C3=A9di=C3=A9 :

De: = The IESG <iesg-secretary@ietf.org>
=C3=80: = "IETF-Announce" <ietf-announce@ietf.org>
Objet: = Protocol Action: = 'PRECIS Framework: Preparation, Enforcement, and Comparison of = Internationalized Strings in Application Protocols' to Proposed Standard = (draft-ietf-precis-framework-23.txt)
Date: = 23 f=C3=A9vrier 2015 14:15:07 = UTC=E2=88=925
Cc: = precis chair <precis-chairs@tools.ietf.org>, precis mailing list = <precis@ietf.org>,= RFC Editor <rfc-editor@rfc-editor.org>
R=C3=A9pon= dre =C3=A0: ietf@ietf.org

The IESG has = approved the following document:
- 'PRECIS Framework: = Preparation, Enforcement, and Comparison of
=   Internationalized Strings in Application Protocols'
 (draft-ietf-precis-framework-23.txt) as Proposed = Standard

This document is the product of = the Preparation and Comparison of
Internationalized = Strings Working Group.

The IESG contact = persons are Pete Resnick and Barry Leiba.

A = URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-precis-framework/




Technical Summary

=   Application protocols using Unicode characters 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 ("PRECIS") in a way that depends = on the
  properties of Unicode characters and = thus is agile with respect to
  versions of = Unicode.

Working Group Summary

  The WG spent some time deciding = how many classes need to be defined
  and what = kind of class is suitable for "profiling" for different
=   purposes. In particular the discussion of use of spaces in = Identifier
  class took a bit of time. But the = WG converged at the end.

  This = document went through two IETF Last Calls and two IESG
=   Evaluations. At the end of the first Last Call, concerns = were raised
  regarding how the term "profiles" = was being used in the context of
  this = document. Additionally, a good deal of the text was copied in
  from IDNA instead of importing definitions. The = IESG also had
  concerns about how the IANA = registry was to be created. The document
  was = updated to address these issues. Additionally, the WG changed the
  discussion Directionality to address review = comments received during
  the second Last = Call. Finally, the IAB produced a statement regarding
=   the issues discovered with the publication of Unicode = version 7
  (though the issue dates back well = before that) that changed
  assumptions made = during the development of IDNA. Because this
=   document is based on IDNA, the same issues apply to this = document.
  The WG addressed this in section = 13.4 of the document. The IESG
  reviewed this = section and, fully understanding that this might
=   constitute a technical omission in the document, concluded = that the
  explanation given in this section is = sufficient and that the document
  was still = worth publishing.

Document Quality

  The approach used by the document = is similar to IDNA 2008 approach
  (use of = Unicode character properties for deciding what to do with
=   characters) and thus wasn't controversial (save the = discussion noted
  above regarding section = 13.4).

  Several protocols = intend to use the framework described in this
=   document, and people from different working groups have = been
  contributing to this work, including = folks involved in iSCSI and
  RADIUS.


Personnel

  The document shepherd is Alexey Melnikov.
  The responsible Area Director is Pete = Resnick.

= --Apple-Mail=_972D0C60-D63F-4C29-971D-84F5BE19742A-- From nobody Mon Feb 23 15:26:49 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD5081A1A92 for ; Mon, 23 Feb 2015 15:26:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzZ0FkPPF9pE for ; Mon, 23 Feb 2015 15:26:47 -0800 (PST) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4C651A1A62 for ; Mon, 23 Feb 2015 15:26:46 -0800 (PST) Received: by iecrd18 with SMTP id rd18so27692043iec.8 for ; Mon, 23 Feb 2015 15:26:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=iGetChve6hNgGYffLNme4HGqiZgKvXmPf+uwhFDFfnw=; b=Z3TxPM5tC4Lv13+MG0HLohzYP2OTOMwNmwnalDvB3P3NRvLsQp9YPLNjMskq+ZPTIJ ZE6r3NR5fBrGVF2KRfYmFs4/EFiwXxHNhMgsguePmw6DLjm2tQ0tjQHXp6zrdGex1i18 UT3QQdljdvhYDqbuab/UGQa0hEFwhZv+JAhZnzsHBHO7gOOTKq5/gXbQQHeukGjjHoUt F1OxE0V1C+h6iyyfrRO8RQWjE7sz653vydLf8i4DsJPQAk7uQpsxAZffiPOouwqeSlgz uu59XyukQVB1caoiaeN190nApf0aC9MFadQkvYuTSNDebdCDg3t84A7GzGksH2B8vSJu Q13w== X-Gm-Message-State: ALoCoQmkyJ4QBwuT47iW5TuRpxy5jYHXUrZKl6YssEXxSgWV95Xv6l+9+EXabD7Rz4ZzrL8O7EFE X-Received: by 10.107.33.11 with SMTP id h11mr16975953ioh.53.1424734006207; Mon, 23 Feb 2015 15:26:46 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id gz4sm6989360igb.19.2015.02.23.15.26.45 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Feb 2015 15:26:45 -0800 (PST) Message-ID: <54EBB733.5070508@andyet.net> Date: Mon, 23 Feb 2015 16:26:43 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Marc Blanchet , precis@ietf.org References: <20150223191507.25607.69068.idtracker@ietfa.amsl.com> <21CBF387-7DA6-49A7-9B98-1A46C6E7789A@viagenie.ca> In-Reply-To: <21CBF387-7DA6-49A7-9B98-1A46C6E7789A@viagenie.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [precis] Fwd: Protocol Action: 'PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols' to Proposed Standard (draft-ietf-precis-framework-23.txt) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 23:26:49 -0000 Given all the folks who've contributed since the NewPrep BoF five years ago, I'd say this was a true team effort! :-) On 2/23/15 12:25 PM, Marc Blanchet wrote: > congratulations to the whole working group for this multi-year work and > a special thanks to Peter. > > Regards, Marc. > >> Début du message réexpédié : >> >> *De: *The IESG > >> *À: *"IETF-Announce" > > >> *Objet: **Protocol Action: 'PRECIS Framework: Preparation, >> Enforcement, and Comparison of Internationalized Strings in >> Application Protocols' to Proposed Standard >> (draft-ietf-precis-framework-23.txt)* >> *Date: *23 février 2015 14:15:07 UTC−5 >> *Cc: *precis chair > >, precis mailing list >> >, RFC Editor >> > >> *Répondre à: *ietf@ietf.org >> >> The IESG has approved the following document: >> - 'PRECIS Framework: Preparation, Enforcement, and Comparison of >> Internationalized Strings in Application Protocols' >> (draft-ietf-precis-framework-23.txt) as Proposed Standard >> >> This document is the product of the Preparation and Comparison of >> Internationalized Strings Working Group. >> >> The IESG contact persons are Pete Resnick and Barry Leiba. >> >> A URL of this Internet Draft is: >> http://datatracker.ietf.org/doc/draft-ietf-precis-framework/ >> >> >> >> >> Technical Summary >> >> Application protocols using Unicode characters 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 ("PRECIS") in a way that depends on the >> properties of Unicode characters and thus is agile with respect to >> versions of Unicode. >> >> Working Group Summary >> >> The WG spent some time deciding how many classes need to be defined >> and what kind of class is suitable for "profiling" for different >> purposes. In particular the discussion of use of spaces in Identifier >> class took a bit of time. But the WG converged at the end. >> >> This document went through two IETF Last Calls and two IESG >> Evaluations. At the end of the first Last Call, concerns were raised >> regarding how the term "profiles" was being used in the context of >> this document. Additionally, a good deal of the text was copied in >> from IDNA instead of importing definitions. The IESG also had >> concerns about how the IANA registry was to be created. The document >> was updated to address these issues. Additionally, the WG changed the >> discussion Directionality to address review comments received during >> the second Last Call. Finally, the IAB produced a statement regarding >> the issues discovered with the publication of Unicode version 7 >> (though the issue dates back well before that) that changed >> assumptions made during the development of IDNA. Because this >> document is based on IDNA, the same issues apply to this document. >> The WG addressed this in section 13.4 of the document. The IESG >> reviewed this section and, fully understanding that this might >> constitute a technical omission in the document, concluded that the >> explanation given in this section is sufficient and that the document >> was still worth publishing. >> >> Document Quality >> >> The approach used by the document is similar to IDNA 2008 approach >> (use of Unicode character properties for deciding what to do with >> characters) and thus wasn't controversial (save the discussion noted >> above regarding section 13.4). >> >> Several protocols intend to use the framework described in this >> document, and people from different working groups have been >> contributing to this work, including folks involved in iSCSI and >> RADIUS. >> >> >> Personnel >> >> The document shepherd is Alexey Melnikov. >> The responsible Area Director is Pete Resnick. From nobody Wed Feb 25 13:50:57 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393571A88F2 for ; Wed, 25 Feb 2015 13:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fniZf31iu2wP for ; Wed, 25 Feb 2015 13:50:55 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 379DC1A88F9 for ; Wed, 25 Feb 2015 13:50:55 -0800 (PST) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t1PLofaJ015673 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Feb 2015 15:50:52 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] From: "Ben Campbell" To: precis@ietf.org Date: Wed, 25 Feb 2015 15:50:41 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9r5066) Archived-At: Cc: Peter Saint-Andre - &yet Subject: [precis] Belated WGLC comments on draft-ietf-precis-saslprepbis-13 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 21:50:56 -0000 Hi, I apologize for the lateness of this. If my comments are a moot by now, please feel free to ignore them. I support publication of this, and think this version is pretty much ready to go. I have a few editorial comments that might be worth considering if there is an update. - Abstract: It would be nice if the abstract mentioned something about moving from stringprep to the precis-framework. - 3.4, third bullet: "… protocols that do not use SASL …" should this paragraph include "and follow the recommendations in this document" or "and that reuse this profile"? clause — 6 The text refers to the 4013 as SASLPrep. But this draft is _also_ SASLPrep, isn't it? At least, it has SASLPrepbis in the short title. (Or does the term saslprep get dropped entirely when the draft becomes an RFC?) From nobody Wed Feb 25 14:39:38 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A2A1A1A99 for ; Wed, 25 Feb 2015 14:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHeDheA_7eH6 for ; Wed, 25 Feb 2015 14:39:35 -0800 (PST) Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com [209.85.213.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B56E21A8931 for ; Wed, 25 Feb 2015 14:39:35 -0800 (PST) Received: by mail-ig0-f177.google.com with SMTP id z20so9958131igj.4 for ; Wed, 25 Feb 2015 14:39:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qWlbcl9F4Kl7jD+fT2Q94gsOkDRlf9xeEAD6OwZexRw=; b=ik3bGsUJ1KZhHlLSFXbCyIvO5qlIt12t4HAfDrp2UDzwQuHU1EL1Z9a4LUpTe+4aeP GSti01FU5Sff3LMtdJZwjqtFE1EjBUHoct7K1/mPLT8WVRtDAz550rw3ZhSUhdPilMP9 x4s/g9N1aPY0/D0nfBghiNVoei63qI/TJt6p0eWfE/CnY9AaaygNA3y0A2OYnYm8l5NN p3CE/7ucV3JqDKJXYuNaztJNEwWtyAqGLPo31FCX3mIasCYaawZZjUgEQvmNuo0rm5D2 0RW7wE9W7fqmptOJHwybnXI+cRZ18HkTXYenIzOJVkzYTsDM5ttTCN1i2UfbhlfgA47r utlQ== X-Gm-Message-State: ALoCoQnFd+md7jc7xFfv+PuUyJg2bM1gMaQ0ODytxriUdGAVXzAH7Rmc8R+n9byzfU+5Cps6IaKs X-Received: by 10.50.143.44 with SMTP id sb12mr9623322igb.3.1424903975088; Wed, 25 Feb 2015 14:39:35 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id n17sm12243791igi.2.2015.02.25.14.39.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Feb 2015 14:39:34 -0800 (PST) Message-ID: <54EE4F24.3080808@andyet.net> Date: Wed, 25 Feb 2015 15:39:32 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ben Campbell , precis@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [precis] Belated WGLC comments on draft-ietf-precis-saslprepbis-13 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 22:39:37 -0000 Hi Ben, thanks for the review! You've been a reviewing machine lately - must be getting in shape for IESG duty. ;-) On 2/25/15 2:50 PM, Ben Campbell wrote: > Hi, > > I apologize for the lateness of this. If my comments are a moot by now, > please feel free to ignore them. > > I support publication of this, and think this version is pretty much > ready to go. I have a few editorial comments that might be worth > considering if there is an update. > > - Abstract: > > It would be nice if the abstract mentioned something about moving from > stringprep to the precis-framework. Agreed. > - 3.4, third bullet: "… protocols that do not use SASL …" > > should this paragraph include "and follow the recommendations in this > document" or "and that reuse this profile"? clause Well, sure. :) But we can't legislate for people who aren't reading this specification (i.e., this isn't a BCP). > — 6 > > The text refers to the 4013 as SASLPrep. But this draft is _also_ > SASLPrep, isn't it? At least, it has SASLPrepbis in the short title. (Or > does the term saslprep get dropped entirely when the draft becomes an RFC?) The latter. The original document name had "saslprepbis" in it and we have't changed it in all this time. Peter From nobody Wed Feb 25 15:24:23 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 824C41A005D for ; Wed, 25 Feb 2015 15:24:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEHI6aQJeQTc for ; Wed, 25 Feb 2015 15:24:20 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39D0C1A004A for ; Wed, 25 Feb 2015 15:24:20 -0800 (PST) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t1PNO6ZO023493 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Feb 2015 17:24:16 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Peter Saint-Andre - &yet" Date: Wed, 25 Feb 2015 17:24:06 -0600 Message-ID: <3C5B38F6-6D82-419E-A486-38A40D73F52E@nostrum.com> In-Reply-To: <54EE4F24.3080808@andyet.net> References: <54EE4F24.3080808@andyet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9r5066) Archived-At: Cc: precis@ietf.org Subject: Re: [precis] Belated WGLC comments on draft-ietf-precis-saslprepbis-13 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 23:24:22 -0000 On 25 Feb 2015, at 16:39, Peter Saint-Andre - &yet wrote: > Hi Ben, thanks for the review! You've been a reviewing machine lately > - must be getting in shape for IESG duty. ;-) Yep. But it seems like you are an author on all of them ;-) > > On 2/25/15 2:50 PM, Ben Campbell wrote: […] > >> - 3.4, third bullet: "… protocols that do not use SASL …" >> >> should this paragraph include "and follow the recommendations in this >> document" or "and that reuse this profile"? clause > > Well, sure. :) But we can't legislate for people who aren't reading > this specification (i.e., this isn't a BCP). I only mentioned it because the other two bullets included it. > >> — 6 >> >> The text refers to the 4013 as SASLPrep. But this draft is _also_ >> SASLPrep, isn't it? At least, it has SASLPrepbis in the short title. >> (Or >> does the term saslprep get dropped entirely when the draft becomes an >> RFC?) > > The latter. The original document name had "saslprepbis" in it and we > have't changed it in all this time. > Okay, got it! /Ben From nobody Wed Feb 25 15:52:04 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58CF21A9236 for ; Wed, 25 Feb 2015 15:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1ehX_HVmkUe for ; Wed, 25 Feb 2015 15:52:02 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75C651A916F for ; Wed, 25 Feb 2015 15:52:02 -0800 (PST) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t1PNpmX8025806 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Feb 2015 17:51:58 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] From: "Ben Campbell" To: precis@ietf.org, "Peter Saint-Andre - &yet" Date: Wed, 25 Feb 2015 17:51:48 -0600 Message-ID: <41E08260-ED66-429A-8D74-FEA257C71264@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9r5066) Archived-At: Subject: [precis] Belated WGLC Comments on draft-ietf-precis-nickname-15 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 23:52:03 -0000 (Apologies again for a belated WGLC review. Please feel free to ignore this if it's become moot.) I think this is basically done, and I support it's publication. I only have one comment: - Table 2, last row: I did not find a proscription against zero length strings in the text, other than a comment that applications can set minimum and maximum sizes. It's quite possible I missed it. Or is this is a property of the FreeFormClass? (For comparison, I note that the saslprepbis draft explicitly forbids zero length strings.) /Ben From nobody Wed Feb 25 17:49:42 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 528151A92E6 for ; Wed, 25 Feb 2015 17:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7y7gynigQpzb for ; Wed, 25 Feb 2015 17:49:39 -0800 (PST) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1EAF1A92EF for ; Wed, 25 Feb 2015 17:49:39 -0800 (PST) Received: by mail-ig0-f176.google.com with SMTP id hl2so40736608igb.3 for ; Wed, 25 Feb 2015 17:49:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=JOhsJsJ7Se8ktyo1UoKfS0psPMRvtZgaPcYTfTfFOqM=; b=cM4eUy3LlP6l6ZL6w6Kh4ZxebpoLgIWWC5qxJR2X2iTbuG2TtqOGxRGne7JerZyl0u w8HdBblh9SSxKgHSomGADSIkOCfySGPbucrlvw4hFVTpY09a56dWsBDPiSWTAXTln5sD qi+Wf62Ed57u28HfD9gG4ksnO8cRd0hUydsmb3qRfUreobfyltJzmSsnlBgZcVCP5z7+ 76mUZ9TEzeaBu2DEhRQHWRITQTmVQtJ5vcrP0H5ayYXF8ydfr+jmy3+/1pBYjiox35lr 2SHrK+/FxFEY2zo9vHteuGCc9WHKcZ5uHkqX4jFqzIDRbv4NeY0KM246ooZWKst5hRs5 wQ2g== X-Gm-Message-State: ALoCoQkPvb5311u2ZG0jrXHJXDfSb2n+xwCFBbBlSHEFYj2sdyFzI6JwNe79B9/2cabjAbKaYVfY X-Received: by 10.107.169.42 with SMTP id s42mr8680023ioe.46.1424915379185; Wed, 25 Feb 2015 17:49:39 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id a31sm10846306ioj.42.2015.02.25.17.49.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Feb 2015 17:49:38 -0800 (PST) Message-ID: <54EE7BB1.5070703@andyet.net> Date: Wed, 25 Feb 2015 18:49:37 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ben Campbell References: <54EE4F24.3080808@andyet.net> <3C5B38F6-6D82-419E-A486-38A40D73F52E@nostrum.com> In-Reply-To: <3C5B38F6-6D82-419E-A486-38A40D73F52E@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: precis@ietf.org Subject: Re: [precis] Belated WGLC comments on draft-ietf-precis-saslprepbis-13 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 01:49:41 -0000 On 2/25/15 4:24 PM, Ben Campbell wrote: > On 25 Feb 2015, at 16:39, Peter Saint-Andre - &yet wrote: > >> Hi Ben, thanks for the review! You've been a reviewing machine lately >> - must be getting in shape for IESG duty. ;-) > > Yep. But it seems like you are an author on all of them ;-) Writing machines, reviewing machines - it all goes together well! >> On 2/25/15 2:50 PM, Ben Campbell wrote: > > […] > >> >>> - 3.4, third bullet: "… protocols that do not use SASL …" >>> >>> should this paragraph include "and follow the recommendations in this >>> document" or "and that reuse this profile"? clause >> >> Well, sure. :) But we can't legislate for people who aren't reading >> this specification (i.e., this isn't a BCP). > > I only mentioned it because the other two bullets included it. Good point. Will fix. Peter From nobody Wed Feb 25 17:53:14 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414731A92F4 for ; Wed, 25 Feb 2015 17:53:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acVApLMkoW_P for ; Wed, 25 Feb 2015 17:53:12 -0800 (PST) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03D481A92F1 for ; Wed, 25 Feb 2015 17:53:12 -0800 (PST) Received: by iecrl12 with SMTP id rl12so10305545iec.2 for ; Wed, 25 Feb 2015 17:53:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jCdhb+haIQ51bRMFrsIpKwWVWobQSl1hIh3ZpaJylo0=; b=m3eWnGSR/K5stz2VPjV9JIzDbt/UMrNWE5vaweR2nziPrS4UjABLPo3f1KOEIayyHu Hw0a+qMtSTisjDT18IGYAcrOblvv74CCJRZFhec+l0PpUvtKbUmGSrs3BTm2cyoHsQhH MUO5JxsiFlJoUi3uiq/EKizSNl50whOfayBBxhFISyiOLe7z6ilWYIDwG1LRWf5HzFOt ZzL87pCutR2JvON1gb5fOdkzPlY24yqDg/1fqnQvDNHrhDw912q6zUT0PYdM+hpsZod9 ydO5njuhv5Irc5Pq0+H8KiJ6FBUixAnDjaIZGBlmYP6XCL1aPlvW6U9KXZluWjXnbzbe I2FA== X-Gm-Message-State: ALoCoQmxUdRkhAfCsEPF+ktOnAEEgGzU/MByrSr2YDSR66JpRp3WihTK8kkITuhAWVVuszA1hSg5 X-Received: by 10.43.64.204 with SMTP id xj12mr1718947icb.9.1424915591454; Wed, 25 Feb 2015 17:53:11 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id c8sm283266igx.9.2015.02.25.17.53.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Feb 2015 17:53:10 -0800 (PST) Message-ID: <54EE7C85.5010408@andyet.net> Date: Wed, 25 Feb 2015 18:53:09 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ben Campbell , precis@ietf.org References: <41E08260-ED66-429A-8D74-FEA257C71264@nostrum.com> In-Reply-To: <41E08260-ED66-429A-8D74-FEA257C71264@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [precis] Belated WGLC Comments on draft-ietf-precis-nickname-15 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 01:53:13 -0000 On 2/25/15 4:51 PM, Ben Campbell wrote: > (Apologies again for a belated WGLC review. Please feel free to ignore > this if it's become moot.) > > > I think this is basically done, and I support it's publication. I only > have one comment: > > - Table 2, last row: > > I did not find a proscription against zero length strings in the text, > other than a comment that applications can set minimum and maximum > sizes. It's quite possible I missed it. Or is this is a property of the > FreeFormClass? (For comparison, I note that the saslprepbis draft > explicitly forbids zero length strings.) Yes, it would be good to add a rule about that. I find it difficult to think of an instance where a zero-length string makes sense within PRECIS, but we don't prohibit them in the framework so we'll need to do that in each profile. Something for profile authors to pay attention to (and, unfortunately, forget to address). Peter From nobody Wed Feb 25 18:10:01 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706511ABD39 for ; Wed, 25 Feb 2015 18:10:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9l9rOwhILMF for ; Wed, 25 Feb 2015 18:09:59 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6053F1ABD38 for ; Wed, 25 Feb 2015 18:09:59 -0800 (PST) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t1Q29e5J036774 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Feb 2015 20:09:50 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Peter Saint-Andre - &yet" Date: Wed, 25 Feb 2015 20:09:40 -0600 Message-ID: In-Reply-To: <54EE7C85.5010408@andyet.net> References: <41E08260-ED66-429A-8D74-FEA257C71264@nostrum.com> <54EE7C85.5010408@andyet.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9r5066) Archived-At: Cc: precis@ietf.org Subject: Re: [precis] Belated WGLC Comments on draft-ietf-precis-nickname-15 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 02:10:00 -0000 On 25 Feb 2015, at 19:53, Peter Saint-Andre - &yet wrote: > On 2/25/15 4:51 PM, Ben Campbell wrote: >> (Apologies again for a belated WGLC review. Please feel free to >> ignore >> this if it's become moot.) >> >> >> I think this is basically done, and I support it's publication. I >> only >> have one comment: >> >> - Table 2, last row: >> >> I did not find a proscription against zero length strings in the >> text, >> other than a comment that applications can set minimum and maximum >> sizes. It's quite possible I missed it. Or is this is a property of >> the >> FreeFormClass? (For comparison, I note that the saslprepbis draft >> explicitly forbids zero length strings.) > > Yes, it would be good to add a rule about that. I find it difficult to > think of an instance where a zero-length string makes sense within > PRECIS, but we don't prohibit them in the framework so we'll need to > do that in each profile. Something for profile authors to pay > attention to (and, unfortunately, forget to address). I'm neutral as to whether the profile needs to outlaw zero length strings or leave that to the application. My point wasn't that I think we need the rule, it was that the table assumes the rule. /Ben From nobody Wed Feb 25 20:15:14 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0823A1A040C for ; Wed, 25 Feb 2015 20:15:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTOSLBgnF6_D for ; Wed, 25 Feb 2015 20:15:11 -0800 (PST) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B064C1A01AA for ; Wed, 25 Feb 2015 20:15:11 -0800 (PST) Received: by iecvy18 with SMTP id vy18so10843183iec.13 for ; Wed, 25 Feb 2015 20:15:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ogtVjeTnEhFUxZoStg1+wPc+3KSAZvyg6xgwE+1MqVQ=; b=VmROxHm9YmYGuXR/VyW7q8SQmmBymzGbhmGpG3d4XveQDKynl5TYofjRR9tTDlkSHo EOFbadkGF4ZD0eJaoIVlZnV0dZk0r1HihhfUcWlUelQSLAjRvv4LJsFRiaxMv5MmmWIO H6unKzKxM4SBikdFDp/px17OFbENnx+Mlqqm0gqqDVzG1FCaXclhC8Q/sGR/JOt5un9+ XCsHwruCYHMHS8SVyUBma7HEEzS3rCiDn85OlN10HATPiPbYP4ycB6mK5I73J3V88xkW Wdx0gWMBJEWlGskaUp+4E6rADMycyg92l8v+cGmy6JqBEDmtE4UrmDt06MWYeXNAIsRr 9Dyg== X-Gm-Message-State: ALoCoQmnWwdsYmwMdWa+A8R1OdjpaHnH07rdi8iqvTKWOUkLXGcpZv4gUQAyT5m8zp3pEC+P/Gir X-Received: by 10.107.9.213 with SMTP id 82mr9181218ioj.56.1424924111143; Wed, 25 Feb 2015 20:15:11 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id 30sm24760867iok.15.2015.02.25.20.15.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Feb 2015 20:15:10 -0800 (PST) Message-ID: <54EE9DCD.9090004@andyet.net> Date: Wed, 25 Feb 2015 21:15:09 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ben Campbell References: <41E08260-ED66-429A-8D74-FEA257C71264@nostrum.com> <54EE7C85.5010408@andyet.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: precis@ietf.org Subject: Re: [precis] Belated WGLC Comments on draft-ietf-precis-nickname-15 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 04:15:13 -0000 On 2/25/15 7:09 PM, Ben Campbell wrote: > On 25 Feb 2015, at 19:53, Peter Saint-Andre - &yet wrote: > >> On 2/25/15 4:51 PM, Ben Campbell wrote: >>> (Apologies again for a belated WGLC review. Please feel free to ignore >>> this if it's become moot.) >>> >>> >>> I think this is basically done, and I support it's publication. I only >>> have one comment: >>> >>> - Table 2, last row: >>> >>> I did not find a proscription against zero length strings in the text, >>> other than a comment that applications can set minimum and maximum >>> sizes. It's quite possible I missed it. Or is this is a property of the >>> FreeFormClass? (For comparison, I note that the saslprepbis draft >>> explicitly forbids zero length strings.) >> >> Yes, it would be good to add a rule about that. I find it difficult to >> think of an instance where a zero-length string makes sense within >> PRECIS, but we don't prohibit them in the framework so we'll need to >> do that in each profile. Something for profile authors to pay >> attention to (and, unfortunately, forget to address). > > I'm neutral as to whether the profile needs to outlaw zero length > strings or leave that to the application. My point wasn't that I think > we need the rule, it was that the table assumes the rule. True. But I do think that a zero-length nickname makes no sense. Peter P.S. I'm sorry that this work has held up draft-ietf-simple-chat for so long! From nobody Thu Feb 26 07:36:31 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5271A03A3; Thu, 26 Feb 2015 07:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eupOaKNOYP7L; Thu, 26 Feb 2015 07:36:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21CAE1A0173; Thu, 26 Feb 2015 07:36:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Marc Blanchet" To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150226153619.24469.26484.idtracker@ietfa.amsl.com> Date: Thu, 26 Feb 2015 07:36:19 -0800 Archived-At: Cc: draft-ietf-precis-nickname@ietf.org, draft-ietf-precis-nickname.ad@ietf.org, precis@ietf.org, draft-ietf-precis-nickname.shepherd@ietf.org, iesg-secretary@ietf.org, precis-chairs@ietf.org, joe-ietf@cursive.net, precis-chairs@tools.ietf.org Subject: [precis] Publication has been requested for draft-ietf-precis-nickname-15 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 15:36:30 -0000 Marc Blanchet has requested publication of draft-ietf-precis-nickname-15 as Proposed Standard on behalf of the PRECIS working group. Please verify the document's state at http://datatracker.ietf.org/doc/draft-ietf-precis-nickname/ From nobody Thu Feb 26 07:37:50 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89BDC1A039C; Thu, 26 Feb 2015 07:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0AvNKaqBy2Z; Thu, 26 Feb 2015 07:37:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C671A046D; Thu, 26 Feb 2015 07:37:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Marc Blanchet" To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150226153744.18821.25337.idtracker@ietfa.amsl.com> Date: Thu, 26 Feb 2015 07:37:44 -0800 Archived-At: Cc: draft-ietf-precis-saslprepbis@ietf.org, linuxwolf@outer-planes.net, precis@ietf.org, iesg-secretary@ietf.org, draft-ietf-precis-saslprepbis.ad@ietf.org, precis-chairs@ietf.org, precis-chairs@tools.ietf.org, draft-ietf-precis-saslprepbis.shepherd@ietf.org Subject: [precis] Publication has been requested for draft-ietf-precis-saslprepbis-13 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 15:37:48 -0000 Marc Blanchet has requested publication of draft-ietf-precis-saslprepbis-13 as Proposed Standard on behalf of the PRECIS working group. Please verify the document's state at http://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/ From nobody Thu Feb 26 18:17:43 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C71741A6F5D; Thu, 26 Feb 2015 18:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzq3dvbxkUaC; Thu, 26 Feb 2015 18:17:38 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96DF41A6F87; Thu, 26 Feb 2015 18:17:38 -0800 (PST) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t1R2HHZu007410 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Feb 2015 20:17:27 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] From: "Ben Campbell" To: "XMPP Group" , precis@ietf.org Date: Thu, 26 Feb 2015 20:17:17 -0600 Message-ID: <98C92FA8-F99C-4861-9199-7B0443506574@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9r5066) Archived-At: Cc: Peter Saint-Andre - &yet Subject: [precis] Cross-WG WGLC of draft-ietf-xmpp-6122bis-18 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2015 02:17:39 -0000 (Cross-posted to XMPP and PRECIS) Hi, This is a XMPP working group last call for draft-ietf-xmpp-6122bis-18. Since this draft includes a profile of the PRECIS framework, we are cross-posting the WGLC to PRECIS. https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/ We actually did a WGLC on this about a year ago, but much has changed since then. Please send comments to the authors and both lists by March 12, 2015. If you've read the draft and consider it ready to go, please send comments to that effect. Thanks! Ben. From nobody Fri Feb 27 13:35:42 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 035D31A0204 for ; Fri, 27 Feb 2015 13:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCUTdSZklsyw for ; Fri, 27 Feb 2015 13:35:38 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8101B1A00FE for ; Fri, 27 Feb 2015 13:35:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1250; q=dns/txt; s=iport; t=1425072938; x=1426282538; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=zVFrLfQMCdp6FITjDrGh8+a4f0pIIatky8tcwBSesiA=; b=iVERgc78rR1aV2vpP+PfFmywKoPg/x+WcnFLjmG7KoFoO6YYrPYZ0oRG hzKMTMiuMkzt2EDDBWyipGQv6LfZaMpGiiIvLYKR1Z4lTFM42BPweI1dL uygKOvPRgIuGJwTTIMsQpgK+gn0lAHgE0sJdCrw9foyaLWOLBQVMaCA0/ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CMCAAl4vBU/5NdJa1bgwJSWgSDBrkhhXCHIE0BAQEBAQF8hDkPAUU2AgUWCwILAwIBAgE1Fg0GAgEBiCutco9ImXQBAQEHAQEBAQEZBIEhkU6BQwWKWoh7hWaBGoVPhhiGUyOCAR2BcE+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.09,662,1418083200"; d="scan'208";a="399723363" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-7.cisco.com with ESMTP; 27 Feb 2015 21:35:38 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t1RLZbhr003262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 27 Feb 2015 21:35:37 GMT Received: from [10.129.24.63] (10.129.24.63) by xhc-rcd-x01.cisco.com (173.37.183.75) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 27 Feb 2015 15:35:37 -0600 Message-ID: <54F0E329.9000009@cisco.com> Date: Fri, 27 Feb 2015 14:35:37 -0700 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: IETF PRECIS WG Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.129.24.63] Archived-At: Subject: [precis] (More) Belated WGLC Comments on draft-ietf-precis-saslprepbis-13 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2015 21:35:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 My apologies for the tardiness of these comments. Overall, I think this document is ready for publication. I agree with the comments that Ben Campbell sent earlier (and Peter's responses). My only outstanding concern: * [MINOR] - The reference to UNICODE in this document is to version 6.3, while precis-framework references version 7.0 and text in section 6.1 mentions version 7.0. Is the difference intentional here, or a case of missing a reference update? I'm guessing it's a missed reference ... And thanks to the authors for all their hard work! - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU8OMoAAoJEDWi+S0W7cO1MwQH/2n2wpjxer6nJdI5AdgzJS+8 bFSAR+WrZHaSbTKKazXZO1Cs7O+foQvS7Tu/IAu4QyefHTRTa5lMQAd49X32/hfU YngVRTcppmmOgQvqbUvFHXwzyVqwLVuuf4NonHa5orSjjP/ZwudITRscRKNlUCmd SNW+ath736CeNTwcnr0GlIsD3UH6zMOyik5BuXgrafdMAJBXmyAvU1RU10qDYIUf J3dgB6W9ZEeNkWqXAQ8u5HxZ2mVJef/73whhzjIiwDqom33KP2gyO03HtoIYl6tW ThM+ngHsjLrrLzrZ45oP7zlLHat6kpup2UT13bAHRvfqlYFYhRRANE8d1UhUQ74= =Q339 -----END PGP SIGNATURE-----