From nobody Mon Apr 7 10:41:16 2014 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 32D641A081D for ; Mon, 7 Apr 2014 10:41:15 -0700 (PDT) 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 uUfJQUzIZqFo for ; Mon, 7 Apr 2014 10:41:10 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id BEEF91A0827 for ; Mon, 7 Apr 2014 10:40:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1396892433; x=1428428433; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=Z9b8YjrGxVnu5I4x7AFOw7yjnzE51emliANMyvsrgOI=; b=iomV4vaLmf8nKSEJbdRnsSSac54qlzVOF3QBH3PQgKXyd+YoH7+MB2tG FOrjPq3a/gsq5yhPO1tRodBPlG+sqWrdqHUXRNFuuUbNWLqF5KpRr1SiH D9tcaiimw29/2eUNA230lEItdimjqfOFwabGM91eMIgGXrSM3mn5GROLh M=; X-IronPort-AV: E=McAfee;i="5400,1158,7401"; a="27161216" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP; 07 Apr 2014 10:40:32 -0700 X-IronPort-AV: E=Sophos;i="4.97,811,1389772800"; d="scan'208";a="645123356" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 07 Apr 2014 10:40:31 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 7 Apr 2014 10:40:30 -0700 Message-ID: <5342E30B.4090700@qti.qualcomm.com> Date: Mon, 7 Apr 2014 12:40:27 -0500 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: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Archived-At: http://mailarchive.ietf.org/arch/msg/precis/lA1QDJvKGkU1yWIA9-JPBaFYGdQ Subject: [precis] AD Evaluation of draft-ietf-precis-framework-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: Mon, 07 Apr 2014 17:41:15 -0000 At long last, I finally completed my review of the framework document. My personal feeling here is that I should go ahead and do the IETF Last Call and consider the below equivalent to Last Call comments, and we can discuss them here during Last Call. If anyone has any concerns about that and thinks we really need to discuss something before I issue the Last Call, please say so now (i.e., in the next 24 hours). Otherwise, the Last Call will go out tomorrow. ----- Substantive issue: ----- 4.1.5: I'm not thrilled with this section in general, but in particular I'm not sure what "mixed-direction strings are not supported" means. We do know how to process strings that contain characters with a mix of directionality. Such strings are sometimes a visual challenge, but not a processing challenge: RFC 5893 exists because IDNs want to use "." as a label separator yet have text display work in a context that is unaware of labels. Neither using 5893 nor considering any RTL character making the whole string RTL is a good recommendation for most cases. Not sure what to do about this. ----- Editorial issues: ----- Throughout: Change "Informational Note:" to "Note:". I don't see any of them for which it makes a difference. 3.1: I would move the first paragraph down further in the section. I would delete the parenthetical at the end of "Contextual Rule Required"; no need to introduce undefined terms here. 3.2.4 and 3.3.4: The SHALLs in here seem weird to me. Above, you don't say that a string with a Disallowed character "SHALL be rejected". If it were me, I'd simply say: Any code points that are not yet designated in the Unicode character set are considered Unassigned for purposes of the XXXClass, and such code points are to be treated as Disallowed. 4.1: Change "MUST register" to "are registered". MUSTs for registration seem silly. (If you want to say, "Implementations MUST NOT use unregistered classes", you could, but I don't think you want to do that.) Change "It is RECOMMENDED for profile names to be of the form" to "The naming convention for profile names is to use the form". 4.2: A bit of ABNF neatening: OLD fullname = namepart [1*(1*SP namepart)] namepart = 1*(idpoint) NEW fullname = namepart *(1*SP namepart) namepart = 1*idpoint 9.2: It might be nice to add section numbers (3.2 and 3.3) to the registrations for IdentifierClass and FreeformClass. 9.3: It might be nice to note the naming convention from 4.1 in the template. ----- That's it. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Mon Apr 7 11:26:32 2014 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 3BC0F1A07D2 for ; Mon, 7 Apr 2014 11:26:28 -0700 (PDT) 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 DrItkORU9CPM for ; Mon, 7 Apr 2014 11:26:23 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 311391A0767 for ; Mon, 7 Apr 2014 11:26:16 -0700 (PDT) Received: from [IPv6:2620::230:c000:c999:5e25:78f6:c5dd] (unknown [IPv6:2620:0:230:c000:c999:5e25:78f6:c5dd]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3121140398; Mon, 7 Apr 2014 14:26:10 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Marc Blanchet In-Reply-To: <5342E30B.4090700@qti.qualcomm.com> Date: Mon, 7 Apr 2014 14:26:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <83EEB695-456C-4260-8588-D0F73689A404@viagenie.ca> References: <5342E30B.4090700@qti.qualcomm.com> To: Pete Resnick X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/precis/vFQOqQj65ph187fEqCc_xsn6r60 Cc: precis@ietf.org Subject: Re: [precis] AD Evaluation of draft-ietf-precis-framework-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: Mon, 07 Apr 2014 18:26:28 -0000 Le 2014-04-07 =E0 13:40, Pete Resnick a = =E9crit : > At long last, I finally completed my review of the framework document. = My personal feeling here is that I should go ahead and do the IETF Last = Call and consider the below equivalent to Last Call comments, and we can = discuss them here during Last Call. If anyone has any concerns about = that and thinks we really need to discuss something before I issue the = Last Call, please say so now (i.e., in the next 24 hours). Otherwise, = the Last Call will go out tomorrow. my take from your comments below is that we can manage them during the = IETF last call, so I suggest we proceed with IETF Last call.=20 Regards, Marc. >=20 > ----- > Substantive issue: > ----- >=20 > 4.1.5: I'm not thrilled with this section in general, but in = particular I'm not sure what "mixed-direction strings are not supported" = means. We do know how to process strings that contain characters with a = mix of directionality. Such strings are sometimes a visual challenge, = but not a processing challenge: RFC 5893 exists because IDNs want to use = "." as a label separator yet have text display work in a context that is = unaware of labels. Neither using 5893 nor considering any RTL character = making the whole string RTL is a good recommendation for most cases. Not = sure what to do about this. >=20 > ----- > Editorial issues: > ----- >=20 > Throughout: Change "Informational Note:" to "Note:". I don't see any = of them for which it makes a difference. >=20 > 3.1: >=20 > I would move the first paragraph down further in the section. >=20 > I would delete the parenthetical at the end of "Contextual Rule = Required"; no need to introduce undefined terms here. >=20 > 3.2.4 and 3.3.4: The SHALLs in here seem weird to me. Above, you don't = say that a string with a Disallowed character "SHALL be rejected". If it = were me, I'd simply say: >=20 > Any code points that are not yet designated in the Unicode character > set are considered Unassigned for purposes of the XXXClass, and such > code points are to be treated as Disallowed. >=20 > 4.1: >=20 > Change "MUST register" to "are registered". MUSTs for registration = seem silly. (If you want to say, "Implementations MUST NOT use = unregistered classes", you could, but I don't think you want to do = that.) >=20 > Change "It is RECOMMENDED for profile names to be of the form" to "The = naming convention for profile names is to use the form". >=20 > 4.2: A bit of ABNF neatening: >=20 > OLD > fullname =3D namepart [1*(1*SP namepart)] > namepart =3D 1*(idpoint) > NEW > fullname =3D namepart *(1*SP namepart) > namepart =3D 1*idpoint >=20 > 9.2: It might be nice to add section numbers (3.2 and 3.3) to the = registrations for IdentifierClass and FreeformClass. >=20 > 9.3: It might be nice to note the naming convention from 4.1 in the = template. > ----- >=20 > That's it. >=20 > pr >=20 > --=20 > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 >=20 > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis From nobody Wed Apr 9 12:08:18 2014 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 E2B541A0457; Wed, 9 Apr 2014 12:08:11 -0700 (PDT) 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 FUzf-eXqiMIy; Wed, 9 Apr 2014 12:08:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 484AA1A0458; Wed, 9 Apr 2014 12:07:44 -0700 (PDT) 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.2.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140409190744.15518.7195.idtracker@ietfa.amsl.com> Date: Wed, 09 Apr 2014 12:07:44 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/precis/zsZevufobaE4kANj1wwxWFb6594 Cc: precis@ietf.org Subject: [precis] Last Call: (PRECIS Framework: Preparation 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: Wed, 09 Apr 2014 19:08:12 -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 and Comparison of Internationalized Strings in Application Protocols' as Proposed Standard 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 2014-04-23. 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 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. 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. This document makes a normative reference to RFC 20, which predates document statuses and therefore may be a downward reference. 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 Apr 11 20:04:19 2014 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 1993F1A01E1 for ; Fri, 11 Apr 2014 20:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, 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 RXtAHqrsHCEc for ; Fri, 11 Apr 2014 20:04:15 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id AECB01A000A for ; Fri, 11 Apr 2014 20:04:15 -0700 (PDT) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C81E740352; Fri, 11 Apr 2014 21:04:13 -0600 (MDT) Message-ID: <5348AD2D.9080308@stpeter.im> Date: Fri, 11 Apr 2014 21:04:13 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "precis@ietf.org" References: <68FA58CE-C00A-4281-8B7E-5C96A0B3B835@nostrum.com> In-Reply-To: <68FA58CE-C00A-4281-8B7E-5C96A0B3B835@nostrum.com> X-Forwarded-Message-Id: <68FA58CE-C00A-4281-8B7E-5C96A0B3B835@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/9tX5nnfNJDA3ygZOi6riburyNGk Subject: [precis] Fwd: WGLC of draft-ietf-xmpp-6122bis-11 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, 12 Apr 2014 03:04:17 -0000 I think we neglected to forward this message to the PRECIS WG list. BTW the latest version (incorporating WGLC feedback from the XMPP WG) is here: http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-12 Reviews would be very much appreciated. Thanks! Peter -------- Original Message -------- Subject: WGLC of draft-ietf-xmpp-6122bis-11 Date: Mon, 17 Mar 2014 14:50:32 -0500 From: Ben Campbell To: XMPP Working Group CC: Peter Saint-Andre , Joe Hildebrand This is a Working Group Last Call of draft-ietf-xmpp-6122bis-11. The draft is available at the following URL: http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-11 The WGLC will conclude on 31 March, 2014. Please send your comments to the authors and the XMPP mailing list. Thanks! Ben. From nobody Mon Apr 14 20:18:12 2014 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 6D6A81A0318 for ; Mon, 14 Apr 2014 20:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.275 X-Spam-Level: X-Spam-Status: No, score=-0.275 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, 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 SW3VuxaO1jcM for ; Mon, 14 Apr 2014 20:18:09 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A51F31A02F6 for ; Mon, 14 Apr 2014 20:18:09 -0700 (PDT) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9466D40347; Mon, 14 Apr 2014 21:18:05 -0600 (MDT) Message-ID: <534CA4EC.8050702@stpeter.im> Date: Mon, 14 Apr 2014 21:18:04 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Pete Resnick , precis@ietf.org References: <5342E30B.4090700@qti.qualcomm.com> In-Reply-To: <5342E30B.4090700@qti.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/BKNqAakikF3o3iZADHZ8hBQF2G8 Subject: Re: [precis] AD Evaluation of draft-ietf-precis-framework-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: Tue, 15 Apr 2014 03:18:11 -0000 On 4/7/14, 11:40 AM, Pete Resnick wrote: > At long last, I finally completed my review of the framework document. > My personal feeling here is that I should go ahead and do the IETF Last > Call and consider the below equivalent to Last Call comments, and we can > discuss them here during Last Call. If anyone has any concerns about > that and thinks we really need to discuss something before I issue the > Last Call, please say so now (i.e., in the next 24 hours). Otherwise, > the Last Call will go out tomorrow. Great, thanks Pete! > ----- > Substantive issue: > ----- > > 4.1.5: I'm not thrilled with this section in general, but in particular > I'm not sure what "mixed-direction strings are not supported" means. We > do know how to process strings that contain characters with a mix of > directionality. Such strings are sometimes a visual challenge, but not a > processing challenge: RFC 5893 exists because IDNs want to use "." as a > label separator yet have text display work in a context that is unaware > of labels. Neither using 5893 nor considering any RTL character making > the whole string RTL is a good recommendation for most cases. Not sure > what to do about this. See: http://www.ietf.org/mail-archive/web/precis/current/msg00553.html and http://www.ietf.org/mail-archive/web/precis/current/msg00557.html I am not sure how helpful it is to distinguish between processing challenges and presentation challenges. I will ponder this further and reply again. > ----- > Editorial issues: > ----- > > Throughout: Change "Informational Note:" to "Note:". I don't see any of > them for which it makes a difference. Sure. > 3.1: > > I would move the first paragraph down further in the section. Seems we could delete it altogether. > I would delete the parenthetical at the end of "Contextual Rule > Required"; no need to introduce undefined terms here. Sure. > 3.2.4 and 3.3.4: The SHALLs in here seem weird to me. Above, you don't > say that a string with a Disallowed character "SHALL be rejected". If it > were me, I'd simply say: > > Any code points that are not yet designated in the Unicode character > set are considered Unassigned for purposes of the XXXClass, and such > code points are to be treated as Disallowed. Works for me. > 4.1: > > Change "MUST register" to "are registered". MUSTs for registration seem > silly. (If you want to say, "Implementations MUST NOT use unregistered > classes", you could, but I don't think you want to do that.) > > Change "It is RECOMMENDED for profile names to be of the form" to "The > naming convention for profile names is to use the form". That's better, yes. > 4.2: A bit of ABNF neatening: > > OLD > fullname = namepart [1*(1*SP namepart)] > namepart = 1*(idpoint) > NEW > fullname = namepart *(1*SP namepart) > namepart = 1*idpoint Noted. > 9.2: It might be nice to add section numbers (3.2 and 3.3) to the > registrations for IdentifierClass and FreeformClass. > > 9.3: It might be nice to note the naming convention from 4.1 in the > template. Will do. > That's it. Excellent, thanks. Peter From nobody Tue Apr 15 17:32:34 2014 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 0ACCB1A0065 for ; Tue, 15 Apr 2014 17:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, 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 AEH_Zlgcr06U for ; Tue, 15 Apr 2014 17:32:31 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 595CF1A0015 for ; Tue, 15 Apr 2014 17:32:31 -0700 (PDT) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D81EF40347; Tue, 15 Apr 2014 18:32:27 -0600 (MDT) Message-ID: <534DCF9A.3050102@stpeter.im> Date: Tue, 15 Apr 2014 18:32:26 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Pete Resnick , precis@ietf.org References: <5342E30B.4090700@qti.qualcomm.com> <534CA4EC.8050702@stpeter.im> In-Reply-To: <534CA4EC.8050702@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/WCggGOmI2hgBfEf29BHFZQ-Zm4A Subject: Re: [precis] AD Evaluation of draft-ietf-precis-framework-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, 16 Apr 2014 00:32:33 -0000 On 4/14/14, 9:18 PM, Peter Saint-Andre wrote: > On 4/7/14, 11:40 AM, Pete Resnick wrote: >> At long last, I finally completed my review of the framework document. >> My personal feeling here is that I should go ahead and do the IETF Last >> Call and consider the below equivalent to Last Call comments, and we can >> discuss them here during Last Call. If anyone has any concerns about >> that and thinks we really need to discuss something before I issue the >> Last Call, please say so now (i.e., in the next 24 hours). Otherwise, >> the Last Call will go out tomorrow. > > Great, thanks Pete! > >> ----- >> Substantive issue: >> ----- >> >> 4.1.5: I'm not thrilled with this section in general, but in particular >> I'm not sure what "mixed-direction strings are not supported" means. We >> do know how to process strings that contain characters with a mix of >> directionality. Such strings are sometimes a visual challenge, but not a >> processing challenge: RFC 5893 exists because IDNs want to use "." as a >> label separator yet have text display work in a context that is unaware >> of labels. Neither using 5893 nor considering any RTL character making >> the whole string RTL is a good recommendation for most cases. Not sure >> what to do about this. > > See: > > http://www.ietf.org/mail-archive/web/precis/current/msg00553.html > > and > > http://www.ietf.org/mail-archive/web/precis/current/msg00557.html > > I am not sure how helpful it is to distinguish between processing > challenges and presentation challenges. > > I will ponder this further and reply again. I recall discussion at one of our in-person meetings about bidi. As I recall, John Klensin sagaciously pointed out that if the PRECIS WG tried to define a new rule for directionality we would almost certainly get it wrong, and that it was better to use the Bidi Rule from RFC 5893 than to design something new. Even though it might be true that the Bidi Rule might not be a good recommendation for most cases, I do not have confidence in our ability to come up with a better recommendation. Would you say that the Bidi Rule works for domain names because "." is a label separator? In particular, my understanding of the Bidi Rule is that it doesn't allow mixed-direction *labels*, although it does allow mixed-direction domain names (where the direction changes at the point of the label separator). It seems to me that not supporting mixed-direction strings in PRECIS is consistent with RFC 5893. I realize that's not ideal, but it might be the best that *we* can do *now*. Whether some other group could do something better in the future might be irrelevant. >> ----- >> Editorial issues: >> ----- >> >> Throughout: Change "Informational Note:" to "Note:". I don't see any of >> them for which it makes a difference. > > Sure. BTW, in RFC 6120/6121 I used a personal convention of three kinds of notes: informational notes, interoperability notes, and security warnings. My use of "Informational Note:" here derives from that, although this document doesn't have any interoperability notes so it might seem a bit strange to include the adjective. Peter From nobody Fri Apr 18 15:29:23 2014 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 ABA991A014D for ; Fri, 18 Apr 2014 15:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, 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 lmhOMKv_HhYP for ; Fri, 18 Apr 2014 15:29:18 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id CD3661A01B5 for ; Fri, 18 Apr 2014 15:29:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1397860155; x=1429396155; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=861u/PHkyW3obxMKJxbfJBoUiiUnybHgV8w/JGEiBdc=; b=jwoyQo0bzD16KStyZ0jQU5HOBsJyVaZRr8A6vU5lIq7jbOsO8I1oC2ct hKKGOwpbJS4ZqjhCF0OH8U9Xy1CIPI5uhXZ/GSThU7BHnpSQ248T8dFmk +dxzmH2nnxZnLzFwj3+FPjxASUhLEUguukmCcsYZSvcQxOB3bVRgek07d 0=; X-IronPort-AV: E=McAfee;i="5400,1158,7412"; a="62189079" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP; 18 Apr 2014 15:29:14 -0700 X-IronPort-AV: E=Sophos;i="4.97,886,1389772800"; d="scan'208";a="664387617" Received: from nasanexhc13.na.qualcomm.com ([172.30.48.20]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 18 Apr 2014 15:29:14 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc13.na.qualcomm.com (172.30.48.20) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 18 Apr 2014 15:29:13 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 18 Apr 2014 15:29:13 -0700 Message-ID: <5351A735.5090802@qti.qualcomm.com> Date: Fri, 18 Apr 2014 17:29:09 -0500 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 References: <5342E30B.4090700@qti.qualcomm.com> <534CA4EC.8050702@stpeter.im> <534DCF9A.3050102@stpeter.im> In-Reply-To: <534DCF9A.3050102@stpeter.im> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/precis/V7hkyMsDpI1lZhJGUEj8s75Kj1A Cc: precis@ietf.org Subject: Re: [precis] AD Evaluation of draft-ietf-precis-framework-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: Fri, 18 Apr 2014 22:29:20 -0000 On 4/15/14 7:32 PM, Peter Saint-Andre wrote: > On 4/14/14, 9:18 PM, Peter Saint-Andre wrote: >> On 4/7/14, 11:40 AM, Pete Resnick wrote: >> >>> ----- >>> Substantive issue: >>> ----- >>> >>> 4.1.5: I'm not thrilled with this section in general, but in particular >>> I'm not sure what "mixed-direction strings are not supported" means. We >>> do know how to process strings that contain characters with a mix of >>> directionality. Such strings are sometimes a visual challenge, but >>> not a >>> processing challenge: RFC 5893 exists because IDNs want to use "." as a >>> label separator yet have text display work in a context that is unaware >>> of labels. Neither using 5893 nor considering any RTL character making >>> the whole string RTL is a good recommendation for most cases. Not sure >>> what to do about this. >> >> See: >> >> http://www.ietf.org/mail-archive/web/precis/current/msg00553.html ...wherein Martin seems to say that this is only allowing fully RTL and fully LTR (i.e., no mixed direction strings). >> http://www.ietf.org/mail-archive/web/precis/current/msg00557.html ...wherein you reply that not allowing mixed direction strings was intended. :-( >> I am not sure how helpful it is to distinguish between processing >> challenges and presentation challenges. There are scant few processing challenges, at least from my long-ago-in-a-galaxy-far-far-away memory of the last time I wrote any code in this area. They are all (again, as far as I remember) presentation challenges. >> I will ponder this further and reply again. > > I recall discussion at one of our in-person meetings about bidi. As I > recall, John Klensin sagaciously pointed out that if the PRECIS WG > tried to define a new rule for directionality we would almost > certainly get it wrong, and that it was better to use the Bidi Rule > from RFC 5893 than to design something new. Even though it might be > true that the Bidi Rule might not be a good recommendation for most > cases, I do not have confidence in our ability to come up with a > better recommendation. On that we can agree. I am sure I do not want to come up with other rules for inclusion (because those rules are completely dependent on the presentation challenges you are or are not willing to contend with). I guess in the end I'd just like the text in 4.1.5 softened to say, "You can have a directionality rule for your profile anything from 'whatever mix of RTL and LTR characters you like' if you don't care how they're presented, all the way to the complicated Bidi Rule from 5893 if you expect users to be typing in protocol elements, and you have to deal with strings with separator punctuation and presentation tools that don't know about them." > Would you say that the Bidi Rule works for domain names because "." is > a label separator? In particular, my understanding of the Bidi Rule is > that it doesn't allow mixed-direction *labels*, although it does allow > mixed-direction domain names (where the direction changes at the point > of the label separator). Correct. The *only* reason for the 5893 Bidi Rule is because they wanted domain names to display identically in both LTR and RTL contexts when the display engine didn't understand that the "." was a label separator. (Well, I guess that's two reasons combined in one.) > It seems to me that not supporting mixed-direction strings in PRECIS > is consistent with RFC 5893. It is consistent with 5893, but I am saying that there are a number of cases where it's the wrong thing to do. There are protocols that shouldn't care whether that strings display inconsistently when the user changes from RTL to LTR contexts. What's the problem if I want my handle to be: pee e tee e dash pei samekh het which if I type them in that order gets you: Pete-פסח which in a LTR context will display to you as (reading them off from left to right): pee e tee e dash het samekh pei or in an RTL context will display to you as (reading them off from left to right): het samekh pei dash pee e tee e The only problem is if you are worried that people will type them in wrong because they don't know what directional context they're in. If it's just my handle name and I'm the only one typing it, you should leave me be. > I realize that's not ideal, but it might be the best that *we* can do > *now*. Whether some other group could do something better in the > future might be irrelevant. Like I said, I'm not looking for a new rule. Just less overt pushing that protocols never allow mixed direction text and that they should lean toward 5893. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Fri Apr 18 16:06:32 2014 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 90EB51A043E for ; Fri, 18 Apr 2014 16:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.573 X-Spam-Level: X-Spam-Status: No, score=-4.573 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, RP_MATCHES_RCVD=-0.272, 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 aTC98CRyNHTq for ; Fri, 18 Apr 2014 16:06:23 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 478DB1A03E2 for ; Fri, 18 Apr 2014 16:06:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1397862379; x=1429398379; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=numb9UFqhpH3wAq0qaU504+6sISqt/BoOvblx+I3Bvw=; b=vtVJ3EKFJy/TJVJagEU/gNR5L0dHQ5L00glZUmMdZnikrj256DzK8efT dT8ro78zveTNQuHFZAxxuRRqFR3LddNAvMClbTUADzlm7Jd6jbY/RWIna SVEz/YPdBxK9sUUC3SxxNffmMFCQYltKmp4k3BL1qAbKnSLJF53BLGllA 4=; X-IronPort-AV: E=McAfee;i="5400,1158,7412"; a="29750119" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by wolverine01.qualcomm.com with ESMTP; 18 Apr 2014 16:06:19 -0700 X-IronPort-AV: E=Sophos;i="4.97,886,1389772800"; d="scan'208";a="30064210" Received: from nasanexhc12.na.qualcomm.com ([172.30.39.187]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 18 Apr 2014 16:06:18 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc12.na.qualcomm.com (172.30.39.187) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 18 Apr 2014 16:06:18 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 18 Apr 2014 16:06:18 -0700 Message-ID: <5351AFE9.2020301@qti.qualcomm.com> Date: Fri, 18 Apr 2014 18:06:17 -0500 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: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/precis/57LLywkS050GPT9ZhQlduvowOSs Subject: [precis] Ballots to be copied to the WG 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, 18 Apr 2014 23:06:29 -0000 Just a heads up: I have set the datatracker to copy IESG ballots to the WG mailing list. Though I doubt it's an issue with this group, let me make the standard warning: Please allow the chairs and/or document editors to respond to comments first, and only jump in if you feel something has been missed. Remember that your messages will be Cc'ed to the IESG during a *very* heavy email week for the ADs. Thanks. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Fri Apr 18 16:08:28 2014 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 C1AB21A04A9; Fri, 18 Apr 2014 16:08:19 -0700 (PDT) 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 rE2QT9c7vsWk; Fri, 18 Apr 2014 16:08:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21EE71A04A4; Fri, 18 Apr 2014 16:08:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Pete Resnick" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140418230818.1652.58752.idtracker@ietfa.amsl.com> Date: Fri, 18 Apr 2014 16:08:18 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/precis/7fL_wU9kIGLJ3t4NrNKWXAVO3y0 Cc: precis-chairs@tools.ietf.org, draft-ietf-precis-framework@tools.ietf.org, precis@ietf.org Subject: [precis] Pete Resnick's Yes on draft-ietf-precis-framework-15: (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: Fri, 18 Apr 2014 23:08:20 -0000 Pete Resnick has entered the following ballot position for draft-ietf-precis-framework-15: Yes 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: ---------------------------------------------------------------------- The following are all items I mentioned in my AD Eval, but we decided none was a show-stopper and all could be held until the end of Last Call. The only substantive point is on 4.1.5, and the world will not end if I end up in the rough on this point. (We don't expect a whole lot of feedback during Last Call; the document got a good deal of review by a lot of experts, but the topic is pretty esoteric for anyone else to have much of a strong opinion.) Throughout: Change "Informational Note:" to "Note:". I don't see any of them for which it makes a difference. 3.1: I would move the first paragraph down further in the section. And I would delete the parenthetical at the end of "Contextual Rule Required"; no need to introduce undefined terms here. 3.2.4 and 3.3.4: The SHALLs in here seem weird to me. Above, you don't say that a string with a Disallowed character "SHALL be rejected". If it were me, I'd simply say: Any code points that are not yet designated in the Unicode character set are considered Unassigned for purposes of the XXXClass, and such code points are to be treated as Disallowed. 4.1: Change "MUST register" to "are registered". MUSTs for registration seem silly. (If you want to say, "Implementations MUST NOT use unregistered classes", you could, but I don't think you want to do that.) Change "It is RECOMMENDED for profile names to be of the form" to "The naming convention for profile names is to use the form". 4.1.5: I'm not thrilled with this section in general, but in particular I'm not sure what "mixed-direction strings are not supported" means. We do know how to process strings that contain characters with a mix of directionality. Such strings are sometimes a visual challenge, but not a processing challenge: The RFC 5893 Bidi Rule exists because IDNs want to be visually stable in either an LTR or RTL context, and because IDNs use "." as a label separator yet want to have text display consistent in a context that is unaware of labels. There are perfectly reasonable cases where none of these hold true, so I think this section could be softened so that it's not overtly pushing that protocols never allow mixed direction text or that they should always lean toward using RFC 5893. 4.2: A bit of ABNF neatening: OLD fullname = namepart [1*(1*SP namepart)] namepart = 1*(idpoint) NEW fullname = namepart *(1*SP namepart) namepart = 1*idpoint 9.2: It might be nice to add section numbers (3.2 and 3.3) to the registrations for IdentifierClass and FreeformClass. 9.3: It might be nice to note the naming convention from 4.1 in the template. From nobody Fri Apr 18 19:13:43 2014 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 AE2231A0062 for ; Fri, 18 Apr 2014 19:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, 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 e7BQdANSgV2k for ; Fri, 18 Apr 2014 19:13:37 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9F25A1A003A for ; Fri, 18 Apr 2014 19:13:37 -0700 (PDT) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 707D54032A; Fri, 18 Apr 2014 20:13:31 -0600 (MDT) Message-ID: <5351DBC9.20405@stpeter.im> Date: Fri, 18 Apr 2014 20:13:29 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Pete Resnick References: <5342E30B.4090700@qti.qualcomm.com> <534CA4EC.8050702@stpeter.im> <534DCF9A.3050102@stpeter.im> <5351A735.5090802@qti.qualcomm.com> In-Reply-To: <5351A735.5090802@qti.qualcomm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/Lvz2D6GngzfLKxNqt7wAtC9CYh4 Cc: precis@ietf.org Subject: Re: [precis] AD Evaluation of draft-ietf-precis-framework-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: Sat, 19 Apr 2014 02:13:40 -0000 On 4/18/14, 4:29 PM, Pete Resnick wrote: > On 4/15/14 7:32 PM, Peter Saint-Andre wrote: >> On 4/14/14, 9:18 PM, Peter Saint-Andre wrote: >>> On 4/7/14, 11:40 AM, Pete Resnick wrote: >>> >>>> ----- >>>> Substantive issue: >>>> ----- >>>> >>>> 4.1.5: I'm not thrilled with this section in general, but in particular >>>> I'm not sure what "mixed-direction strings are not supported" means. We >>>> do know how to process strings that contain characters with a mix of >>>> directionality. Such strings are sometimes a visual challenge, but >>>> not a >>>> processing challenge: RFC 5893 exists because IDNs want to use "." as a >>>> label separator yet have text display work in a context that is unaware >>>> of labels. Neither using 5893 nor considering any RTL character making >>>> the whole string RTL is a good recommendation for most cases. Not sure >>>> what to do about this. >>> >>> See: >>> >>> http://www.ietf.org/mail-archive/web/precis/current/msg00553.html > > ...wherein Martin seems to say that this is only allowing fully RTL and > fully LTR (i.e., no mixed direction strings). > >>> http://www.ietf.org/mail-archive/web/precis/current/msg00557.html > > ...wherein you reply that not allowing mixed direction strings was > intended. :-( > >>> I am not sure how helpful it is to distinguish between processing >>> challenges and presentation challenges. > > There are scant few processing challenges, at least from my > long-ago-in-a-galaxy-far-far-away memory of the last time I wrote any > code in this area. They are all (again, as far as I remember) > presentation challenges. > >>> I will ponder this further and reply again. >> >> I recall discussion at one of our in-person meetings about bidi. As I >> recall, John Klensin sagaciously pointed out that if the PRECIS WG >> tried to define a new rule for directionality we would almost >> certainly get it wrong, and that it was better to use the Bidi Rule >> from RFC 5893 than to design something new. Even though it might be >> true that the Bidi Rule might not be a good recommendation for most >> cases, I do not have confidence in our ability to come up with a >> better recommendation. > > On that we can agree. I am sure I do not want to come up with other > rules for inclusion (because those rules are completely dependent on the > presentation challenges you are or are not willing to contend with). I > guess in the end I'd just like the text in 4.1.5 softened to say, "You > can have a directionality rule for your profile anything from 'whatever > mix of RTL and LTR characters you like' if you don't care how they're > presented, all the way to the complicated Bidi Rule from 5893 if you > expect users to be typing in protocol elements, and you have to deal > with strings with separator punctuation and presentation tools that > don't know about them." > >> Would you say that the Bidi Rule works for domain names because "." is >> a label separator? In particular, my understanding of the Bidi Rule is >> that it doesn't allow mixed-direction *labels*, although it does allow >> mixed-direction domain names (where the direction changes at the point >> of the label separator). > > Correct. The *only* reason for the 5893 Bidi Rule is because they wanted > domain names to display identically in both LTR and RTL contexts when > the display engine didn't understand that the "." was a label separator. > (Well, I guess that's two reasons combined in one.) > >> It seems to me that not supporting mixed-direction strings in PRECIS >> is consistent with RFC 5893. > > It is consistent with 5893, but I am saying that there are a number of > cases where it's the wrong thing to do. There are protocols that > shouldn't care whether that strings display inconsistently when the user > changes from RTL to LTR contexts. What's the problem if I want my handle > to be: > > pee e tee e dash pei samekh het > > which if I type them in that order gets you: > > Pete-פסח > > which in a LTR context will display to you as (reading them off from > left to right): > > pee e tee e dash het samekh pei > > or in an RTL context will display to you as (reading them off from left > to right): > > het samekh pei dash pee e tee e > > The only problem is if you are worried that people will type them in > wrong because they don't know what directional context they're in. If > it's just my handle name and I'm the only one typing it, you should > leave me be. > >> I realize that's not ideal, but it might be the best that *we* can do >> *now*. Whether some other group could do something better in the >> future might be irrelevant. > > Like I said, I'm not looking for a new rule. Just less overt pushing > that protocols never allow mixed direction text and that they should > lean toward 5893. I'm still worried about foot-guns. Part of what we've tried to do in PREICS is to actively prevent people who don't necessarily know much about internationalization from shooting themselves in the foot. Yes, we could tell those folks "it's fine to allow whatever mix of RTL and LTR characters you like, as long as you don't care how they're presented" - but we know that could cause serious confusion if more than one actor in said protocol might view the same string. Do we really think that's a good idea? Peter From nobody Mon Apr 21 04:13:04 2014 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 74EBC1A01F3 for ; Mon, 21 Apr 2014 04:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.536 X-Spam-Level: ** X-Spam-Status: No, score=2.536 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, RP_MATCHES_RCVD=-0.272] 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 QmfxMOAacMRA for ; Mon, 21 Apr 2014 04:12:59 -0700 (PDT) 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 B93151A01F4 for ; Mon, 21 Apr 2014 04:12:57 -0700 (PDT) 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 D0B1632E577; Mon, 21 Apr 2014 20:12:49 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 56dd_0073_40937da9_18d5_4bdb_a0fd_ed7d03b7c825; Mon, 21 Apr 2014 20:12:48 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 00807BF4CE; Mon, 21 Apr 2014 20:12:48 +0900 (JST) Message-ID: <5354FD24.6060003@it.aoyama.ac.jp> Date: Mon, 21 Apr 2014 20:12:36 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Peter Saint-Andre , Pete Resnick References: <5342E30B.4090700@qti.qualcomm.com> <534CA4EC.8050702@stpeter.im> <534DCF9A.3050102@stpeter.im> <5351A735.5090802@qti.qualcomm.com> <5351DBC9.20405@stpeter.im> In-Reply-To: <5351DBC9.20405@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/precis/qpMr_j51EKtcu5azbPSaas7qDbI Cc: precis@ietf.org Subject: Re: [precis] AD Evaluation of draft-ietf-precis-framework-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: Mon, 21 Apr 2014 11:13:03 -0000 [Sorry for the top-posting, but it's way easier for those who want to=20 see just the next bit of the argument.] On 2014/04/19 11:13, Peter Saint-Andre wrote: >>>> I'm still worried about foot-guns. Part of what we've tried to do in=20 PREICS is to actively prevent people who don't necessarily know much=20 about internationalization from shooting themselves in the foot. Yes, we=20 could tell those folks "it's fine to allow whatever mix of RTL and LTR=20 characters you like, as long as you don't care how they're presented" -=20 but we know that could cause serious confusion if more than one actor in=20 said protocol might view the same string. Do we really think that's a=20 good idea? >>>> Even strings without a mix of RTL and LTR characters can lead to=20 confusing display, e.g. if they contain digits at the start or at the=20 end. Don't remember to what extent they are excluded in IDNs. As long as Precis strings are displayed only in isolation, the=20 restrictions may not be that important, but the moment any of these=20 strings is displayed with something else, maybe with an entervening=20 punctuation, these restrictions will be very helpful, although not=20 perfect (they aren't perfect for IDNs, either). So I think the restrictions are a good thing. Regards, Martin. On 2014/04/19 11:13, Peter Saint-Andre wrote: > On 4/18/14, 4:29 PM, Pete Resnick wrote: >> On 4/15/14 7:32 PM, Peter Saint-Andre wrote: >>> On 4/14/14, 9:18 PM, Peter Saint-Andre wrote: >>>> On 4/7/14, 11:40 AM, Pete Resnick wrote: >>>> >>>>> ----- >>>>> Substantive issue: >>>>> ----- >>>>> >>>>> 4.1.5: I'm not thrilled with this section in general, but in >>>>> particular >>>>> I'm not sure what "mixed-direction strings are not supported" >>>>> means. We >>>>> do know how to process strings that contain characters with a mix o= f >>>>> directionality. Such strings are sometimes a visual challenge, but >>>>> not a >>>>> processing challenge: RFC 5893 exists because IDNs want to use "." >>>>> as a >>>>> label separator yet have text display work in a context that is >>>>> unaware >>>>> of labels. Neither using 5893 nor considering any RTL character mak= ing >>>>> the whole string RTL is a good recommendation for most cases. Not s= ure >>>>> what to do about this. >>>> >>>> See: >>>> >>>> http://www.ietf.org/mail-archive/web/precis/current/msg00553.html >> >> ...wherein Martin seems to say that this is only allowing fully RTL an= d >> fully LTR (i.e., no mixed direction strings). >> >>>> http://www.ietf.org/mail-archive/web/precis/current/msg00557.html >> >> ...wherein you reply that not allowing mixed direction strings was >> intended. :-( >> >>>> I am not sure how helpful it is to distinguish between processing >>>> challenges and presentation challenges. >> >> There are scant few processing challenges, at least from my >> long-ago-in-a-galaxy-far-far-away memory of the last time I wrote any >> code in this area. They are all (again, as far as I remember) >> presentation challenges. >> >>>> I will ponder this further and reply again. >>> >>> I recall discussion at one of our in-person meetings about bidi. As I >>> recall, John Klensin sagaciously pointed out that if the PRECIS WG >>> tried to define a new rule for directionality we would almost >>> certainly get it wrong, and that it was better to use the Bidi Rule >>> from RFC 5893 than to design something new. Even though it might be >>> true that the Bidi Rule might not be a good recommendation for most >>> cases, I do not have confidence in our ability to come up with a >>> better recommendation. >> >> On that we can agree. I am sure I do not want to come up with other >> rules for inclusion (because those rules are completely dependent on t= he >> presentation challenges you are or are not willing to contend with). I >> guess in the end I'd just like the text in 4.1.5 softened to say, "You >> can have a directionality rule for your profile anything from 'whateve= r >> mix of RTL and LTR characters you like' if you don't care how they're >> presented, all the way to the complicated Bidi Rule from 5893 if you >> expect users to be typing in protocol elements, and you have to deal >> with strings with separator punctuation and presentation tools that >> don't know about them." >> >>> Would you say that the Bidi Rule works for domain names because "." i= s >>> a label separator? In particular, my understanding of the Bidi Rule i= s >>> that it doesn't allow mixed-direction *labels*, although it does allo= w >>> mixed-direction domain names (where the direction changes at the poin= t >>> of the label separator). >> >> Correct. The *only* reason for the 5893 Bidi Rule is because they want= ed >> domain names to display identically in both LTR and RTL contexts when >> the display engine didn't understand that the "." was a label separato= r. >> (Well, I guess that's two reasons combined in one.) >> >>> It seems to me that not supporting mixed-direction strings in PRECIS >>> is consistent with RFC 5893. >> >> It is consistent with 5893, but I am saying that there are a number of >> cases where it's the wrong thing to do. There are protocols that >> shouldn't care whether that strings display inconsistently when the us= er >> changes from RTL to LTR contexts. What's the problem if I want my hand= le >> to be: >> >> pee e tee e dash pei samekh het >> >> which if I type them in that order gets you: >> >> Pete-=D7=A4=D7=A1=D7=97 >> >> which in a LTR context will display to you as (reading them off from >> left to right): >> >> pee e tee e dash het samekh pei >> >> or in an RTL context will display to you as (reading them off from lef= t >> to right): >> >> het samekh pei dash pee e tee e >> >> The only problem is if you are worried that people will type them in >> wrong because they don't know what directional context they're in. If >> it's just my handle name and I'm the only one typing it, you should >> leave me be. >> >>> I realize that's not ideal, but it might be the best that *we* can do >>> *now*. Whether some other group could do something better in the >>> future might be irrelevant. >> >> Like I said, I'm not looking for a new rule. Just less overt pushing >> that protocols never allow mixed direction text and that they should >> lean toward 5893. > > I'm still worried about foot-guns. Part of what we've tried to do in > PREICS is to actively prevent people who don't necessarily know much > about internationalization from shooting themselves in the foot. Yes, w= e > could tell those folks "it's fine to allow whatever mix of RTL and LTR > characters you like, as long as you don't care how they're presented" - > but we know that could cause serious confusion if more than one actor i= n > said protocol might view the same string. Do we really think that's a > good idea? > > Peter > > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis From nobody Mon Apr 21 10:45:07 2014 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 8C61E1A022B for ; Mon, 21 Apr 2014 10:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, 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 EmBOj3D6P0NW for ; Mon, 21 Apr 2014 10:45:03 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D1CB21A01FA for ; Mon, 21 Apr 2014 10:45:03 -0700 (PDT) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0BB314032A; Mon, 21 Apr 2014 11:44:57 -0600 (MDT) Message-ID: <5355591B.4070903@stpeter.im> Date: Mon, 21 Apr 2014 11:44:59 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , Pete Resnick References: <5342E30B.4090700@qti.qualcomm.com> <534CA4EC.8050702@stpeter.im> <534DCF9A.3050102@stpeter.im> <5351A735.5090802@qti.qualcomm.com> <5351DBC9.20405@stpeter.im> <5354FD24.6060003@it.aoyama.ac.jp> In-Reply-To: <5354FD24.6060003@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/lx2n-Tw4xbgrdR9dvUvSZCep6R0 Cc: precis@ietf.org Subject: Re: [precis] AD Evaluation of draft-ietf-precis-framework-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: Mon, 21 Apr 2014 17:45:05 -0000 On 4/21/14, 5:12 AM, "Martin J. Dürst" wrote: > [Sorry for the top-posting, but it's way easier for those who want to > see just the next bit of the argument.] > > On 2014/04/19 11:13, Peter Saint-Andre wrote: > > >>>> > I'm still worried about foot-guns. Part of what we've tried to do in > PREICS is to actively prevent people who don't necessarily know much > about internationalization from shooting themselves in the foot. Yes, we > could tell those folks "it's fine to allow whatever mix of RTL and LTR > characters you like, as long as you don't care how they're presented" - > but we know that could cause serious confusion if more than one actor in > said protocol might view the same string. Do we really think that's a > good idea? > >>>> > > Even strings without a mix of RTL and LTR characters can lead to > confusing display, e.g. if they contain digits at the start or at the > end. Don't remember to what extent they are excluded in IDNs. > > As long as Precis strings are displayed only in isolation, the > restrictions may not be that important, but the moment any of these > strings is displayed with something else, maybe with an entervening > punctuation, these restrictions will be very helpful, although not > perfect (they aren't perfect for IDNs, either). > > So I think the restrictions are a good thing. I still agree. Looking back at the text, I think Pete might have a point. I suggest the following change. ### OLD The directionality rule of a profile specifies which strings are to be considered left-to-right (LTR) and right-to-left (RTL), and the allowable sequences of characters in LTR and RTL strings (see Unicode Standard Annex #9 [UAX9]); note that mixed-direction strings are not supported, since there is currently no widely accepted and implemented solution for the processing and display of mixed- direction 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]. NEW The directionality rule of a profile specifies which strings are to be considered left-to-right (LTR) and right-to-left (RTL), and the allowable sequences of characters in LTR and RTL strings (see Unicode Standard Annex #9 [UAX9]). 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]. Mixed-direction strings are not directly supported by the PRECIS framework itself, since there is currently no widely accepted and implemented solution for the processing and safe display of mixed- direction strings. An application protocol that uses the PRECIS framework (or an extension to the framework) could define methods for handling mixed-direction strings; however, such methods are outside the scope of the framework. ### Peter From nobody Mon Apr 21 15:54:08 2014 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 2011B1A02DC; Mon, 21 Apr 2014 15:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, 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 xXM9ypY5q6zL; Mon, 21 Apr 2014 15:54:05 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 94BEE1A02D1; Mon, 21 Apr 2014 15:54:05 -0700 (PDT) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CA8024032A; Mon, 21 Apr 2014 16:53:57 -0600 (MDT) Message-ID: <5355A184.5030808@stpeter.im> Date: Mon, 21 Apr 2014 16:53:56 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Alissa Cooper , The IESG References: <20140421223821.25181.56312.idtracker@ietfa.amsl.com> In-Reply-To: <20140421223821.25181.56312.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/DUFMboiB5RPlHUKjtQOnAyl4G3I Cc: precis-chairs@tools.ietf.org, draft-ietf-precis-framework@tools.ietf.org, precis@ietf.org Subject: Re: [precis] Alissa Cooper's No Objection on draft-ietf-precis-framework-15: (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: Mon, 21 Apr 2014 22:54:07 -0000 On 4/21/14, 4:38 PM, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-precis-framework-15: 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: > ---------------------------------------------------------------------- > > Nice work. I have one comment in Section 4.3, which says: > > One consequence of disallowing space characters in the > IdentifierClass might be to effectively discourage the use of ASCII > space (or, even more problematically, non-ASCII space characters) > within identifiers created in newer application protocols; given the > challenges involved in properly handling space characters in > identifiers and other protocol strings, the Working Group considered > this to be a feature, not a bug. > > I find the use of the phrase “even more problematically” confusing given > that it comes after “to effectively discourage.” I think the intended > meaning here is that if non-ASCII space characters were to be used (or > _encouraged_), that would be even more problematic than if ASCII space > characters were to be used (or encouraged), right? I would suggest the > following edit to the first part of the first sentence: > > One consequence of disallowing space characters in the > IdentifierClass might be to effectively discourage the use of ASCII > space (or the even more problematic non-ASCII space characters) > within identifiers created in newer application protocols; Good point. I think this might be even clearer: One consequence of disallowing space characters in the IdentifierClass might be to effectively discourage their use within identifiers created in newer application protocols; given the challenges involved in properly handling space characters (especially non-ASCII space characters) in identifiers and other protocol strings, the Working Group considered this to be a feature, not a bug. Peter From nobody Mon Apr 21 16:07:14 2014 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 5194B1A02D1; Mon, 21 Apr 2014 16:07:09 -0700 (PDT) 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 ZzDykQBUVydP; Mon, 21 Apr 2014 16:07:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC111A02F4; Mon, 21 Apr 2014 16:07:02 -0700 (PDT) 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.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140421230702.7749.66602.idtracker@ietfa.amsl.com> Date: Mon, 21 Apr 2014 16:07:02 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/precis/rrg3BEYXbXlhBRN6caJ-LOLIj7s Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-framework-16.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, 21 Apr 2014 23:07:09 -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 and Comparison of Internationalized Strings in Application Protocols Authors : Peter Saint-Andre Marc Blanchet Filename : draft-ietf-precis-framework-16.txt Pages : 65 Date : 2014-04-21 Abstract: 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. 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-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-framework-16 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 Mon Apr 21 16:07:16 2014 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 AF1A21A02D1 for ; Mon, 21 Apr 2014 16:07:10 -0700 (PDT) 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 MR6WufuijzBS; Mon, 21 Apr 2014 16:07:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC1F51A02FE; Mon, 21 Apr 2014 16:07:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: precis-chairs@tools.ietf.org, draft-ietf-precis-framework@tools.ietf.org, precis@ietf.org, presnick@qti.qualcomm.com X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140421230702.7749.72631.idtracker@ietfa.amsl.com> Date: Mon, 21 Apr 2014 16:07:02 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/precis/-z2g9Me7Ya7YP09PkgJAq89RqwY Subject: [precis] New Version Notification - draft-ietf-precis-framework-16.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, 21 Apr 2014 23:07:10 -0000 A new version (-16) has been submitted for draft-ietf-precis-framework: http://www.ietf.org/internet-drafts/draft-ietf-precis-framework-16.txt 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-16 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 Mon Apr 21 16:22:32 2014 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 672371A0303 for ; Mon, 21 Apr 2014 16:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, 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 vnQuW6JPk99m for ; Mon, 21 Apr 2014 16:22:29 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE731A029A for ; Mon, 21 Apr 2014 16:22:29 -0700 (PDT) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 230F64032A; Mon, 21 Apr 2014 17:22:23 -0600 (MDT) Message-ID: <5355A82E.9010304@stpeter.im> Date: Mon, 21 Apr 2014 17:22:22 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: precis@ietf.org, presnick@qti.qualcomm.com References: <20140421230702.7749.72631.idtracker@ietfa.amsl.com> In-Reply-To: <20140421230702.7749.72631.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/em4FUAdMkTEWIm9Z_HIkbjNMUZY Subject: Re: [precis] New Version Notification - draft-ietf-precis-framework-16.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, 21 Apr 2014 23:22:30 -0000 A few changes to address SecDir and AD review feedback. On 4/21/14, 5:07 PM, internet-drafts@ietf.org wrote: > > A new version (-16) has been submitted for draft-ietf-precis-framework: > http://www.ietf.org/internet-drafts/draft-ietf-precis-framework-16.txt > > > 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-16 > > 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. > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis > From nobody Mon Apr 21 16:45:12 2014 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 838031A0326 for ; Mon, 21 Apr 2014 16:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, 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 iqIr-3SVZOdx for ; Mon, 21 Apr 2014 16:45:06 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 595691A031F for ; Mon, 21 Apr 2014 16:45:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1398123901; x=1429659901; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=VsxHHOiPRIx0zgLlpUTAvrhxlzcg3zFVBXPcaV2EaH0=; b=mbAuKQVmTcOWkRrAVq3TL8lI6VZeTNIoSbaDPFW6ZOJzImgyGLFNCZ9D zshgiVsM+S2ouzFdX/yR0pNS3a8KcgZrifbUamzpT/2gKAAG80e6LLtch BOFf0YWEypa5enX3NlpZrjWNW/ddB0Iwwg2DZ9merHr9QN30ypFcthtKP E=; X-IronPort-AV: E=McAfee;i="5400,1158,7415"; a="62413466" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth02.qualcomm.com with ESMTP; 21 Apr 2014 16:45:00 -0700 X-IronPort-AV: E=Sophos;i="4.97,898,1389772800"; d="scan'208";a="665659886" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 21 Apr 2014 16:45:00 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 21 Apr 2014 16:45:00 -0700 Message-ID: <5355AD7B.5090709@qti.qualcomm.com> Date: Mon, 21 Apr 2014 18:44:59 -0500 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 References: <5342E30B.4090700@qti.qualcomm.com> <534CA4EC.8050702@stpeter.im> <534DCF9A.3050102@stpeter.im> <5351A735.5090802@qti.qualcomm.com> <5351DBC9.20405@stpeter.im> <5354FD24.6060003@it.aoyama.ac.jp> <5355591B.4070903@stpeter.im> In-Reply-To: <5355591B.4070903@stpeter.im> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/precis/NcmVxnPShoCzlrzLSKj_Q9n9FRQ Cc: precis@ietf.org Subject: Re: [precis] AD Evaluation of draft-ietf-precis-framework-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: Mon, 21 Apr 2014 23:45:09 -0000 On 4/21/14 12:44 PM, Peter Saint-Andre wrote: > On 4/21/14, 5:12 AM, "Martin J. Drst" wrote: >> On 2014/04/19 11:13, Peter Saint-Andre wrote: >> >>> I'm still worried about foot-guns. Yeah, I think the foot-gun argument is always the trump card. So I will relent on asking for any significant change. >> Even strings without a mix of RTL and LTR characters can lead to >> confusing display, e.g. if they contain digits at the start or at the >> end. Don't remember to what extent they are excluded in IDNs. IDN Labels can't begin with a number. LTR labels can't have any RTL numbers. So the only strange case is RTL strings, which can end with number, but the rest of the rules make bad behavior pretty hard. >> As long as Precis strings are displayed only in isolation, the >> restrictions may not be that important, but the moment any of these >> strings is displayed with something else, maybe with an entervening >> punctuation, these restrictions will be very helpful, although not >> perfect (they aren't perfect for IDNs, either). >> >> So I think the restrictions are a good thing. > > I still agree. I'm convinced on the restrictions. On the text: > NEW > The directionality rule of a profile specifies which strings are to > be considered left-to-right (LTR) and right-to-left (RTL), and the > allowable sequences of characters in LTR and RTL strings (see Unicode > Standard Annex #9 [UAX9]). This is the part I'm still having trouble with. An "LTR string" and an "RTL string" are not defined entities in Annex 9; AFAICT, are entirely 5893 inventions, and 5893 only talks in terms of "labels", not "strings". How about this: 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. The rest of this is fine: > 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]. > > Mixed-direction strings are not directly supported by the PRECIS > framework itself, since there is currently no widely accepted and > implemented solution for the processing and safe display of mixed- > direction strings. An application protocol that uses the PRECIS > framework (or an extension to the framework) could define methods for > handling mixed-direction strings; however, such methods are outside > the scope of the framework. s/the framework/this framework ? pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Mon Apr 21 16:47:50 2014 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 4076C1A031A for ; Mon, 21 Apr 2014 16:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.273 X-Spam-Level: X-Spam-Status: No, score=-4.273 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, RP_MATCHES_RCVD=-0.272, 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 Hp8xMgkQWS8C for ; Mon, 21 Apr 2014 16:47:48 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 35F761A0323 for ; Mon, 21 Apr 2014 16:47:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1398124063; x=1429660063; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=DHA9pIa11nRK42RctjbIksP2D+iGhAQnlDgOk2ycxQc=; b=R9u5KjCMT2ZJCmjqRSw50EVJ23qrK6oEKh+vEFRzcqES2keJ2/8PfbrR AcbcPiqVTEfamgWrRtBVsw2pEH+YiC5b2/EVfUIHDy7GqqGg8jQn2ViS4 VZSSnh+n535Wp2S+Syunll+Q5BYkTOkVjsInIQ+k60F26BLOurMMo6Ol8 4=; X-IronPort-AV: E=McAfee;i="5400,1158,7415"; a="62305511" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP; 21 Apr 2014 16:47:43 -0700 X-IronPort-AV: E=Sophos;i="4.97,898,1389772800"; d="scan'208";a="665660939" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 21 Apr 2014 16:47:42 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 21 Apr 2014 16:47:42 -0700 Message-ID: <5355AE1D.8020702@qti.qualcomm.com> Date: Mon, 21 Apr 2014 18:47:41 -0500 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 References: <20140421230702.7749.72631.idtracker@ietfa.amsl.com> <5355A82E.9010304@stpeter.im> In-Reply-To: <5355A82E.9010304@stpeter.im> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/precis/sLOZVlzNBFBXwvVgEvXinZkiJio Cc: precis@ietf.org Subject: Re: [precis] New Version Notification - draft-ietf-precis-framework-16.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, 21 Apr 2014 23:47:49 -0000 On 4/21/14 6:22 PM, Peter Saint-Andre wrote: > A few changes to address SecDir and AD review feedback. Typo in 9.2: OLD Base Class: IdentifierClass. Description: A sequence of letters, numbers, and symbols that is used to identify or address a network entity. Specification: Section 3.3 of this document. NEW Base Class: IdentifierClass. Description: A sequence of letters, numbers, and symbols that is used to identify or address a network entity. Specification: Section 3.2 of this document. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Mon Apr 21 17:10:18 2014 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 A2D0F1A0321 for ; Mon, 21 Apr 2014 17:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.174 X-Spam-Level: X-Spam-Status: No, score=-4.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, 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 2TUGSWDSnXdc for ; Mon, 21 Apr 2014 17:10:09 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BD2411A031F for ; Mon, 21 Apr 2014 17:09:54 -0700 (PDT) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8D5E34032A; Mon, 21 Apr 2014 18:09:49 -0600 (MDT) Message-ID: <5355B34C.7000301@stpeter.im> Date: Mon, 21 Apr 2014 18:09:48 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Pete Resnick References: <20140421230702.7749.72631.idtracker@ietfa.amsl.com> <5355A82E.9010304@stpeter.im> <5355AE1D.8020702@qti.qualcomm.com> In-Reply-To: <5355AE1D.8020702@qti.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/c1rTwWaTBGn4EG9Tg53GEHV4pEE Cc: precis@ietf.org Subject: Re: [precis] New Version Notification - draft-ietf-precis-framework-16.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: Tue, 22 Apr 2014 00:10:12 -0000 On 4/21/14, 5:47 PM, Pete Resnick wrote: > On 4/21/14 6:22 PM, Peter Saint-Andre wrote: >> A few changes to address SecDir and AD review feedback. > > Typo in 9.2: > > OLD > Base Class: IdentifierClass. > Description: A sequence of letters, numbers, and symbols that is > used to identify or address a network entity. > Specification: Section 3.3 of this document. > > NEW > Base Class: IdentifierClass. > Description: A sequence of letters, numbers, and symbols that is > used to identify or address a network entity. > Specification: Section 3.2 of this document. Copy, meet paste. :-) Will fix. Peter From nobody Mon Apr 21 17:40:23 2014 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 E64031A00C2 for ; Mon, 21 Apr 2014 17:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, 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 OC83gYoUBae9 for ; Mon, 21 Apr 2014 17:40:18 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8EC1A00BD for ; Mon, 21 Apr 2014 17:40:18 -0700 (PDT) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 818BA4032A; Mon, 21 Apr 2014 18:40:12 -0600 (MDT) Message-ID: <5355BA6B.70601@stpeter.im> Date: Mon, 21 Apr 2014 18:40:11 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Pete Resnick References: <5342E30B.4090700@qti.qualcomm.com> <534CA4EC.8050702@stpeter.im> <534DCF9A.3050102@stpeter.im> <5351A735.5090802@qti.qualcomm.com> <5351DBC9.20405@stpeter.im> <5354FD24.6060003@it.aoyama.ac.jp> <5355591B.4070903@stpeter.im> <5355AD7B.5090709@qti.qualcomm.com> In-Reply-To: <5355AD7B.5090709@qti.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/2uKW6haBmGgQmJKJHp2U1kkjf88 Cc: precis@ietf.org Subject: Re: [precis] AD Evaluation of draft-ietf-precis-framework-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: Tue, 22 Apr 2014 00:40:20 -0000 On 4/21/14, 5:44 PM, Pete Resnick wrote: > On 4/21/14 12:44 PM, Peter Saint-Andre wrote: >> On 4/21/14, 5:12 AM, "Martin J. Drst" wrote: >>> On 2014/04/19 11:13, Peter Saint-Andre wrote: >>> >>>> I'm still worried about foot-guns. > > Yeah, I think the foot-gun argument is always the trump card. So I will > relent on asking for any significant change. > >>> Even strings without a mix of RTL and LTR characters can lead to >>> confusing display, e.g. if they contain digits at the start or at the >>> end. Don't remember to what extent they are excluded in IDNs. > > IDN Labels can't begin with a number. LTR labels can't have any RTL > numbers. So the only strange case is RTL strings, which can end with > number, but the rest of the rules make bad behavior pretty hard. > >>> As long as Precis strings are displayed only in isolation, the >>> restrictions may not be that important, but the moment any of these >>> strings is displayed with something else, maybe with an entervening >>> punctuation, these restrictions will be very helpful, although not >>> perfect (they aren't perfect for IDNs, either). >>> >>> So I think the restrictions are a good thing. >> >> I still agree. > > I'm convinced on the restrictions. On the text: > >> NEW >> The directionality rule of a profile specifies which strings are to >> be considered left-to-right (LTR) and right-to-left (RTL), and the >> allowable sequences of characters in LTR and RTL strings (see Unicode >> Standard Annex #9 [UAX9]). > > This is the part I'm still having trouble with. An "LTR string" and an > "RTL string" are not defined entities in Annex 9; AFAICT, are entirely > 5893 inventions, and 5893 only talks in terms of "labels", not > "strings". Good catch! > How about this: > > 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. Yes, that's better. > The rest of this is fine: > >> 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]. >> >> Mixed-direction strings are not directly supported by the PRECIS >> framework itself, since there is currently no widely accepted and >> implemented solution for the processing and safe display of mixed- >> direction strings. An application protocol that uses the PRECIS >> framework (or an extension to the framework) could define methods for >> handling mixed-direction strings; however, such methods are outside >> the scope of the framework. > > s/the framework/this framework ? +1 Peter From nobody Tue Apr 22 00:55:32 2014 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 EEC421A013B for ; Tue, 22 Apr 2014 00:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.063 X-Spam-Level: X-Spam-Status: No, score=-0.063 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272] 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 K4LOiAkVpiv3 for ; Tue, 22 Apr 2014 00:55:28 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 548461A0125 for ; Tue, 22 Apr 2014 00:55:28 -0700 (PDT) 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 291C032E56D; Tue, 22 Apr 2014 16:55:21 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 181c_64bb_364191c2_6ff0_43ca_8411_fdce9c1aba70; Tue, 22 Apr 2014 16:55:21 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 7C649BF4A0; Tue, 22 Apr 2014 16:55:20 +0900 (JST) Message-ID: <5356205C.2080804@it.aoyama.ac.jp> Date: Tue, 22 Apr 2014 16:55:08 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Peter Saint-Andre , Pete Resnick References: <5342E30B.4090700@qti.qualcomm.com> <534CA4EC.8050702@stpeter.im> <534DCF9A.3050102@stpeter.im> <5351A735.5090802@qti.qualcomm.com> <5351DBC9.20405@stpeter.im> <5354FD24.6060003@it.aoyama.ac.jp> <5355591B.4070903@stpeter.im> In-Reply-To: <5355591B.4070903@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/74Qa0Mc1_vL6tz6kvfxOiMLFREM Cc: precis@ietf.org Subject: Re: [precis] AD Evaluation of draft-ietf-precis-framework-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: Tue, 22 Apr 2014 07:55:30 -0000 Hello Peter/Pete/others, On 2014/04/22 02:44, Peter Saint-Andre wrote: > Looking back at the text, I think Pete might have a point. I suggest the > following change. > > ### > > OLD > The directionality rule of a profile specifies which strings are to > be considered left-to-right (LTR) and right-to-left (RTL), and the > allowable sequences of characters in LTR and RTL strings (see Unicode > Standard Annex #9 [UAX9]); note that mixed-direction strings are not > supported, since there is currently no widely accepted and > implemented solution for the processing and display of mixed- > direction 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]. > > NEW > The directionality rule of a profile specifies which strings are to > be considered left-to-right (LTR) and right-to-left (RTL), and the > allowable sequences of characters in LTR and RTL strings (see Unicode > Standard Annex #9 [UAX9]). 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]. > > Mixed-direction strings are not directly supported by the PRECIS > framework itself, since there is currently no widely accepted and > implemented solution for the processing and safe display of mixed- Please remove "processing". Processing mixed-direction strings isn't a problem at all. Display is the problem. > direction strings. An application protocol that uses the PRECIS > framework (or an extension to the framework) could define methods for > handling mixed-direction strings; however, such methods are outside > the scope of the framework. I'm not sure "handling" and "methods" are the right word, unless these words are used in other parts of the text. They sound a bit too procedural for simple restrictions. In theory, it's possible to define new ways of displaying things, but good luck for getting these deployed :-(. I'd prefer if the text here ended with some clear caution. Maybe something like changing the last part of the last sentence to "however, such methods are outside the scope of the framework and should only be introduced after carefully studying bidirectional display problems." Regards, Martin. > ### > > Peter > > From nobody Tue Apr 22 05:04:35 2014 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 986A61A03EC; Tue, 22 Apr 2014 05:04:30 -0700 (PDT) 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 L92JG-M1K6Re; Tue, 22 Apr 2014 05:04:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD0F1A03EF; Tue, 22 Apr 2014 05:04:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Adrian Farrel" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140422120424.6082.65586.idtracker@ietfa.amsl.com> Date: Tue, 22 Apr 2014 05:04:24 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/precis/lKeF6tBTd8LITqCiYxsJEWiRx_0 Cc: precis-chairs@tools.ietf.org, draft-ietf-precis-framework@tools.ietf.org, precis@ietf.org Subject: [precis] Adrian Farrel's No Objection on draft-ietf-precis-framework-16: (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, 22 Apr 2014 12:04:31 -0000 Adrian Farrel has entered the following ballot position for draft-ietf-precis-framework-16: 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: ---------------------------------------------------------------------- Not my area of expertise, but ... :-) Why isn't BCP18 an important reference? From nobody Tue Apr 22 08:19:52 2014 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 58C891A04E8; Tue, 22 Apr 2014 08:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, 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 XmugSMcHrRuJ; Tue, 22 Apr 2014 08:19:44 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1CED11A04C8; Tue, 22 Apr 2014 08:19:43 -0700 (PDT) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CD7314032A; Tue, 22 Apr 2014 09:19:37 -0600 (MDT) Message-ID: <53568888.3050701@stpeter.im> Date: Tue, 22 Apr 2014 09:19:36 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Adrian Farrel , The IESG References: <20140422120424.6082.65586.idtracker@ietfa.amsl.com> In-Reply-To: <20140422120424.6082.65586.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/2q5cV9qrschRcYIadpEBz7n5Pmw Cc: precis-chairs@tools.ietf.org, draft-ietf-precis-framework@tools.ietf.org, precis@ietf.org Subject: Re: [precis] Adrian Farrel's No Objection on draft-ietf-precis-framework-16: (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: Tue, 22 Apr 2014 15:19:48 -0000 On 4/22/14, 6:04 AM, Adrian Farrel wrote: > Adrian Farrel has entered the following ballot position for > draft-ietf-precis-framework-16: 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: > ---------------------------------------------------------------------- > > Not my area of expertise, but ... :-) > > Why isn't BCP18 an important reference? Probably because, roughly speaking, BCP18 is to i18n as BCP61 is to security. Plus much of BCP18 has been superseded by RFCs 3629, 4646, 5198, 6365, etc. Peter From nobody Tue Apr 22 08:30:17 2014 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 7E4D61A0662 for ; Tue, 22 Apr 2014 08:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, 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 fRqbUTN-cDAx for ; Tue, 22 Apr 2014 08:30:14 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D9BD91A065E for ; Tue, 22 Apr 2014 08:30:11 -0700 (PDT) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F31FC4032A; Tue, 22 Apr 2014 09:30:05 -0600 (MDT) Message-ID: <53568AFC.2020703@stpeter.im> Date: Tue, 22 Apr 2014 09:30:04 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , Pete Resnick References: <5342E30B.4090700@qti.qualcomm.com> <534CA4EC.8050702@stpeter.im> <534DCF9A.3050102@stpeter.im> <5351A735.5090802@qti.qualcomm.com> <5351DBC9.20405@stpeter.im> <5354FD24.6060003@it.aoyama.ac.jp> <5355591B.4070903@stpeter.im> <5356205C.2080804@it.aoyama.ac.jp> In-Reply-To: <5356205C.2080804@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/cwwBTEbeglSWsOMGF45jIQdEboY Cc: precis@ietf.org Subject: Re: [precis] AD Evaluation of draft-ietf-precis-framework-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: Tue, 22 Apr 2014 15:30:16 -0000 On 4/22/14, 1:55 AM, "Martin J. Dürst" wrote: > Hello Peter/Pete/others, > > On 2014/04/22 02:44, Peter Saint-Andre wrote: > >> Looking back at the text, I think Pete might have a point. I suggest the >> following change. >> >> ### >> >> OLD >> The directionality rule of a profile specifies which strings are to >> be considered left-to-right (LTR) and right-to-left (RTL), and the >> allowable sequences of characters in LTR and RTL strings (see Unicode >> Standard Annex #9 [UAX9]); note that mixed-direction strings are not >> supported, since there is currently no widely accepted and >> implemented solution for the processing and display of mixed- >> direction 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]. >> >> NEW >> The directionality rule of a profile specifies which strings are to >> be considered left-to-right (LTR) and right-to-left (RTL), and the >> allowable sequences of characters in LTR and RTL strings (see Unicode >> Standard Annex #9 [UAX9]). 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]. >> >> Mixed-direction strings are not directly supported by the PRECIS >> framework itself, since there is currently no widely accepted and >> implemented solution for the processing and safe display of mixed- > > Please remove "processing". Processing mixed-direction strings isn't a > problem at all. Display is the problem. Correct. >> direction strings. An application protocol that uses the PRECIS >> framework (or an extension to the framework) could define methods for >> handling mixed-direction strings; however, such methods are outside >> the scope of the framework. > > I'm not sure "handling" and "methods" are the right word, unless these > words are used in other parts of the text. They sound a bit too > procedural for simple restrictions. In theory, it's possible to define > new ways of displaying things, but good luck for getting these deployed > :-(. > > I'd prefer if the text here ended with some clear caution. Maybe > something like changing the last part of the last sentence to > > "however, such methods are outside the scope of the framework and should > only be introduced after carefully studying bidirectional display > problems." I originally had something like "such methods are fraught with difficulty so don't try to solve the problem unless you really know what you're doing". Adding the text you propose is fine with me. Peter From nobody Tue Apr 22 08:36:10 2014 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 3F9171A0675 for ; Tue, 22 Apr 2014 08:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, 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 qrnEsCZ9ATFP for ; Tue, 22 Apr 2014 08:36:08 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 62F431A067B for ; Tue, 22 Apr 2014 08:36:07 -0700 (PDT) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 07BCF4032A; Tue, 22 Apr 2014 09:36:01 -0600 (MDT) Message-ID: <53568C60.8000205@stpeter.im> Date: Tue, 22 Apr 2014 09:36:00 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , Pete Resnick References: <5342E30B.4090700@qti.qualcomm.com> <534CA4EC.8050702@stpeter.im> <534DCF9A.3050102@stpeter.im> <5351A735.5090802@qti.qualcomm.com> <5351DBC9.20405@stpeter.im> <5354FD24.6060003@it.aoyama.ac.jp> <5355591B.4070903@stpeter.im> <5356205C.2080804@it.aoyama.ac.jp> <53568AFC.2020703@stpeter.im> In-Reply-To: <53568AFC.2020703@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/xnm7x9CUq4s1jD3Cok6W-XZ32jc Cc: precis@ietf.org Subject: Re: [precis] AD Evaluation of draft-ietf-precis-framework-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: Tue, 22 Apr 2014 15:36:09 -0000 On 4/22/14, 9:30 AM, Peter Saint-Andre wrote: > On 4/22/14, 1:55 AM, "Martin J. Dürst" wrote: >> Hello Peter/Pete/others, >> >> On 2014/04/22 02:44, Peter Saint-Andre wrote: >> >>> Looking back at the text, I think Pete might have a point. I suggest the >>> following change. >>> >>> ### >>> >>> OLD >>> The directionality rule of a profile specifies which strings are to >>> be considered left-to-right (LTR) and right-to-left (RTL), and the >>> allowable sequences of characters in LTR and RTL strings (see >>> Unicode >>> Standard Annex #9 [UAX9]); note that mixed-direction strings are not >>> supported, since there is currently no widely accepted and >>> implemented solution for the processing and display of mixed- >>> direction 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]. >>> >>> NEW >>> The directionality rule of a profile specifies which strings are to >>> be considered left-to-right (LTR) and right-to-left (RTL), and the >>> allowable sequences of characters in LTR and RTL strings (see >>> Unicode >>> Standard Annex #9 [UAX9]). 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]. >>> >>> Mixed-direction strings are not directly supported by the PRECIS >>> framework itself, since there is currently no widely accepted and >>> implemented solution for the processing and safe display of mixed- >> >> Please remove "processing". Processing mixed-direction strings isn't a >> problem at all. Display is the problem. > > Correct. > >>> direction strings. An application protocol that uses the PRECIS >>> framework (or an extension to the framework) could define methods >>> for >>> handling mixed-direction strings; however, such methods are outside >>> the scope of the framework. >> >> I'm not sure "handling" and "methods" are the right word, unless these >> words are used in other parts of the text. They sound a bit too >> procedural for simple restrictions. In theory, it's possible to define >> new ways of displaying things, but good luck for getting these deployed >> :-(. >> >> I'd prefer if the text here ended with some clear caution. Maybe >> something like changing the last part of the last sentence to >> >> "however, such methods are outside the scope of the framework and should >> only be introduced after carefully studying bidirectional display >> problems." > > I originally had something like "such methods are fraught with > difficulty so don't try to solve the problem unless you really know what > you're doing". Adding the text you propose is fine with me. So, how is this? Mixed-direction strings are not directly supported by the PRECIS framework itself, since there is currently no widely accepted and implemented solution for the safe display of mixed-direction strings. An application protocol that uses the PRECIS framework (or an extension to the framework) could define better ways to present mixed-direction strings; however, that work is outside the scope of this framework and would likely require a great deal of careful research into the problems of displaying bidirectional text. Peter From nobody Tue Apr 22 08:40:19 2014 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 E47EE1A059F; Tue, 22 Apr 2014 08:40:13 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 D-zf2kuH2ejG; Tue, 22 Apr 2014 08:40:12 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 2301B1A0684; Tue, 22 Apr 2014 08:40:08 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3MFe2j4013500; Tue, 22 Apr 2014 16:40:02 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3MFdx7O013451 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Apr 2014 16:39:59 +0100 From: "Adrian Farrel" To: "'Peter Saint-Andre'" , "'The IESG'" References: <20140422120424.6082.65586.idtracker@ietfa.amsl.com> <53568888.3050701@stpeter.im> In-Reply-To: <53568888.3050701@stpeter.im> Date: Tue, 22 Apr 2014 16:39:59 +0100 Message-ID: <06ca01cf5e41$1fd2d630$5f788290$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJOC4s0UySDo/lRc7BHIivz+esKlAGoK4OomhMl90A= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20648.007 X-TM-AS-Result: No--11.594-10.0-31-10 X-imss-scan-details: No--11.594-10.0-31-10 X-TMASE-MatchedRID: lORh06tOiKgn2WEbWzq9rRHRbGr1ECgHC/ExpXrHizzqLnOUXH9QdAO3 d0GZBFH7kORNbrhzxInVxq28FbXD/TkSt1Y0OznF/c0+LJTMrN236GGfwjLoZZsoi2XrUn/JxbG vmM9nj5NQSFbL1bvQASAHAopEd76vhgBYGmK8BitYEIF7JlEEFlszRDpos/6sjqSswJrXKq/p0T hIAs5XFA== Archived-At: http://mailarchive.ietf.org/arch/msg/precis/MBuqej4abiBjdvLcenPdTcjo8JA Cc: precis-chairs@tools.ietf.org, draft-ietf-precis-framework@tools.ietf.org, precis@ietf.org Subject: Re: [precis] Adrian Farrel's No Objection on draft-ietf-precis-framework-16: (with COMMENT) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 15:40:14 -0000 > > Why isn't BCP18 an important reference? >=20 > Probably because, roughly speaking, BCP18 is to i18n as BCP61 is to > security. Plus much of BCP18 has been superseded by RFCs 3629, 4646, > 5198, 6365, etc. I like the idea of a BCP being superseded and still remaining as a BCP, = that is probably not helpful even if 4646 got stabbed to death by 5646. What you are saying, I think, is essentially that RFC 2277 is not = applicable to the space of "Preparation and Comparison of = Internationalized Strings in Application Protocols". So is RFC 2277 wrong, deprecated, or still applicable as written? And, = in the former two cases, is anyone doing anything about it? Cheers, Adrian From nobody Tue Apr 22 09:27:14 2014 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 2840A1A0699; Tue, 22 Apr 2014 09:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, 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 E1oih-Ebqz_c; Tue, 22 Apr 2014 09:27:08 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 060171A021F; Tue, 22 Apr 2014 09:26:55 -0700 (PDT) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7DB4E4032A; Tue, 22 Apr 2014 10:26:39 -0600 (MDT) Message-ID: <5356983E.2080500@stpeter.im> Date: Tue, 22 Apr 2014 10:26:38 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, 'The IESG' References: <20140422120424.6082.65586.idtracker@ietfa.amsl.com> <53568888.3050701@stpeter.im> <06ca01cf5e41$1fd2d630$5f788290$@olddog.co.uk> In-Reply-To: <06ca01cf5e41$1fd2d630$5f788290$@olddog.co.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/_m5wBys3BtMSAgp8Kh0Pt5hQTkk Cc: precis-chairs@tools.ietf.org, draft-ietf-precis-framework@tools.ietf.org, precis@ietf.org Subject: Re: [precis] Adrian Farrel's No Objection on draft-ietf-precis-framework-16: (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: Tue, 22 Apr 2014 16:27:10 -0000 On 4/22/14, 9:39 AM, Adrian Farrel wrote: >>> Why isn't BCP18 an important reference? >> >> Probably because, roughly speaking, BCP18 is to i18n as BCP61 is to >> security. Plus much of BCP18 has been superseded by RFCs 3629, 4646, >> 5198, 6365, etc. > > I like the idea of a BCP being superseded and still remaining as a BCP, that is probably not helpful even if 4646 got stabbed to death by 5646. > > What you are saying, I think, is essentially that RFC 2277 is not applicable to the space of "Preparation and Comparison of Internationalized Strings in Application Protocols". > > So is RFC 2277 wrong, deprecated, or still applicable as written? And, in the former two cases, is anyone doing anything about it? RFC 2277 was written long ago (1998) and far away, when very few people in the IETF paid attention to internationalization. As I see it, in large measure RFC 2277 was intended as a call to do so, and provided a few somewhat primitive guidelines regarding definitions (superseded by RFC 6365), "charsets" [sic] (superseded by RFC 3629 and RFC 5198), language tags (superseded by RFC 4646), etc. But I really don't see how those early suggestions have much to do with the advanced work we're doing on replacing stringprep. Heck, even the stringprep specification from 2002 (RFC 3545), which this I-D will supersede if it is approved, didn't reference RFC 2277. Peter From nobody Tue Apr 22 09:27:43 2014 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 6F91B1A0697; Tue, 22 Apr 2014 09:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, 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 NaDEWriCfbuF; Tue, 22 Apr 2014 09:27:37 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id F00091A068B; Tue, 22 Apr 2014 09:27:36 -0700 (PDT) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7FA624032A; Tue, 22 Apr 2014 10:27:31 -0600 (MDT) Message-ID: <53569872.6050306@stpeter.im> Date: Tue, 22 Apr 2014 10:27:30 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, 'The IESG' References: <20140422120424.6082.65586.idtracker@ietfa.amsl.com> <53568888.3050701@stpeter.im> <06ca01cf5e41$1fd2d630$5f788290$@olddog.co.uk> <5356983E.2080500@stpeter.im> In-Reply-To: <5356983E.2080500@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/QlIPybZS6bTlepG-8ox9gIXm_oY Cc: precis-chairs@tools.ietf.org, draft-ietf-precis-framework@tools.ietf.org, precis@ietf.org Subject: Re: [precis] Adrian Farrel's No Objection on draft-ietf-precis-framework-16: (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: Tue, 22 Apr 2014 16:27:38 -0000 On 4/22/14, 10:26 AM, Peter Saint-Andre wrote: > On 4/22/14, 9:39 AM, Adrian Farrel wrote: >>>> Why isn't BCP18 an important reference? >>> >>> Probably because, roughly speaking, BCP18 is to i18n as BCP61 is to >>> security. Plus much of BCP18 has been superseded by RFCs 3629, 4646, >>> 5198, 6365, etc. >> >> I like the idea of a BCP being superseded and still remaining as a >> BCP, that is probably not helpful even if 4646 got stabbed to death by >> 5646. >> >> What you are saying, I think, is essentially that RFC 2277 is not >> applicable to the space of "Preparation and Comparison of >> Internationalized Strings in Application Protocols". >> >> So is RFC 2277 wrong, deprecated, or still applicable as written? And, >> in the former two cases, is anyone doing anything about it? > > RFC 2277 was written long ago (1998) and far away, when very few people > in the IETF paid attention to internationalization. As I see it, in > large measure RFC 2277 was intended as a call to do so, and provided a > few somewhat primitive guidelines regarding definitions (superseded by > RFC 6365), "charsets" [sic] (superseded by RFC 3629 and RFC 5198), > language tags (superseded by RFC 4646), etc. But I really don't see how > those early suggestions have much to do with the advanced work we're > doing on replacing stringprep. Heck, even the stringprep specification > from 2002 (RFC 3545), which this I-D will supersede if it is approved, > didn't reference RFC 2277. Er, RFC 3454, that is. Peter From nobody Tue Apr 22 09:30:29 2014 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 193EE1A018E; Tue, 22 Apr 2014 09:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, 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 T-TWD_eKi53R; Tue, 22 Apr 2014 09:30:22 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF7F1A0215; Tue, 22 Apr 2014 09:30:22 -0700 (PDT) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0F0C04032A; Tue, 22 Apr 2014 10:30:17 -0600 (MDT) Message-ID: <53569918.6030706@stpeter.im> Date: Tue, 22 Apr 2014 10:30:16 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, 'The IESG' References: <20140422120424.6082.65586.idtracker@ietfa.amsl.com> <53568888.3050701@stpeter.im> <06ca01cf5e41$1fd2d630$5f788290$@olddog.co.uk> <5356983E.2080500@stpeter.im> <53569872.6050306@stpeter.im> In-Reply-To: <53569872.6050306@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/W34HMBnrIFRX7OKv0uV8Pp8Prt0 Cc: precis-chairs@tools.ietf.org, draft-ietf-precis-framework@tools.ietf.org, precis@ietf.org Subject: Re: [precis] Adrian Farrel's No Objection on draft-ietf-precis-framework-16: (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: Tue, 22 Apr 2014 16:30:27 -0000 On 4/22/14, 10:27 AM, Peter Saint-Andre wrote: > On 4/22/14, 10:26 AM, Peter Saint-Andre wrote: >> On 4/22/14, 9:39 AM, Adrian Farrel wrote: >>> So is RFC 2277 wrong, deprecated, or still applicable as written? And, >>> in the former two cases, is anyone doing anything about it? Oh, and the datatracker says: http://datatracker.ietf.org/doc/draft-sullivan-rfc2277-bis/ Peter From nobody Tue Apr 22 10:28:10 2014 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 AE8311A06B7; Tue, 22 Apr 2014 10:28:06 -0700 (PDT) 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 89gRJASDI7G2; Tue, 22 Apr 2014 10:28:02 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBC61A0698; Tue, 22 Apr 2014 10:28:02 -0700 (PDT) Received: from crankycanuck.ca (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 437148A031; Tue, 22 Apr 2014 17:27:55 +0000 (UTC) Date: Tue, 22 Apr 2014 13:27:52 -0400 From: Andrew Sullivan To: Peter Saint-Andre Message-ID: <20140422172752.GM16554@crankycanuck.ca> References: <20140422120424.6082.65586.idtracker@ietfa.amsl.com> <53568888.3050701@stpeter.im> <06ca01cf5e41$1fd2d630$5f788290$@olddog.co.uk> <5356983E.2080500@stpeter.im> <53569872.6050306@stpeter.im> <53569918.6030706@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53569918.6030706@stpeter.im> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/precis/Be5P2eKCtcCiC3Wm8GfjHdIsfsc Cc: adrian@olddog.co.uk, precis-chairs@tools.ietf.org, precis@ietf.org, 'The IESG' , draft-ietf-precis-framework@tools.ietf.org Subject: Re: [precis] Adrian Farrel's No Objection on draft-ietf-precis-framework-16: (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: Tue, 22 Apr 2014 17:28:06 -0000 Yes, the IAB's i18n program is working on this. Comments are solicited, BTW. A On Tue, Apr 22, 2014 at 10:30:16AM -0600, Peter Saint-Andre wrote: > On 4/22/14, 10:27 AM, Peter Saint-Andre wrote: > >On 4/22/14, 10:26 AM, Peter Saint-Andre wrote: > >>On 4/22/14, 9:39 AM, Adrian Farrel wrote: > > >>>So is RFC 2277 wrong, deprecated, or still applicable as written? And, > >>>in the former two cases, is anyone doing anything about it? > > Oh, and the datatracker says: > > http://datatracker.ietf.org/doc/draft-sullivan-rfc2277-bis/ > > Peter > > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis -- Andrew Sullivan ajs@crankycanuck.ca From nobody Tue Apr 22 18:21:01 2014 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 3F76C1A02EC; Mon, 21 Apr 2014 15:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] 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 IzGytF6ho3yx; Mon, 21 Apr 2014 15:38:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABAF1A0067; Mon, 21 Apr 2014 15:38:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Alissa Cooper" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140421223821.25181.56312.idtracker@ietfa.amsl.com> Date: Mon, 21 Apr 2014 15:38:21 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/precis/6GORJqpFAiV5tnFTM5lHVLUe0yQ X-Mailman-Approved-At: Tue, 22 Apr 2014 18:21:00 -0700 Cc: precis-chairs@tools.ietf.org, draft-ietf-precis-framework@tools.ietf.org, precis@ietf.org Subject: [precis] Alissa Cooper's No Objection on draft-ietf-precis-framework-15: (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: Mon, 21 Apr 2014 22:38:22 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-precis-framework-15: 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: ---------------------------------------------------------------------- Nice work. I have one comment in Section 4.3, which says: One consequence of disallowing space characters in the IdentifierClass might be to effectively discourage the use of ASCII space (or, even more problematically, non-ASCII space characters) within identifiers created in newer application protocols; given the challenges involved in properly handling space characters in identifiers and other protocol strings, the Working Group considered this to be a feature, not a bug. I find the use of the phrase “even more problematically” confusing given that it comes after “to effectively discourage.” I think the intended meaning here is that if non-ASCII space characters were to be used (or _encouraged_), that would be even more problematic than if ASCII space characters were to be used (or encouraged), right? I would suggest the following edit to the first part of the first sentence: One consequence of disallowing space characters in the IdentifierClass might be to effectively discourage the use of ASCII space (or the even more problematic non-ASCII space characters) within identifiers created in newer application protocols; From nobody Tue Apr 22 18:22:34 2014 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 D0F4D1A03A1; Tue, 22 Apr 2014 08:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.151 X-Spam-Level: X-Spam-Status: No, score=-3.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, MISSING_HEADERS=1.021, RP_MATCHES_RCVD=-0.272] 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 SBXjeKKIHfAf; Tue, 22 Apr 2014 08:54:01 -0700 (PDT) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) by ietfa.amsl.com (Postfix) with ESMTP id EE5131A0004; Tue, 22 Apr 2014 08:54:00 -0700 (PDT) Received: from request1.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id s3MFrts8005024; Tue, 22 Apr 2014 15:53:55 GMT Received: by request1.lax.icann.org (Postfix, from userid 48) id 9749D5601A3; Tue, 22 Apr 2014 15:53:55 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: <20140409190744.15518.43045.idtracker@ietfa.amsl.com> References: <20140409190744.15518.43045.idtracker@ietfa.amsl.com> Message-ID: Precedence: bulk X-RT-Loop-Prevention: IANA RT-Ticket: IANA #754906 Managed-BY: RT 4.0.8 (http://www.bestpractical.com/rt/) RT-Originator: pearl.liang@icann.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Tue, 22 Apr 2014 15:53:55 +0000 Archived-At: http://mailarchive.ietf.org/arch/msg/precis/BFWOYUXeQRG7jmHLYPhYCMb1QSQ X-Mailman-Approved-At: Tue, 22 Apr 2014 18:22:32 -0700 Cc: iesg@ietf.org, precis-chairs@tools.ietf.org, draft-ietf-precis-framework@tools.ietf.org, precis@ietf.org Subject: [precis] [IANA #754906] Last Call: (PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols) to Proposed Standard X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-lastcall@iana.org List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 15:54:06 -0000 (BEGIN IANA LAST CALL COMMENTS) IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-precis-framework. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. IANA's reviewer has the following comments/questions: IANA has a few questions about the IANA actions requested in this document. This document requests the creation of three registries in support of the PRECIS Framework. As far as IANA can tell, there have never been registries created for PRECIS in the past. IANA Question --> should the three registries that are requested in this document be combined into a singlee, high-level PRECIS master registry where the three new registries would reside? Is PRECIS a brand new parameter, or a new protocol of an existing one? If the former that PRECIS is a brand new parameter, what’s the exact name of the new registry? Is Preparation and Comparison of Internationalized Strings in Application Protocols? IANA understands that, upon approval of this document, there are three actions which IANA must complete. First, IANA will create a new registry called the PRECIS Derived Property Value Registry. This new registry will contain the Derived Properties for the versions of Unicode that are released after (and including) version 6.3 of Unicode. The derived property value is to be calculated in cooperation with a designated expert [RFC5226] according to the rules specified under Section 7 and Section 8 in the current document. The registry will only be created when a designated expert is made available to assist IANA in the initiation of the registry. Changes to the rules that are used to generate the table of derived property values, and thus the registry itself, are done through IETF Review as defined by RFC 5226. QUESTION: Are the authors intended to get an DE before IESG Approval? Second, IANA will create a new registry called the PRECIS Base Classes Registry. This new registry has a registration template in the document submitted for approval. Maintenance of the registry will be through RFC Required, as defined in RFC 5226. There are two initial registrations in the registry, as follows: Base Class: FreeformClass. Description: A sequence of letters, numbers, symbols, spaces, and other code points that is used for free-form strings. Specification: Section 3.3 of [ RFC-to-be ]. Base Class: IdentifierClass. Description: A sequence of letters, numbers, and symbols that is used to identify or address a network entity. Specification: Section 3.3 of [ RFC-to-be ]. Third, IANA will create a new registry called the PRECIS Profiles Registry. This new registry has a registration template in the document submitted for approval. Maintenance of the registry will be through Expert Review, as defined in RFC 5226. IANA Question -> Are there to be any initial registrations in the new PRECIS Profiles Registry? IANA understands that these three actions are the only ones that need to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. Thanks, Pearl Liang ICANN/IANA (END IANA LAST CALL COMMENTS) On Wed Apr 09 19:08:34 2014, iesg-secretary@ietf.org wrote: > > The IESG has received a request from the Preparation and Comparison of > Internationalized Strings WG (precis) to consider the following document: > - 'PRECIS Framework: Preparation and Comparison of Internationalized > Strings in Application Protocols' > as Proposed Standard > > 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 2014-04-23. 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 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. 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. > > This document makes a normative reference to RFC 20, which > predates document statuses and therefore may be a downward > reference. > > 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 Tue Apr 22 18:23:09 2014 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 243891A068F for ; Tue, 22 Apr 2014 09:07:34 -0700 (PDT) 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 vlB9_qrr8W_9; Tue, 22 Apr 2014 09:07:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E70E61A0694; Tue, 22 Apr 2014 09:07:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: precis-chairs@tools.ietf.org, draft-ietf-precis-framework@tools.ietf.org, precis@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140422160724.31737.4528.idtracker@ietfa.amsl.com> Date: Tue, 22 Apr 2014 09:07:24 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/precis/7CO9Kzj_7N-G5-KPP6_630M46IA X-Mailman-Approved-At: Tue, 22 Apr 2014 18:22:51 -0700 Subject: [precis] ID Tracker State Update Notice: 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, 22 Apr 2014 16:07:34 -0000 IANA review state changed to IANA - Not OK ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-precis-framework/ From nobody Wed Apr 23 00:07:20 2014 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 B7FE91A0088; Wed, 23 Apr 2014 00:07:14 -0700 (PDT) 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 E6kNuQz3mwBF; Wed, 23 Apr 2014 00:07:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEC01A0334; Wed, 23 Apr 2014 00:07:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: iesg@ietf.org, precis-chairs@tools.ietf.org, draft-ietf-precis-framework@tools.ietf.org, precis@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140423070705.18095.24457.idtracker@ietfa.amsl.com> Date: Wed, 23 Apr 2014 00:07:05 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/precis/J7i1mFA4I-jKdt7Quzxv9E1IeiI 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: Wed, 23 Apr 2014 07:07:14 -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 Wed Apr 23 12:10:02 2014 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 3F1E81A0422; Wed, 23 Apr 2014 12:09:58 -0700 (PDT) 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 P6UYYiBSV_tg; Wed, 23 Apr 2014 12:09:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9127F1A04CD; Wed, 23 Apr 2014 12:09:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ted Lemon" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140423190956.18764.24725.idtracker@ietfa.amsl.com> Date: Wed, 23 Apr 2014 12:09:56 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/precis/a2AFVcyewUmUd_6wfkMzrS6b1F0 Cc: precis-chairs@tools.ietf.org, draft-ietf-precis-framework@tools.ietf.org, precis@ietf.org Subject: [precis] Ted Lemon's No Objection on draft-ietf-precis-framework-16: (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: Wed, 23 Apr 2014 19:09:58 -0000 Ted Lemon has entered the following ballot position for draft-ietf-precis-framework-16: 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: ---------------------------------------------------------------------- In section 6, last paragraph, the reference to [UNICODE] would be more helpful if it said (see Chapter 4 of [UNICODE]), similar to later references in section 7. Aside from that, this is an excellent attempt to provide a basis for unraveling the gordian knot of unicode use in standards, and I look forward to seeing how it works in practice. From nobody Wed Apr 23 14:27:15 2014 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 973241A065F; Wed, 23 Apr 2014 14:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, 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 4gtVYqLMPIO1; Wed, 23 Apr 2014 14:27:10 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 370A81A06C4; Wed, 23 Apr 2014 14:27:10 -0700 (PDT) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 539AF4032A; Wed, 23 Apr 2014 15:26:56 -0600 (MDT) Message-ID: <5358301F.5010102@stpeter.im> Date: Wed, 23 Apr 2014 15:26:55 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ted Lemon , The IESG References: <20140423190956.18764.24725.idtracker@ietfa.amsl.com> In-Reply-To: <20140423190956.18764.24725.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/noiUMMg1WutheHCXPh7ZE69f08c Cc: precis-chairs@tools.ietf.org, draft-ietf-precis-framework@tools.ietf.org, precis@ietf.org Subject: Re: [precis] Ted Lemon's No Objection on draft-ietf-precis-framework-16: (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: Wed, 23 Apr 2014 21:27:11 -0000 On 4/23/14, 1:09 PM, Ted Lemon wrote: > Ted Lemon has entered the following ballot position for > draft-ietf-precis-framework-16: 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: > ---------------------------------------------------------------------- > > In section 6, last paragraph, the reference to [UNICODE] would be more > helpful if it said (see Chapter 4 of [UNICODE]), similar to later > references in section 7. Noted. > Aside from that, this is an excellent attempt to provide a basis for > unraveling the gordian knot of unicode use in standards, and I look > forward to seeing how it works in practice. Thanks! Peter From nobody Wed Apr 23 15:42:32 2014 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 76C611A070E; Wed, 23 Apr 2014 15:42:28 -0700 (PDT) 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 13dHLMLB_r6P; Wed, 23 Apr 2014 15:42:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E371A029F; Wed, 23 Apr 2014 15:42:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140423224227.12329.68404.idtracker@ietfa.amsl.com> Date: Wed, 23 Apr 2014 15:42:27 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/precis/Hl5gNuPtZ_nggbcUq298VaUN3Sw Cc: precis-chairs@tools.ietf.org, draft-ietf-precis-framework@tools.ietf.org, precis@ietf.org Subject: [precis] Barry Leiba's Discuss on draft-ietf-precis-framework-16: (with DISCUSS) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 22:42:28 -0000 Barry Leiba has entered the following ballot position for draft-ietf-precis-framework-16: Discuss 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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I will move to a strong "yes" on this, once we have some discussion of the registry defined in Section 9.1. The registry created in Section 9.1 is very odd indeed. I guess IANA is expected to assume that the format of the registry will look like the non-normative table in the appendix, but Section 9.1 doesn't say what the format of the registry will be. In general, I see that IANA has asked several questions in its review, and those questions haven't been responded to (and, unusually, the IANA review is in the IESG mailing list archive but *not* in the document history in the datatracker). They should be given a response. But the real oddity here is that the specification of the registry involves an *enormous* startup cost for the designated expert, *and* requires that the DE be appointed and start her work immediately. Normally, IANA takes the required actions as soon as the document's approval is announced, but in this case they will have to wait for the DE to be appointed and to derive the entire content of the registry. It seems to me that the right way to have handled this would have been for the working group to have engaged the appropriate experts and made the table Appendix A *be* the initial contents of the registry, rather than explicitly denouncing Appendix A and leaving it as a seemingly quite onerous startup task that will delay the IANA actions indefinitely. Why was it done this way, and what is the plan to get the registry content specified in a reasonable time? Should approval of the document wait for that content to be specified? Or are we really expecting to approve the document with the content of the registry left open? From nobody Wed Apr 23 16:48:11 2014 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 C5EEE1A0737; Wed, 23 Apr 2014 16:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.573 X-Spam-Level: X-Spam-Status: No, score=-4.573 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, RP_MATCHES_RCVD=-0.272, 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 eo7E_7UxhGFR; Wed, 23 Apr 2014 16:48:03 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 496B91A02B8; Wed, 23 Apr 2014 16:48:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1398296878; x=1429832878; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=8fhuWYNXLm6MpsP8j0A4PQ0DDp0Xv1KFwS9TbifeH5o=; b=m2kqlYv3AOLc64ArzG8pqo94nbPlBQrxlWNRIZMJQOK19TjK4hm3UEWp /7aZiCnzyveDRoARs59NrsKtRnhsAM3LphWvSgzk72MpWYXRZ7T0BAyvq JHSrjq64W/f+TUiO+J1aW8dsrgVod4/GHAGXBVHSIrEjdbzBng3rNAQQG E=; X-IronPort-AV: E=McAfee;i="5400,1158,7417"; a="30735653" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by wolverine01.qualcomm.com with ESMTP; 23 Apr 2014 16:47:58 -0700 X-IronPort-AV: E=Sophos;i="4.97,914,1389772800"; d="scan'208";a="29512140" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 23 Apr 2014 16:47:56 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Apr 2014 16:47:56 -0700 Message-ID: <5358512A.1040706@qti.qualcomm.com> Date: Wed, 23 Apr 2014 18:47:54 -0500 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: Barry Leiba References: <20140423224227.12329.68404.idtracker@ietfa.amsl.com> In-Reply-To: <20140423224227.12329.68404.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/precis/szyOsvOOLsV4cGeHrlmT3nH0Ppo Cc: precis@ietf.org, precis-chairs@tools.ietf.org, The IESG , draft-ietf-precis-framework@tools.ietf.org Subject: Re: [precis] Barry Leiba's Discuss on draft-ietf-precis-framework-16: (with DISCUSS) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 23:48:06 -0000 I do expect the authors to follow up with the IANA questions, but on the main point: I refer you to RFC 5892, section 5.1 and Appendix B: https://tools.ietf.org/html/rfc5892#section-5.1 https://tools.ietf.org/html/rfc5892#appendix-B As well as the IANA registry referred to in that document: http://www.iana.org/assignments/idna-tables-6.0.0/idna-tables-6.0.0.xhtml#idna-tables-6.0.0-properties This is pretty much identical to what IDNA did. I agree that we should probably recruit the expert (and I hope we can recruit the same expert as the one for IDNA Derived Properties), but I don't think the task will be tremendously burdensome, even though it sounds that way. The point of "don't just copy Appendix A" is to account for the possibility that the Unicode properties might be moving targets. But for the most part, it's an act of checking that the properties are "as expected". I will contact Patrik and see if he's willing. pr On 4/23/14 5:42 PM, Barry Leiba wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I will move to a strong "yes" on this, once we have some discussion of > the registry defined in Section 9.1. > > The registry created in Section 9.1 is very odd indeed. I guess IANA is > expected to assume that the format of the registry will look like the > non-normative table in the appendix, but Section 9.1 doesn't say what the > format of the registry will be. In general, I see that IANA has asked > several questions in its review, and those questions haven't been > responded to (and, unusually, the IANA review is in the IESG mailing list > archive but *not* in the document history in the datatracker). They > should be given a response. > > But the real oddity here is that the specification of the registry > involves an *enormous* startup cost for the designated expert, *and* > requires that the DE be appointed and start her work immediately. > Normally, IANA takes the required actions as soon as the document's > approval is announced, but in this case they will have to wait for the DE > to be appointed and to derive the entire content of the registry. > > It seems to me that the right way to have handled this would have been > for the working group to have engaged the appropriate experts and made > the table Appendix A *be* the initial contents of the registry, rather > than explicitly denouncing Appendix A and leaving it as a seemingly quite > onerous startup task that will delay the IANA actions indefinitely. > > Why was it done this way, and what is the plan to get the registry > content specified in a reasonable time? Should approval of the document > wait for that content to be specified? Or are we really expecting to > approve the document with the content of the registry left open? > > > > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis > -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Wed Apr 23 17:27:11 2014 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 070C01A076F; Wed, 23 Apr 2014 17:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, 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 e7bnx0xjdWP7; Wed, 23 Apr 2014 17:27:05 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 977711A0771; Wed, 23 Apr 2014 17:27:05 -0700 (PDT) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id EC5554032A; Wed, 23 Apr 2014 18:26:52 -0600 (MDT) Message-ID: <53585A4B.4060800@stpeter.im> Date: Wed, 23 Apr 2014 18:26:51 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Pete Resnick , Barry Leiba References: <20140423224227.12329.68404.idtracker@ietfa.amsl.com> <5358512A.1040706@qti.qualcomm.com> In-Reply-To: <5358512A.1040706@qti.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/ZAFwcU_gDuIaAJ_wCo5DXcCMrpw Cc: precis@ietf.org, precis-chairs@tools.ietf.org, The IESG , draft-ietf-precis-framework@tools.ietf.org Subject: Re: [precis] Barry Leiba's Discuss on draft-ietf-precis-framework-16: (with DISCUSS) 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, 24 Apr 2014 00:27:07 -0000 On 4/23/14, 5:47 PM, Pete Resnick wrote: > I do expect the authors to follow up with the IANA questions, Will do this evening. > but on the > main point: > > I refer you to RFC 5892, section 5.1 and Appendix B: > > https://tools.ietf.org/html/rfc5892#section-5.1 > https://tools.ietf.org/html/rfc5892#appendix-B > > As well as the IANA registry referred to in that document: > > http://www.iana.org/assignments/idna-tables-6.0.0/idna-tables-6.0.0.xhtml#idna-tables-6.0.0-properties > > > This is pretty much identical to what IDNA did. I agree that we should > probably recruit the expert (and I hope we can recruit the same expert > as the one for IDNA Derived Properties), but I don't think the task will > be tremendously burdensome, even though it sounds that way. The point of > "don't just copy Appendix A" is to account for the possibility that the > Unicode properties might be moving targets. But for the most part, it's > an act of checking that the properties are "as expected". Yes. And we had some discussion about that on the WG list: http://www.ietf.org/mail-archive/web/precis/current/msg00605.html http://www.ietf.org/mail-archive/web/precis/current/msg00606.html Peter From nobody Wed Apr 23 17:38:13 2014 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 CE72A1A044D; Wed, 23 Apr 2014 17:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.174 X-Spam-Level: X-Spam-Status: No, score=-4.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, 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 wg-cOkxjauXc; Wed, 23 Apr 2014 17:38:07 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B57F91A02B2; Wed, 23 Apr 2014 17:38:07 -0700 (PDT) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 903014032A; Wed, 23 Apr 2014 18:37:56 -0600 (MDT) Message-ID: <53585CE3.2030506@stpeter.im> Date: Wed, 23 Apr 2014 18:37:55 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: drafts-lastcall@iana.org References: <20140409190744.15518.43045.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/5If_WeZKT2qkaKRExhCxf9nDajg Cc: iesg@ietf.org, precis-chairs@tools.ietf.org, draft-ietf-precis-framework@tools.ietf.org, precis@ietf.org Subject: Re: [precis] [IANA #754906] Last Call: (PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols) to Proposed Standard 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, 24 Apr 2014 00:38:10 -0000 On 4/22/14, 9:53 AM, Pearl Liang via RT wrote: > (BEGIN IANA LAST CALL COMMENTS) > > IESG/Authors/WG Chairs: > > IANA has reviewed draft-ietf-precis-framework. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. > > IANA's reviewer has the following comments/questions: > > IANA has a few questions about the IANA actions requested in this document. > > This document requests the creation of three registries in support of the PRECIS Framework. As far as IANA can tell, there have never been registries created for PRECIS in the past. Correct. > IANA Question --> should the three registries that are requested in this document be combined into a singlee, high-level PRECIS master registry where the three new registries would reside? That seems reasonable. These PRECIS registries are very similar to the IDNA registries: http://www.iana.org/assignments/idna-tables-6.3.0/idna-tables-6.3.0.xhtml As much as possible, I would respectfully suggest that we follow the same practices here as for the IDNA registries. > Is PRECIS a brand new parameter, or a new protocol of an existing one? PRECIS is a brand new protocol, similar to IDNA but applying more generally. > If the former that PRECIS is a brand new parameter, what’s the exact name of the new registry? Is Preparation and Comparison of Internationalized Strings in Application Protocols? That seems good to me. > IANA understands that, upon approval of this document, there are three actions which IANA must complete. > > First, IANA will create a new registry called the PRECIS Derived Property Value Registry. This new registry will contain the Derived Properties for the versions of Unicode that are released after (and including) version 6.3 of Unicode. The derived property value is to be calculated in cooperation with a designated expert [RFC5226] according to the rules specified under Section 7 and Section 8 in the current document. The registry will only be created when a designated expert is made available to assist IANA in the initiation of the registry. Changes to the rules that are used to generate the table of derived property values, and thus the registry itself, are done through IETF Review as defined by RFC 5226. > > QUESTION: Are the authors intended to get an DE before IESG Approval? Pete Resnick is following up on this. > Second, IANA will create a new registry called the PRECIS Base Classes Registry. This new registry has a registration template in the document submitted for approval. Maintenance of the registry will be through RFC Required, as defined in RFC 5226. > > There are two initial registrations in the registry, as follows: > > Base Class: FreeformClass. > Description: A sequence of letters, numbers, symbols, spaces, and > other code points that is used for free-form strings. > Specification: Section 3.3 of [ RFC-to-be ]. > > Base Class: IdentifierClass. > Description: A sequence of letters, numbers, and symbols that is > used to identify or address a network entity. > Specification: Section 3.3 of [ RFC-to-be ]. Correct, except the second instance of "Section 3.3" is incorrect in the I-D and should be "Section 3.2". > Third, IANA will create a new registry called the PRECIS Profiles Registry. This new registry has a registration template in the document submitted for approval. Maintenance of the registry will be through Expert Review, as defined in RFC 5226. > > IANA Question -> Are there to be any initial registrations in the new PRECIS Profiles Registry? No. However, just so you are aware, registrations are forthcoming in the following I-Ds: draft-ietf-precis-nickname draft-ietf-precis-saslprepbis draft-ietf-xmpp-6122bis > IANA understands that these three actions are the only ones that need to be completed upon approval of this document. Agreed. > Note: The actions requested in this document will not be completed > until the document has been approved for publication as an RFC. > This message is only to confirm what actions will be performed. > > Thanks, > > Pearl Liang Thank you, Pearl! Peter From nobody Wed Apr 23 17:56:58 2014 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 D63771A029F for ; Wed, 23 Apr 2014 15:52:51 -0700 (PDT) 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 SW63PEwu0UHq; Wed, 23 Apr 2014 15:52:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB201A070B; Wed, 23 Apr 2014 15:52:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: precis-chairs@tools.ietf.org, draft-ietf-precis-framework@tools.ietf.org, precis@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140423225250.25201.97197.idtracker@ietfa.amsl.com> Date: Wed, 23 Apr 2014 15:52:50 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/precis/fJmojVDljDKdYUp8anWw6SUlADs X-Mailman-Approved-At: Wed, 23 Apr 2014 17:56:55 -0700 Subject: [precis] ID Tracker State Update Notice: X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 22:52:52 -0000 IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-precis-framework/ From nobody Wed Apr 23 21:18:10 2014 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 E28141A029F; Wed, 23 Apr 2014 21:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.172 X-Spam-Level: X-Spam-Status: No, score=-0.172 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272] 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 PCUkx0cdciAQ; Wed, 23 Apr 2014 21:18:04 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id B196E1A0025; Wed, 23 Apr 2014 21:18:04 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WdB6j-000OV3-9t; Thu, 24 Apr 2014 00:17:57 -0400 Date: Thu, 24 Apr 2014 00:17:52 -0400 From: John C Klensin To: ietf@ietf.org, IETF-Announce Message-ID: <6C520F47E0BA6CEF00EF649B@JcK-HP8200.jck.com> In-Reply-To: <20140409190744.15518.7195.idtracker@ietfa.amsl.com> References: <20140409190744.15518.7195.idtracker@ietfa.amsl.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.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/precis/AysSVr27qtjts2MjoRaLVv5asAo Cc: precis@ietf.org Subject: Re: [precis] Last Call: (PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols) to Proposed Standard 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, 24 Apr 2014 04:18:08 -0000 --On Wednesday, April 09, 2014 12:07 -0700 The IESG wrote: > The IESG has received a request from the Preparation and > Comparison of Internationalized Strings WG (precis) to > consider the following document: - 'PRECIS Framework: > Preparation and Comparison of Internationalized Strings in > Application Protocols' > as Proposed Standard > > 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 > 2014-04-23. IESG, I have deliberately waited until the end of the Last Call period as posted [1], hoping that you would get (or generate) more focused comments on the draft in the interim. The issues discussed in this note were raised while what became the PRECIS WG (originally known by names like "Stringprep-bis") was being discussed and chartered and again on several occasions during the meetings of the WG. At least in my opinion, they were never discussed seriously: the WG made one important improvement (shifting to a rule-based inclusion approach) but has essentially ignored the fundamental problem. Because the predecessors of this note have not been actively considered in the WG or while its charter was being created, I don't actually expect it to accomplish anything other than to get some issues on the record. But I think the circumstances require one last try. This note consists of a high-level summary with details in footnotes on its various points. It is as short as I cam make it without leaving out issues and explanations that I believe are important. Summary: I see fundamental problems with approval of this specification and some issues with the decisions it includes. The first of these is temporary; the second more fundamental. (1) After the PRECIS WG task list settled down into its charter [2], the goal became, in essence, to replace Stringprep with something more explicitly rule-based and to update (or advise on) the various uses of Stringprep profiles. As described in the PRECIS charter, that approach noted the relationships among the various parts of the PRECIS work and called for handling the "framework, profile replacements, and guidelines ... in parallel as much as possible". The interrelated nature of the pieces makes it inappropriate for the IESG to approve the "framework" document for publication on the standards track at this time because doing so would foreclose some reasonable discussion of issues with the other specs -- exactly the situation the charter language was intended, at least in my recollection, to prevent. The approval and publication of RFC 6885 over a year ago has already been used that way. Some of the decisions reflected in the current draft illustration why more testing against specific profile examples and guidelines is important [5]. Recommendation: Tentatively approve the document now if that seems otherwise justified (I suggest below that it is not) but do not issue a Protocol Action Notice or handoff to the RFC Editor until after a sufficient number of of "profile replacements" and "guidelines" have been completed and examined through the IETF Last Call process to validate the "framework" provisions. The analogy of such a request to "running code" requirements should be obvious. (2) The longer-term problem is the one that PRECIS simply refused to address. When designing systems with direct effects on and interactions with users, predictability based on prior user experience and expectations is vital. That predictability is often expressed as the Law of Least Astonishment. In the case of use of non-ASCII characters in Internet applications, "least astonishment" implies, first, that rules should be intuitive and easily understood to the extent possible. Second and more important, if a user understands the rules of one application, she should be able to accurately extrapolate from that application to others. If there is a reason why that extrapolation does not work, the reasons should be clearly expressed and sufficiently comprehensible to be easily incorporated into the user's cognitive framework... and there should be few such cases. With the addition of "IdentifierClass" and "FreeformClass" to what, in its language, might be called "IDNA2008Class", we already have between one and two "Classes" too many for good user predictability. The language that indicates that additional classes might be defined in future specifications is not nearly strong enough in discouraging additional classes and explaining the reasons why. The PRECIS framework appears to fail those tests. It can be read as actively encouraging multiple profiles [3]. This is true even though the third bullet under "It is expected that this framework will yield..." explicitly acknowledges "more accurate expectations about the characters that are acceptable in various contexts" as an explicit objective. Recommendation: Hold this document until the various categories are exercised by at least a sampling of applicable profiles. Make the problems with excessive profiles explicit; impose requirements on additional profiles that include an explanation of why they are needed given the user-level interoperability and astonishment problems that can result from even three of them and require a higher level of review and consensus for creating new ones than "expert review". Modify the Security Considerations section to identify user astonishment and consequent confusion about what rules are being applied in a given PRECIS-User protocol as a risk and possible attack vector. thanks, john ----------------------------- [1] Despite the apparently-automatic announcement dated April 23, 2014 00:07 -0700 and indicating that the last call period had ended and the document state changed, the announcement, quoted above, says "by 2014-04-23". To the best of my knowledge, there has never been an announcement to the community, much less one backed by community discussion and consensus, that "by " now means "00:07 California time on that date". If anything, we have tended to interpret "by " as COB on that date or the last minute of that date anywhere in the world. [2] http://datatracker.ietf.org/wg/precis/charter/ [3] Not only should multiple profiles be discouraged for this type of case by the Law of Least Astonishment, but general IETF experience indicates that profiles are a bad idea and that protocols that depend on them (and use a significant variety) tend to be less successful than those that do not. [4] Sections 3.2.2 and 3.3.2 of -15. [5] There are issues with the two classes that are defined in this document that have not, I believe, been carefully addressed in the WG. At a minimum, they need to be considered more carefully in context with specific examples without preempting the choices to be made for those examples. The following are examples, not an exclusive list: (i) The "Contextual Rule" categories of IDNA2008 have proven to be extremely problematic, confusing, and controversial enough to be one of the key issues in the UTR 46 battles that have impeded IDNA2008 adoption in some important communities. While I still believe that the IDNA2008 decision was the right one, inclusion of those characters as Valid for both classes [4] should, given those bad experiences, require significantly more explanation and/or justification than this draft appears to provide. If the intent of incorporating this list in PRECIS is to provide for compatibility with IDNA2008, the list should be incorporated by reference (either to RFC 5892 and its successors or to a separate documents that updates and replaces the list in RFC 5892 as well as being used for PRECIS), not be provided as a list of code points that could cause the two definitions to diverge if changes are made to one or the other. The issue may apply more generally to the other characters listed in Section 7.6 and to other IDNA-derived elements of Section 7. (ii) Characters with compatibility equivalents are problematic, in large measure because of a Unicode issue that has been extensively discussed in the past. Basically the compatibility equivalency category mixes several unrelated and incompatible (sic) groups of things under a single label. One extreme is occupied by characters used with East Asian scripts that are distinguished only by their widths. If the Unicode design principles of "characters, not glyphs" and "plain text" had been followed, these different-width variations would never have been assigned different code points. As a contrasting example, the relevance of, and distinctions among, special mathematical code points distinguished by mathematical use and specific type styles is less clear: treating them as separate characters may be justified under some circumstances. A more extreme example occurs with some Chinese characters that Unicode treats as compatibility equivalents for other characters. That treatment is usually (and perhaps always) appropriate when the "meaning" of the characters is intended. But some of those characters are, or historically have been, used in personal names. To the extent to which those names are used as identifiers, e.g., for a person thus named, treating them as invalid is inappropriate and applying a compatibility mapping to them only slightly less bad. (iii) Experience with IDNA strongly suggests that "DefaultIgnorable" is a bad idea. Forbidding some (or perhaps all) of these characters may be reasonable; treating them as if they were not present impedes possibly-reasonable future extensions and provides an attack vector for phishing and other types of unpleasant behavior that do not appear to be called out in Security Considerations. It is also worth noting that one difference between IDNA2008 and this specification is that the former is not profiled (except by registries providing their own subsetting rules) while the latter is intended as a base for profiling. While the order in which categorization rules is applied in Section 8 provides some protection (perhaps sufficient protection if the spec is never updated or used as the basis for a different profile), it is worth noting that some code points appear in more than one category (e.g., the notorious ZWJ and ZWNJ in both JoinControl (Section 7.8) and PrecisIgnorableProperties (Section 7.13)) and that this should at least be called out explicitly. From nobody Thu Apr 24 05:16:35 2014 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 40DE41A01B3; Thu, 24 Apr 2014 05:16:29 -0700 (PDT) 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 hI4-Rp_5g1AM; Thu, 24 Apr 2014 05:16:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4979D1A0188; Thu, 24 Apr 2014 05:16:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140424121627.28661.19091.idtracker@ietfa.amsl.com> Date: Thu, 24 Apr 2014 05:16:27 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/precis/QDxZEWPHU9TkK7In0YGkFYIL1uc Cc: precis-chairs@tools.ietf.org, draft-ietf-precis-framework@tools.ietf.org, precis@ietf.org Subject: [precis] Benoit Claise's No Objection on draft-ietf-precis-framework-16: (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, 24 Apr 2014 12:16:30 -0000 Benoit Claise has entered the following ballot position for draft-ietf-precis-framework-16: 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: ---------------------------------------------------------------------- - More of a series of question than a COMMENT. Disclaimer: the PRECIS work is very far from my comfort zone, so there might be a little bit of eduction involved here. You have identified IdentifierClass and FreeformClass. As OPS AD, I'm wondering whether future OPS data models should take these classes into account. Let me explain. We have: SMI Textual Convention (RFC 2579). For example: SnmpAdminString YANG typedef (https://tools.ietf.org/html/rfc6020#section-7.3) IPFIX data types (RFC 7011) AAA Should we ideally start specifying our data model strings according to these classes, to facilitate strings comparison operations? Should we start defining new SMI TC, YANG typedef, or IPFIX data types? Is there some education required in OPS? I guess that there is no action for the authors at this point, and the next step is an informal discussion with Pete. - https://datatracker.ietf.org/doc/draft-ietf-precis-framework/shepherdwriteup/ There is a normative downref to draft-ietf-precis-mappings (an Informative document). I see that draft-ietf-precis-mappings in the informative references. From nobody Thu Apr 24 06:21:07 2014 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 C53E21A01CB; Thu, 24 Apr 2014 06:21:02 -0700 (PDT) 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 w39yLbHAPZ1Y; Thu, 24 Apr 2014 06:20:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 198F71A01E3; Thu, 24 Apr 2014 06:20:59 -0700 (PDT) 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.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140424132059.12242.13096.idtracker@ietfa.amsl.com> Date: Thu, 24 Apr 2014 06:20:59 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/precis/72H-fm256sEOLywP6649xQThWqY Cc: precis-chairs@tools.ietf.org, draft-ietf-precis-framework@tools.ietf.org, precis@ietf.org Subject: [precis] Stephen Farrell's No Objection on draft-ietf-precis-framework-16: (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, 24 Apr 2014 13:21:03 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-precis-framework-16: 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: ---------------------------------------------------------------------- - 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 Apr 24 07:19:27 2014 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 220F31A02C8; Thu, 24 Apr 2014 07:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JsCNX8XKkTw; Thu, 24 Apr 2014 07:19:23 -0700 (PDT) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id BEF521A02AD; Thu, 24 Apr 2014 07:19:22 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id cm18so2295058qab.32 for ; Thu, 24 Apr 2014 07:19:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=bFlGVqGQxGMyGVAB5NTpyBA4eumCmyU+6nUb7FQHND8=; b=VpC7RztID2P3gfJsGb2FZEN3RQBhlFGrB3+eenTj7BzzQMGvluOa5lnJ0fGe+J/gzs bmcyNbtHFEEaanXBTCsUB5K0YXxcEY9GWPL5Xsr0r8xUjlicgLHlCSedhbqHRNyitoN8 rL5QOMh+l522SbPOmM9d9ZJYJQ+X2XVq91mFzTRqKk3LDy1dpbvzIKmymISkSeYMradv vJbF6MhPJ+KKM+m/GSFCd2UeMb+0kyZ1sn6QZIeFstNejVhFprQWWGH2ULrQaLJXNwYx L549DvyeVa9gQtyIi7jrlBR9xt1aSdh7P467wD2GkgMwGXxIsG0UefFNmaU3JdisDHxa eVzQ== MIME-Version: 1.0 X-Received: by 10.140.83.232 with SMTP id j95mr2963011qgd.42.1398349156524; Thu, 24 Apr 2014 07:19:16 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.136.134 with HTTP; Thu, 24 Apr 2014 07:19:16 -0700 (PDT) In-Reply-To: <5358512A.1040706@qti.qualcomm.com> References: <20140423224227.12329.68404.idtracker@ietfa.amsl.com> <5358512A.1040706@qti.qualcomm.com> Date: Thu, 24 Apr 2014 10:19:16 -0400 X-Google-Sender-Auth: ikIrvoJ30iluXxcwKFepOl8zgc4 Message-ID: From: Barry Leiba To: Pete Resnick Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/precis/gjWLeFZ-8a6rEkBwMsAeA_5-Yd4 Cc: draft-ietf-precis-framework@tools.ietf.org, precis-chairs@tools.ietf.org, precis@ietf.org, The IESG Subject: Re: [precis] Barry Leiba's Discuss on draft-ietf-precis-framework-16: (with DISCUSS) 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, 24 Apr 2014 14:19:24 -0000 > I refer you to RFC 5892, section 5.1 and Appendix B: It might not surprise you, but I don't very much care that IDNAbis did it the wrong way also. > This is pretty much identical to what IDNA did. I agree that we should > probably recruit the expert (and I hope we can recruit the same expert as > the one for IDNA Derived Properties), but I don't think the task will be > tremendously burdensome, even though it sounds that way. The point of "don't > just copy Appendix A" is to account for the possibility that the Unicode > properties might be moving targets. But for the most part, it's an act of > checking that the properties are "as expected". > > I will contact Patrik and see if he's willing. It's good to hear that it won't be burdensome, but it still seems that the working group produced an incomplete document. The right way to have handled this would have been to involve the appropriate experts near the end of the working group's process, and to get the table in Appendix A to be the initial registration data, already vetted by the expert. That way, the instructions to IANA would be clear, and the IETF and the IESG would be reviewing the complete picture. When the document is approved and IANA creates the registry, they will contact the authors to confirm that it's all correct, at which point the authors would ask the expert to check it again. It's unlikely that there'd be any changes needed in the roughly four weeks between IETF last call and document approval, and given that the expert you intend to recruit is also our liaison to the Unicode Consortium, he could confirm that they are not working on any updates just now. As it stands, what the working group seems to be saying is that they don't have the expertise to get this right, and can't get the right experts involved... which, in any other context, we would push back on very hard, indeed. All that said, we've now had the discussion and Pete has this in hand, so even though I think it was done badly (which is beating up Pete as much as it is the working group), it's time for me to move this to a non-blocking comment. If this sort of thing comes up again, *please* do not do it this way. Get the experts involved earlier, and present the community with a finished document. Barry >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> I will move to a strong "yes" on this, once we have some discussion of >> the registry defined in Section 9.1. >> >> The registry created in Section 9.1 is very odd indeed. I guess IANA is >> expected to assume that the format of the registry will look like the >> non-normative table in the appendix, but Section 9.1 doesn't say what the >> format of the registry will be. In general, I see that IANA has asked >> several questions in its review, and those questions haven't been >> responded to (and, unusually, the IANA review is in the IESG mailing list >> archive but *not* in the document history in the datatracker). They >> should be given a response. >> >> But the real oddity here is that the specification of the registry >> involves an *enormous* startup cost for the designated expert, *and* >> requires that the DE be appointed and start her work immediately. >> Normally, IANA takes the required actions as soon as the document's >> approval is announced, but in this case they will have to wait for the DE >> to be appointed and to derive the entire content of the registry. >> >> It seems to me that the right way to have handled this would have been >> for the working group to have engaged the appropriate experts and made >> the table Appendix A *be* the initial contents of the registry, rather >> than explicitly denouncing Appendix A and leaving it as a seemingly quite >> onerous startup task that will delay the IANA actions indefinitely. >> >> Why was it done this way, and what is the plan to get the registry >> content specified in a reasonable time? Should approval of the document >> wait for that content to be specified? Or are we really expecting to >> approve the document with the content of the registry left open? From nobody Thu Apr 24 07:31:55 2014 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 DECB31A01DA; Thu, 24 Apr 2014 07:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, 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 FLfQb77n_cqw; Thu, 24 Apr 2014 07:31:49 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B766D1A0290; Thu, 24 Apr 2014 07:31:49 -0700 (PDT) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 42A0340427; Thu, 24 Apr 2014 08:31:38 -0600 (MDT) Message-ID: <5359204A.90100@stpeter.im> Date: Thu, 24 Apr 2014 08:31:38 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Stephen Farrell , The IESG References: <20140424132059.12242.13096.idtracker@ietfa.amsl.com> In-Reply-To: <20140424132059.12242.13096.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/cTTI0t1UxWyuWsfihddybrrYzbA Cc: precis-chairs@tools.ietf.org, draft-ietf-precis-framework@tools.ietf.org, precis@ietf.org Subject: Re: [precis] Stephen Farrell's No Objection on draft-ietf-precis-framework-16: (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, 24 Apr 2014 14:31:52 -0000 On 4/24/14, 7:20 AM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-precis-framework-16: 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: > ---------------------------------------------------------------------- > > > - 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. Appendix A has been checked using two implementations. The question is whether we want to base the initial registration on a third. But yes, the *initial* registration *could* use Appendix A once it has been reviewed by the designated expert (who might find errors, despite the fact that Takahiro Nemoto and I checked our independent results and came to agreement on the derived properties). This was discussed on the WG list, see for instance: http://www.ietf.org/mail-archive/web/precis/current/msg00605.html > 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. We are simply referencing RFC 5892 here: http://tools.ietf.org/html/rfc5892#section-2.7 Further, the PRECIS Derived Property Value Registry will specify only the derived properties (e.g., UNASSIGNED or PVALID), not the interim steps used to calculate the derived properties (e.g., HasCompat or BackwardCompatible). So the latter values are never populated into the registry. > 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? s/MUST/are strongly encouraged to/ ? One example of what an application protocol spec could say is here: http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-12#section-7.3.2 > 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:-) Well, draft-ietf-precis-saslprepbis currently says: In protocols that provide usernames as input to a cryptographic algorithm such as a hash function, the client will need to perform proper preparation of the username before applying the algorithm. and: 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. Would some text along those lines in the security considerations of this document meet your needs? Peter From nobody Thu Apr 24 07:34:59 2014 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 6F2EC1A027E; Thu, 24 Apr 2014 07:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, 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 nPrhK0vIJrCG; Thu, 24 Apr 2014 07:34:54 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B666B1A0266; Thu, 24 Apr 2014 07:34:54 -0700 (PDT) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A5ACF40453; Thu, 24 Apr 2014 08:34:48 -0600 (MDT) Message-ID: <53592108.7030009@stpeter.im> Date: Thu, 24 Apr 2014 08:34:48 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Benoit Claise , The IESG References: <20140424121627.28661.19091.idtracker@ietfa.amsl.com> In-Reply-To: <20140424121627.28661.19091.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/XnbxDiBxVMHWZ5z_lcq1VaYX3Mk Cc: precis-chairs@tools.ietf.org, draft-ietf-precis-framework@tools.ietf.org, precis@ietf.org Subject: Re: [precis] Benoit Claise's No Objection on draft-ietf-precis-framework-16: (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, 24 Apr 2014 14:34:56 -0000 On 4/24/14, 6:16 AM, Benoit Claise wrote: > Benoit Claise has entered the following ballot position for > draft-ietf-precis-framework-16: 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: > ---------------------------------------------------------------------- > > - More of a series of question than a COMMENT. Disclaimer: the PRECIS > work is very far from my comfort zone, so there might be a little bit of > eduction involved here. > > You have identified IdentifierClass and FreeformClass. > As OPS AD, I'm wondering whether future OPS data models should take these > classes into account. > Let me explain. We have: > SMI Textual Convention (RFC 2579). For example: SnmpAdminString > YANG typedef (https://tools.ietf.org/html/rfc6020#section-7.3) > IPFIX data types (RFC 7011) > AAA > Should we ideally start specifying our data model strings according to > these classes, to facilitate strings comparison operations? Should we > start defining new SMI TC, YANG typedef, or IPFIX data types? Is there > some education required in OPS? > I guess that there is no action for the authors at this point, and the > next step is an informal discussion with Pete. Yes, I think that chatting with Pete about it is a good idea. Peter From nobody Thu Apr 24 07:40:08 2014 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 3CF561A0318; Thu, 24 Apr 2014 07:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, 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 YjDrsiv6u5o9; Thu, 24 Apr 2014 07:40:02 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 39C8F1A031A; Thu, 24 Apr 2014 07:40:02 -0700 (PDT) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5734140453; Thu, 24 Apr 2014 08:39:53 -0600 (MDT) Message-ID: <53592239.8020401@stpeter.im> Date: Thu, 24 Apr 2014 08:39:53 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Barry Leiba , Pete Resnick References: <20140423224227.12329.68404.idtracker@ietfa.amsl.com> <5358512A.1040706@qti.qualcomm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/LnFIg5RehnjxUXAoLcsjiySI7JU Cc: draft-ietf-precis-framework@tools.ietf.org, precis-chairs@tools.ietf.org, precis@ietf.org, The IESG Subject: Re: [precis] Barry Leiba's Discuss on draft-ietf-precis-framework-16: (with DISCUSS) 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, 24 Apr 2014 14:40:06 -0000 On 4/24/14, 8:19 AM, Barry Leiba wrote: >> I refer you to RFC 5892, section 5.1 and Appendix B: > > It might not surprise you, but I don't very much care that IDNAbis did > it the wrong way also. > >> This is pretty much identical to what IDNA did. I agree that we should >> probably recruit the expert (and I hope we can recruit the same expert as >> the one for IDNA Derived Properties), but I don't think the task will be >> tremendously burdensome, even though it sounds that way. The point of "don't >> just copy Appendix A" is to account for the possibility that the Unicode >> properties might be moving targets. But for the most part, it's an act of >> checking that the properties are "as expected". >> >> I will contact Patrik and see if he's willing. > > It's good to hear that it won't be burdensome, but it still seems that > the working group produced an incomplete document. The right way to > have handled this would have been to involve the appropriate experts > near the end of the working group's process, and to get the table in > Appendix A to be the initial registration data, already vetted by the > expert. That way, the instructions to IANA would be clear, and the > IETF and the IESG would be reviewing the complete picture. When the > document is approved and IANA creates the registry, they will contact > the authors to confirm that it's all correct, at which point the > authors would ask the expert to check it again. It's unlikely that > there'd be any changes needed in the roughly four weeks between IETF > last call and document approval, and given that the expert you intend > to recruit is also our liaison to the Unicode Consortium, he could > confirm that they are not working on any updates just now. That all sounds beautiful. I'm sorry we didn't do it that way. > As it stands, what the working group seems to be saying is that they > don't have the expertise to get this right, and can't get the right > experts involved... which, in any other context, we would push back on > very hard, indeed. IMHO the WG has worked hard to get things right - we've had two separate implementations comparing their output, etc. But as we know i18n is difficult, and perhaps only John Klensin has the expertise to get this right anyway. :-) That's partly why in general we based PRECIS on the same technical approach taken in IDNA. > All that said, we've now had the discussion and Pete has this in hand, > so even though I think it was done badly (which is beating up Pete as > much as it is the working group), it's time for me to move this to a > non-blocking comment. If this sort of thing comes up again, *please* > do not do it this way. Get the experts involved earlier, and present > the community with a finished document. I, for one, intend to never work on an internationalization framework again... Peter From nobody Thu Apr 24 07:40:51 2014 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 5A02A1A0318; Thu, 24 Apr 2014 07:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 5xLX8e16UcgN; Thu, 24 Apr 2014 07:40:46 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A2B951A031A; Thu, 24 Apr 2014 07:40:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 86F31BE58; Thu, 24 Apr 2014 15:40:38 +0100 (IST) 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 RM0s+me6OamJ; Thu, 24 Apr 2014 15:40:38 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5642BBE57; Thu, 24 Apr 2014 15:40:38 +0100 (IST) Message-ID: <53592266.2060509@cs.tcd.ie> Date: Thu, 24 Apr 2014 15:40:38 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Peter Saint-Andre , The IESG References: <20140424132059.12242.13096.idtracker@ietfa.amsl.com> <5359204A.90100@stpeter.im> In-Reply-To: <5359204A.90100@stpeter.im> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/rb2IlJByDBGnK4Ji5Gn9QUN22qM Cc: precis-chairs@tools.ietf.org, draft-ietf-precis-framework@tools.ietf.org, precis@ietf.org Subject: Re: [precis] Stephen Farrell's No Objection on draft-ietf-precis-framework-16: (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, 24 Apr 2014 14:40:49 -0000 Hi Peter, On 04/24/2014 03:31 PM, Peter Saint-Andre wrote: > On 4/24/14, 7:20 AM, Stephen Farrell wrote: >> Stephen Farrell has entered the following ballot position for >> draft-ietf-precis-framework-16: 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: >> ---------------------------------------------------------------------- >> >> >> - 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. > > Appendix A has been checked using two implementations. The question is > whether we want to base the initial registration on a third. > > But yes, the *initial* registration *could* use Appendix A once it has > been reviewed by the designated expert (who might find errors, despite > the fact that Takahiro Nemoto and I checked our independent results and > came to agreement on the derived properties). > > This was discussed on the WG list, see for instance: > > http://www.ietf.org/mail-archive/web/precis/current/msg00605.html I'm fine that you've discussed this with Barry. > >> 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. > > We are simply referencing RFC 5892 here: > > http://tools.ietf.org/html/rfc5892#section-2.7 > > Further, the PRECIS Derived Property Value Registry will specify only > the derived properties (e.g., UNASSIGNED or PVALID), not the interim > steps used to calculate the derived properties (e.g., HasCompat or > BackwardCompatible). So the latter values are never populated into the > registry. The bit that I found odd (no more) was: "G: cp is in {}" I think that's just saying there are no code points in this category at the moment, which is fine, but that wasn't (clearly) stated, instead it says "This category includes..." which is a bit confusing since its the empty set. If you wanted, s/This category includes/This currently empty category will include/ would be clearer for me. (Assuming I read it right:-) > >> 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? > > s/MUST/are strongly encouraged to/ ? Yes, I think that's better. > One example of what an application protocol spec could say is here: > > http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-12#section-7.3.2 Right. I note that that's over a page of text. Seems like a pity it can't be much shorter, but I guess that's just life;-) > >> 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:-) > > Well, draft-ietf-precis-saslprepbis currently says: > > In protocols that provide usernames as input to a cryptographic > algorithm such as a hash function, the client will need to perform > proper preparation of the username before applying the algorithm. > > and: > > 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. > > Would some text along those lines in the security considerations of this > document meet your needs? You already reference that draft from here so its probably ok, but I guess the point is generic and not sasl-specific so it could (also) be mentioned here. Your call though, as its a fairly minor and pretty obvious thing. Cheers, S. > > Peter > From nobody Thu Apr 24 07:46:47 2014 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 C991A1A031D; Thu, 24 Apr 2014 07:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUR6azxg1Q_N; Thu, 24 Apr 2014 07:46:43 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 811AF1A0318; Thu, 24 Apr 2014 07:46:43 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id i17so2635787qcy.0 for ; Thu, 24 Apr 2014 07:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=MNscjoiwM1jAbeHBwC3ygLa2OToJ0BSvfTGw99XWBDQ=; b=RsJgwTDeZ2Kx/dS/rQ4PssTlBOWJ1AZi2u2YxG24+SZXZZH197UZPqHtaniJKGoPkn luFj4EiYnMX9SgRushqCmpjKoDVX07vCebxdns0YjZN2F3MFTi37nerpm3xyXGFtUEzI SeOzHWtcHYT8g2dHxQT3pBSdvn9R0xcu+wlDYWrr+1fW7aGQ88XcVW1I9xbmF+ojUe0M rRmltSlijQry4EEb3HYPwPDpRQHUxYjs4vdpjQ7FksSRXCqonbgwwOcXSg4aWLSbuGp9 0pDVhNjyDaFsryVoInk+ajQ4H8XtCpeCkqTbAMIedIiERozKlDp6gwrBHebbI7+rBmQp P2Nw== MIME-Version: 1.0 X-Received: by 10.224.25.2 with SMTP id x2mr3299670qab.37.1398350797274; Thu, 24 Apr 2014 07:46:37 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.136.134 with HTTP; Thu, 24 Apr 2014 07:46:37 -0700 (PDT) In-Reply-To: <53592239.8020401@stpeter.im> References: <20140423224227.12329.68404.idtracker@ietfa.amsl.com> <5358512A.1040706@qti.qualcomm.com> <53592239.8020401@stpeter.im> Date: Thu, 24 Apr 2014 10:46:37 -0400 X-Google-Sender-Auth: QZtH3MzvUOENXQhbD-b6ASNmprE Message-ID: From: Barry Leiba To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/precis/masYtTVAvb93k55M6NtTRXTGcGo Cc: The IESG , Pete Resnick , draft-ietf-precis-framework@tools.ietf.org, precis-chairs@tools.ietf.org, precis@ietf.org Subject: Re: [precis] Barry Leiba's Discuss on draft-ietf-precis-framework-16: (with DISCUSS) 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, 24 Apr 2014 14:46:45 -0000 > I, for one, intend to never work on an internationalization framework > again... He-he-he........ [And so, unfortunately, does I18N burn out experts at an alarming rate.] b From nobody Thu Apr 24 08:18:09 2014 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 44B4C1A0397; Thu, 24 Apr 2014 08:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.674 X-Spam-Level: X-Spam-Status: No, score=-2.674 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 g8Ee_N9TtAGl; Thu, 24 Apr 2014 08:17:59 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id E7A481A033D; Thu, 24 Apr 2014 08:17:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1398352673; x=1429888673; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=AUAIJ6IHcf3VwxStknqcwO30mK0IddftwZDCrzU0XYU=; b=fmANBsVTgvFBJrU96AbwTyFEIaiodVsYucO75hTg1gvLncBUSeTd7NJK 03VNKf6MVdYwWAeH6L8+6d0dqff6O/T6zl0dIf1u0Jtia/NjWQEk8ogSL CRYOT0q5eAYHw41fpAlWAP0TtfVzU0swl8MfUG8EqPOhIY8lOIrG4hx3M k=; X-IronPort-AV: E=McAfee;i="5400,1158,7417"; a="30918887" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 24 Apr 2014 08:17:53 -0700 X-IronPort-AV: E=Sophos;i="4.97,919,1389772800"; d="scan'208";a="667319135" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 24 Apr 2014 08:17:54 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Apr 2014 08:17:52 -0700 Message-ID: <53592B13.3060707@qti.qualcomm.com> Date: Thu, 24 Apr 2014 10:17:39 -0500 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: Barry Leiba References: <20140423224227.12329.68404.idtracker@ietfa.amsl.com> <5358512A.1040706@qti.qualcomm.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Archived-At: http://mailarchive.ietf.org/arch/msg/precis/8txXKkaxDtVRNZbmS7JvcfsfpQ8 Cc: The IESG , precis-chairs@tools.ietf.org, draft-ietf-precis-framework@tools.ietf.org, precis@ietf.org Subject: Re: [precis] Barry Leiba's Discuss on draft-ietf-precis-framework-16: (with DISCUSS) 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, 24 Apr 2014 15:18:01 -0000 On 4/24/14 9:19 AM, Barry Leiba wrote: > It's good to hear that it won't be burdensome, but it still seems that > the working group produced an incomplete document. Sort of. The problem is that it really isn't the IETF's expertise or responsibility to create that sort of document. In fact what would be ideal is to point to a document or registry controlled by the Unicode Consortium. But the conclusion of the community during IDNA was that we would not be provided such a stable reference. Given that, IDNA did a de-reference; we'd create an IANA registry, run by a Unicode expert, but that tracked the state of the properties that we needed for our purposes. Not pretty or ideal, but practical. This WG followed that lead, I think equally pragmatically. As you say, water under the bridge. I got email back and Patrik has agreed to be the expert; I'll add a management item during agenda bash. He'll prepare the contents of the registry and we should be good to go. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Thu Apr 24 08:46:42 2014 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 6AEB61A0275; Thu, 24 Apr 2014 08:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 bjSJdSYwEDbq; Thu, 24 Apr 2014 08:46:36 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1DD1A020F; Thu, 24 Apr 2014 08:46:36 -0700 (PDT) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B374340427; Thu, 24 Apr 2014 09:46:27 -0600 (MDT) Message-ID: <535931D3.1060002@stpeter.im> Date: Thu, 24 Apr 2014 09:46:27 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: John C Klensin , ietf@ietf.org References: <20140409190744.15518.7195.idtracker@ietfa.amsl.com> <6C520F47E0BA6CEF00EF649B@JcK-HP8200.jck.com> In-Reply-To: <6C520F47E0BA6CEF00EF649B@JcK-HP8200.jck.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/hrRAm93Dl0oX-DLOWLvYWVmuB1E Cc: precis@ietf.org Subject: Re: [precis] Last Call: (PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols) to Proposed Standard 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, 24 Apr 2014 15:46:39 -0000 On 4/23/14, 10:17 PM, John C Klensin wrote: > > > --On Wednesday, April 09, 2014 12:07 -0700 The IESG > wrote: > >> The IESG has received a request from the Preparation and >> Comparison of Internationalized Strings WG (precis) to >> consider the following document: - 'PRECIS Framework: >> Preparation and Comparison of Internationalized Strings in >> Application Protocols' >> as Proposed Standard >> >> 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 >> 2014-04-23. > > IESG, > > I have deliberately waited until the end of the Last Call period > as posted [1], hoping that you would get (or generate) more > focused comments on the draft in the interim. John, that seems like an exceedingly unrealistic hope. You know better than anyone that internationalization expertise is spread very thinly in the IETF (and elsewhere). Folks from the IETF community who care about i18n are already likely to have provided feedback on the PRECIS documents. We just don't have very many such people. > The issues > discussed in this note were raised while what became the PRECIS > WG (originally known by names like "Stringprep-bis") was being > discussed and chartered and again on several occasions during > the meetings of the WG. At least in my opinion, they were > never discussed seriously: the WG made one important improvement > (shifting to a rule-based inclusion approach) but has > essentially ignored the fundamental problem. Because the > predecessors of this note have not been actively considered in > the WG or while its charter was being created, I don't actually > expect it to accomplish anything other than to get some issues > on the record. But I think the circumstances require one last > try. Ignored might be a bit strong. Perhaps those active in the WG did not see a way to achieve the high goal you have set here. Throwing up our hands and doing nothing (and thus remaining stuck on Stringprep and Unicode 3.2) seems like it would have been a worse outcome. > This note consists of a high-level summary with details in > footnotes on its various points. It is as short as I cam make > it without leaving out issues and explanations that I believe > are important. > > Summary: > > I see fundamental problems with approval of this specification > and some issues with the decisions it includes. The first of > these is temporary; the second more fundamental. > > (1) After the PRECIS WG task list settled down into its charter > [2], the goal became, in essence, to replace Stringprep with > something more explicitly rule-based and to update (or advise > on) the various uses of Stringprep profiles. As described in > the PRECIS charter, that approach noted the relationships among > the various parts of the PRECIS work and called for handling the > "framework, profile replacements, and guidelines ... in parallel > as much as possible". The interrelated nature of the pieces > makes it inappropriate for the IESG to approve the "framework" > document for publication on the standards track at this time > because doing so would foreclose some reasonable discussion of > issues with the other specs -- exactly the situation the charter > language was intended, at least in my recollection, to prevent. > The approval and publication of RFC 6885 over a year ago has > already been used that way. > > Some of the decisions reflected in the current draft > illustration why more testing against specific profile examples > and guidelines is important [5]. We have 5 profiles in a quite advanced state, specified in 3 I-Ds (draft-ietf-precis-saslprepbis, draft-ietf- > Recommendation: Tentatively approve the document now if that > seems otherwise justified (I suggest below that it is not) but > do not issue a Protocol Action Notice or handoff to the RFC > Editor until after a sufficient number of of "profile > replacements" and "guidelines" have been completed and examined > through the IETF Last Call process to validate the "framework" > provisions. The analogy of such a request to "running code" > requirements should be obvious. IMHO we are close to having that running code, but we haven't pushed all the documents forward at exactly the same time. > (2) The longer-term problem is the one that PRECIS simply > refused to address. It's a hard problem. Refused might be a bit strong. > When designing systems with direct effects > on and interactions with users, predictability based on prior > user experience and expectations is vital. That predictability > is often expressed as the Law of Least Astonishment. In the > case of use of non-ASCII characters in Internet applications, > "least astonishment" implies, first, that rules should be > intuitive and easily understood to the extent possible. Second > and more important, if a user understands the rules of one > application, she should be able to accurately extrapolate from > that application to others. If there is a reason why that > extrapolation does not work, the reasons should be clearly > expressed and sufficiently comprehensible to be easily > incorporated into the user's cognitive framework... and there > should be few such cases. That sounds ideal, but unfortunately we are dealing with a quite messy reality in which we have many different kinds of identifiers - domain names, email addresses, file names, chatrooms, IM handles, nicknames, etc. Reducing them all to one thing seems unrealistic to me. I would love to achieve that, but I don't see it happening anytime soon. > With the addition of "IdentifierClass" and "FreeformClass" to > what, in its language, might be called "IDNA2008Class", we > already have between one and two "Classes" too many for good > user predictability. The language that indicates that > additional classes might be defined in future specifications is > not nearly strong enough in discouraging additional classes and > explaining the reasons why. > > The PRECIS framework appears to fail those tests. It can be > read as actively encouraging multiple profiles [3]. Because we have a world with multiple identifiers. > This is > true even though the third bullet under "It is expected that > this framework will yield..." explicitly acknowledges "more > accurate expectations about the characters that are acceptable > in various contexts" as an explicit objective. > > Recommendation: Hold this document until the various categories > are exercised by at least a sampling of applicable profiles. See above. We have 5 profiles very close to done. Also: hold in what sense? These documents are going forward to Proposed Standard. IMHO we need further experience with them, in the field, and possible revision in the future. But we have a stronger basis for that now (with PRECIS) than we ever would have had with Stringprep. I think the WG realizes that PRECIS is not perfect as it is. I doubt that perfection can be achieved in the messy domain of i18n, though. > Make the problems with excessive profiles explicit; impose > requirements on additional profiles that include an explanation > of why they are needed given the user-level interoperability and > astonishment problems that can result from even three of them > and require a higher level of review and consensus for creating > new ones than "expert review". Modify the Security > Considerations section to identify user astonishment and > consequent confusion about what rules are being applied in a > given PRECIS-User protocol as a risk and possible attack vector. Those do seem like good things. I am out of time right now to reply to the topics from your footnotes. Peter > > thanks, > john > > ----------------------------- > [3] Not only should multiple profiles be discouraged for this > type of case by the Law of Least Astonishment, but general IETF > experience indicates that profiles are a bad idea and that > protocols that depend on them (and use a significant variety) > tend to be less successful than those that do not. > > [4] Sections 3.2.2 and 3.3.2 of -15. > > [5] There are issues with the two classes that are defined in > this document that have not, I believe, been carefully addressed > in the WG. At a minimum, they need to be considered more > carefully in context with specific examples without preempting > the choices to be made for those examples. The following are > examples, not an exclusive list: > > (i) The "Contextual Rule" categories of IDNA2008 have proven to > be extremely problematic, confusing, and controversial enough to > be one of the key issues in the UTR 46 battles that have impeded > IDNA2008 adoption in some important communities. While I still > believe that the IDNA2008 decision was the right one, inclusion > of those characters as Valid for both classes [4] should, given > those bad experiences, require significantly more explanation > and/or justification than this draft appears to provide. If the > intent of incorporating this list in PRECIS is to provide for > compatibility with IDNA2008, the list should be incorporated by > reference (either to RFC 5892 and its successors or to a > separate documents that updates and replaces the list in RFC > 5892 as well as being used for PRECIS), not be provided as a > list of code points that could cause the two definitions to > diverge if changes are made to one or the other. The issue may > apply more generally to the other characters listed in Section > 7.6 and to other IDNA-derived elements of Section 7. > > (ii) Characters with compatibility equivalents are problematic, > in large measure because of a Unicode issue that has been > extensively discussed in the past. Basically the compatibility > equivalency category mixes several unrelated and incompatible > (sic) groups of things under a single label. One extreme is > occupied by characters used with East Asian scripts that are > distinguished only by their widths. If the Unicode design > principles of "characters, not glyphs" and "plain text" had been > followed, these different-width variations would never have been > assigned different code points. As a contrasting example, the > relevance of, and distinctions among, special mathematical code > points distinguished by mathematical use and specific type > styles is less clear: treating them as separate characters may > be justified under some circumstances. A more extreme example > occurs with some Chinese characters that Unicode treats as > compatibility equivalents for other characters. That treatment > is usually (and perhaps always) appropriate when the "meaning" > of the characters is intended. But some of those characters > are, or historically have been, used in personal names. To the > extent to which those names are used as identifiers, e.g., for a > person thus named, treating them as invalid is inappropriate and > applying a compatibility mapping to them only slightly less bad. > > (iii) Experience with IDNA strongly suggests that > "DefaultIgnorable" is a bad idea. Forbidding some (or perhaps > all) of these characters may be reasonable; treating them as if > they were not present impedes possibly-reasonable future > extensions and provides an attack vector for phishing and other > types of unpleasant behavior that do not appear to be called out > in Security Considerations. It is also worth noting that one > difference between IDNA2008 and this specification is that the > former is not profiled (except by registries providing their own > subsetting rules) while the latter is intended as a base for > profiling. While the order in which categorization rules is > applied in Section 8 provides some protection (perhaps > sufficient protection if the spec is never updated or used as > the basis for a different profile), it is worth noting that some > code points appear in more than one category (e.g., the > notorious ZWJ and ZWNJ in both JoinControl (Section 7.8) and > PrecisIgnorableProperties (Section 7.13)) and that this should > at least be called out explicitly. > > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis > From nobody Thu Apr 24 09:01:56 2014 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 996991A02AD; Thu, 24 Apr 2014 09:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.872 X-Spam-Level: X-Spam-Status: No, score=-2.872 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272] 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 fFV2C_MiQNOl; Thu, 24 Apr 2014 09:01:49 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id DCBFF1A03BA; Thu, 24 Apr 2014 09:01:48 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WdM5g-000PQG-K3; Thu, 24 Apr 2014 12:01:36 -0400 Date: Thu, 24 Apr 2014 12:01:31 -0400 From: John C Klensin To: Peter Saint-Andre , Barry Leiba , Pete Resnick Message-ID: In-Reply-To: <53592239.8020401@stpeter.im> References: <20140423224227.12329.68404.idtracker@ietfa.amsl.com> <5358512A.1040706@qti.qualcomm.com> <53592239.8020401@stpeter.im> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/precis/mHUSx5KK3BfQGF4VN7c5n_geUaI Cc: The IESG , precis-chairs@tools.ietf.org, draft-ietf-precis-framework@tools.ietf.org, precis@ietf.org Subject: Re: [precis] Barry Leiba's Discuss on draft-ietf-precis-framework-16: (with DISCUSS) 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, 24 Apr 2014 16:01:53 -0000 --On Thursday, April 24, 2014 08:39 -0600 Peter Saint-Andre wrote: > IMHO the WG has worked hard to get things right - we've had > two separate implementations comparing their output, etc. But > as we know i18n is difficult, and perhaps only John Klensin > has the expertise to get this right anyway. :-) That's partly > why in general we based PRECIS on the same technical approach > taken in IDNA. I know only three things: (1) How little I actually know, an assessment that gets worse with each passing week and problem. (2) How badly some approaches can lead us astray and into problems, including the Law of Least Astonishment one and its relationship to profiles in this area. (3) Following up Peter's comment, how dangerously close to burning out I get at regular intervals, sometimes unfortunately resulting in tuning out as a self-preservation measure. The latter got me several times during PRECIS discussions, in large measure because the whole approach that could lead to "one application, one profile" struck me as so profoundly wrong. I couldn't get the WG to address that issue and investing energy in fine-tuning documents that reflected that approach just didn't seem productive. john p.s. The W3C i18n WG has had an action item on its agenda since late (Northern Hemisphere) summer to note the differences between the evolving PRECIS approach and that of the Charmod revision, differences in string matching, and some normalization concerns. From the viewpoint of my "too many profiles" concerns, Charmod is yet another profile approach as is UAX31 ("Unicode Identifier and Pattern Syntax"). I did mention on their call today that the action item is probably OBE but, if anyone wants to pursue those differences, the contact points are Addison Phillips and Richard Ishida From nobody Thu Apr 24 10:41:01 2014 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 75EF41A0332; Thu, 24 Apr 2014 10:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.573 X-Spam-Level: X-Spam-Status: No, score=-4.573 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, RP_MATCHES_RCVD=-0.272, 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 0fKvJqfbNuHG; Thu, 24 Apr 2014 10:40:54 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id E94B11A0227; Thu, 24 Apr 2014 10:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1398361248; x=1429897248; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=RCxtqtKQyDpOoa6gDv6xG91a2Ki042l7MOjtBAkXMec=; b=pp4DVCsMWwfRRexxA5axyQO4CPjuukZEK5qq9a06aCou4PBAuJc4vo5M eG/Q1HMKF7f3w98K+oAnXvGw3bjroW82PcqG9jZpSBmOqPyjsGSzhxgn4 lX27zE2TLd221okr6T34pnKqWfo5QnNyJ9vObYye+RG8f/FsvL1fZ5HNT 4=; X-IronPort-AV: E=McAfee;i="5400,1158,7418"; a="122056722" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by wolverine02.qualcomm.com with ESMTP; 24 Apr 2014 10:40:47 -0700 X-IronPort-AV: E=Sophos;i="4.97,920,1389772800"; d="scan'208";a="29518320" Received: from nasanexhc15.na.qualcomm.com ([129.46.52.215]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 24 Apr 2014 10:40:47 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc15.na.qualcomm.com (129.46.52.215) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Apr 2014 10:40:47 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Apr 2014 10:40:46 -0700 Message-ID: <53594C9C.1080507@qti.qualcomm.com> Date: Thu, 24 Apr 2014 12:40:44 -0500 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: <20140409190744.15518.7195.idtracker@ietfa.amsl.com> <6C520F47E0BA6CEF00EF649B@JcK-HP8200.jck.com> In-Reply-To: <6C520F47E0BA6CEF00EF649B@JcK-HP8200.jck.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/precis/ugVp8B6V7tzDhq7tPM-S9bZR8Xc Cc: ietf@ietf.org, precis@ietf.org Subject: Re: [precis] Last Call: (PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols) to Proposed Standard 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, 24 Apr 2014 17:40:56 -0000 John, Peter has had a start on answering these meat of the issues, and unless there are objections (by you, or anyone else), I'd ask that the remainder of the technical discussion be taken to the precis mailing list alone. That said, a couple process points that I think are appropriate to discuss here: On 4/23/14 11:17 PM, John C Klensin wrote: > I have deliberately waited until the end of the Last Call period > as posted [1], hoping that you would get (or generate) more > focused comments on the draft in the interim. Please don't do that in the future. In this particular case (and mea culpa for this), I completely missed this note before the IESG telechat started, and wish we could have had this discussion going before the IESG got the document. In the end, the outcome is as per your first recommendation anyway: > Recommendation: Tentatively approve the document now if that > seems otherwise justified (I suggest below that it is not) but > do not issue a Protocol Action Notice or handoff to the RFC > Editor until after a sufficient number of of "profile > replacements" and "guidelines" have been completed and examined > through the IETF Last Call process to validate the "framework" > provisions. The IESG tentatively approved the document today, but it's announcement is contingent on a final review by me and a writeup. (In the datatracker, you'll see this recorded as "Approved::Point Raised".) I was going to do that anyway to deal with other comments that came up during AD Evaluation and Last Call, but I'll take your comments into account as well. If we end up in a place where I think we need to bring it back to the IESG, I can always do that. But I do want to comment on the overall process issue: > The issues > discussed in this note were raised while what became the PRECIS > WG (originally known by names like "Stringprep-bis") was being > discussed and chartered and again on several occasions during > the meetings of the WG. At least in my opinion, they were > never discussed seriously: the WG made one important improvement > (shifting to a rule-based inclusion approach) but has > essentially ignored the fundamental problem. Because the > predecessors of this note have not been actively considered in > the WG or while its charter was being created, I don't actually > expect it to accomplish anything other than to get some issues > on the record. But I think the circumstances require one last > try. > As much as we've failed in many ways to keep the spirit of our procedures alive, they do still exist. The IETF is *not* supposed to be another of the "formal review" SDOs where nothing happens until formal last calls and final reviews. We are supposed to be running a process where consensus is *built* during document creation, and importantly where failures are identified early and throughout the process, not late. Part of the way the IETF operates is that we *don't* wait until it's a big formal deal to address problems. Part of the social contract is that participants take responsibility for that and make their concerns known while consensus building is still going on. We talk a lot in the IESG about how to push things back earlier in the process, to not have late surprises and to not rely on things like formal DISCUSSes of the IESG for getting good work out of the IETF. Participants have to be part of that as well and use the tools we have to make sure that our process operates effectively. RFC 2026, Section 6.5.1, defines what to do if a participant's views have not been adequately considered by the Working Group or that the Working Group has made an incorrect technical choice. In particular, the first step is to approach the chairs directly, at which point the chairs are supposed to figure out how to resolve the matter, bringing in other members of the WG (or the WG as a whole) when needed. If that doesn't work, *then* you bring that concern to the AD to attempt to resolve. (And of course, after that you can appeal to the IESG.) The PRECIS WG has been discussing this document for round about three years. The WG made the decision to send this document to the IESG two months ago. I do not know whether you discussed this matter directly with the chairs, but I know that you have not discussed it directly with me. If you hadn't come to the conclusion that things had gone off the rails until recently, there's not much that you could have done differently, but my sense from your message is that you have had this concern for quite some time and that the WG has been missing it. (Indeed, I have been following PRECIS better than some of my WGs, and I know I've been in the room at f2f sessions, and *I* missed that you had this concern.) This concern should have been escalated long ago. You should have followed 2026/6.5.1 and brought this to the chairs, and then to me as the AD if you weren't getting heard. The IETF only works when all participants take the responsibility to raise concerns during the process. If the senior members of the community aren't going to take that responsibility, why are we surprised when people are discouraged about how our processes work? As I said, I'll review these concerns, and I'll take the document back to the IESG (or even the WG) if that is warranted. But this isn't the way the process is supposed to work. Disappointedly, pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Thu Apr 24 18:07:24 2014 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 31B411A03AB for ; Thu, 24 Apr 2014 09:21:34 -0700 (PDT) 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 V6RjDxGSYNhC; Thu, 24 Apr 2014 09:21:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4721A037A; Thu, 24 Apr 2014 09:21:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: precis-chairs@tools.ietf.org, draft-ietf-precis-framework@tools.ietf.org, precis@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140424162133.12107.58095.idtracker@ietfa.amsl.com> Date: Thu, 24 Apr 2014 09:21:33 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/precis/qMYuv9_X_GSx6jvs-eeP19QEH24 X-Mailman-Approved-At: Thu, 24 Apr 2014 18:07:22 -0700 Subject: [precis] ID Tracker State Update Notice: 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, 24 Apr 2014 16:21:34 -0000 IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-precis-framework/ From nobody Thu Apr 24 18:07:45 2014 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 B8B941A02AD; Thu, 24 Apr 2014 09:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.151 X-Spam-Level: X-Spam-Status: No, score=-3.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, MISSING_HEADERS=1.021, RP_MATCHES_RCVD=-0.272] 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 GP6vOrqVptHn; Thu, 24 Apr 2014 09:36:45 -0700 (PDT) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) by ietfa.amsl.com (Postfix) with ESMTP id B9C071A028B; Thu, 24 Apr 2014 09:36:45 -0700 (PDT) Received: from request1.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id s3OGadMB001176; Thu, 24 Apr 2014 16:36:39 GMT Received: by request1.lax.icann.org (Postfix, from userid 48) id C3EC35606D8; Thu, 24 Apr 2014 16:36:39 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: <53585CE3.2030506@stpeter.im> References: <20140409190744.15518.43045.idtracker@ietfa.amsl.com> <53585CE3.2030506@stpeter.im> Message-ID: Precedence: bulk X-RT-Loop-Prevention: IANA RT-Ticket: IANA #757297 Managed-BY: RT 4.0.8 (http://www.bestpractical.com/rt/) RT-Originator: pearl.liang@icann.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Thu, 24 Apr 2014 16:36:39 +0000 Archived-At: http://mailarchive.ietf.org/arch/msg/precis/aBy2IEgdvg81lhMdkWkgXXTA72w X-Mailman-Approved-At: Thu, 24 Apr 2014 18:07:44 -0700 Cc: liang@icann.org, draft-ietf-precis-framework@tools.ietf.org, iesg@ietf.org, precis@ietf.org, precis-chairs@tools.ietf.org Subject: [precis] [IANA #757297] Re: Last Call: (PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols) to Proposed Standard X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Reply-To: iana-issues@iana.org List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 16:36:47 -0000 Hi, Please see inline comments. On Thu Apr 24 00:56:22 2014, stpeter@stpeter.im wrote: > On 4/22/14, 9:53 AM, Pearl Liang via RT wrote: > > (BEGIN IANA LAST CALL COMMENTS) > > > > IESG/Authors/WG Chairs: > > > > IANA has reviewed draft-ietf-precis-framework. Authors should > review the comments and/or questions below. Please report any > inaccuracies and respond to any questions as soon as possible. > > > > IANA's reviewer has the following comments/questions: > > > > IANA has a few questions about the IANA actions requested in this > document. > > > > This document requests the creation of three registries in support > of the PRECIS Framework. As far as IANA can tell, there have never > been registries created for PRECIS in the past. > > Correct. > > > IANA Question --> should the three registries that are requested in > this document be combined into a singlee, high-level PRECIS master > registry where the three new registries would reside? > > That seems reasonable. > > These PRECIS registries are very similar to the IDNA registries: > > http://www.iana.org/assignments/idna-tables-6.3.0/idna-tables- > 6.3.0.xhtml > > As much as possible, I would respectfully suggest that we follow the > same practices here as for the IDNA registries. > WOW. Are you saying that new versions of PRECIS Derived Property Values will be announced via a public notification mailing list, similar to the announcement for new version so Unicode? That idna table registry was setup, configured and coded by Marc's team. If that is the format, Marc's team needs to create that tool to generate every new version of this registry. > > Is PRECIS a brand new parameter, or a new protocol of an existing > one? > > PRECIS is a brand new protocol, similar to IDNA but applying more > generally. > > > If the former that PRECIS is a brand new parameter, what’s the exact > name of the new registry? Is Preparation and Comparison of > Internationalized Strings in Application Protocols? > > That seems good to me. > Can you please add this information in section 9 before 9.1? > > IANA understands that, upon approval of this document, there are > three actions which IANA must complete. > > > > First, IANA will create a new registry called the PRECIS Derived > Property Value Registry. This new registry will contain the Derived > Properties for the versions of Unicode that are released after (and > including) version 6.3 of Unicode. The derived property value is to > be calculated in cooperation with a designated expert [RFC5226] > according to the rules specified under Section 7 and Section 8 in > the current document. The registry will only be created when a > designated expert is made available to assist IANA in the > initiation of the registry. Changes to the rules that are used to > generate the table of derived property values, and thus the > registry itself, are done through IETF Review as defined by RFC > 5226. > > > > QUESTION: Are the authors intended to get an DE before IESG > Approval? > > Pete Resnick is following up on this. > Sure. > > Second, IANA will create a new registry called the PRECIS Base > Classes Registry. This new registry has a registration template in > the document submitted for approval. Maintenance of the registry > will be through RFC Required, as defined in RFC 5226. > > > > There are two initial registrations in the registry, as follows: > > > > Base Class: FreeformClass. > > Description: A sequence of letters, numbers, symbols, spaces, and > > other code points that is used for free-form strings. > > Specification: Section 3.3 of [ RFC-to-be ]. > > > > Base Class: IdentifierClass. > > Description: A sequence of letters, numbers, and symbols that is > > used to identify or address a network entity. > > Specification: Section 3.3 of [ RFC-to-be ]. > > Correct, except the second instance of "Section 3.3" is incorrect in > the > I-D and should be "Section 3.2". > > > Third, IANA will create a new registry called the PRECIS Profiles > Registry. This new registry has a registration template in the > document submitted for approval. Maintenance of the registry will > be through Expert Review, as defined in RFC 5226. > > > > IANA Question -> Are there to be any initial registrations in the > new PRECIS Profiles Registry? > > No. However, just so you are aware, registrations are forthcoming in > the > following I-Ds: > > draft-ietf-precis-nickname > draft-ietf-precis-saslprepbis > draft-ietf-xmpp-6122bis > No, we do not know and we have no way to track what registrations are tied to what I-Ds. So, it'd be helpful if: - the authors of those I-Ds identify this document draft-ietf-precis-framework in the IC section for reference. We mainly focus on the IC section and will notice related I-Ds if they are being cited in the section. - the precis WG chairs can help to coordinate all I-Ds that will update the same registry. > > IANA understands that these three actions are the only ones that > need to be completed upon approval of this document. > > Agreed. > > > Note: The actions requested in this document will not be completed > > until the document has been approved for publication as an RFC. > > This message is only to confirm what actions will be performed. > > > > Thanks, > > > > Pearl Liang > > Thank you, Pearl! > > Peter > > From nobody Mon Apr 28 13:23:30 2014 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 E69551A7D82 for ; Mon, 28 Apr 2014 13:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.552 X-Spam-Level: X-Spam-Status: No, score=-14.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 EhrTIERcKC3N for ; Mon, 28 Apr 2014 13:23:21 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0451A797C for ; Mon, 28 Apr 2014 13:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2371; q=dns/txt; s=iport; t=1398716600; x=1399926200; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=N0vtmEkN1pkXt+eVcfqdi1ijzQYme3/V1R0mCrMOSnU=; b=Coa0WMzaKmjbOA7XRzdD2dt86HGFqpF7EcpuZFDJW1Mhc/YDGOLb/4+/ KViwIoftxcE5NQq2uPBY//fc7Bis29jdX+KWZ4fl7AFGBoXec+YY1L6yX 8QoJbnkMjkxCYcxknxKONw6BQmALyp/UPWdckZZ37eqVtand0HJLNV3Dn A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQFAMG3XlOtJA2H/2dsb2JhbABZgwZPV6psAQEBBZI9hzmBGxZ0giUBAQEEAQEBLwE4AwoNBBwDAQIKFg8JAwIBAgEVJgIIBg0GAgEBBYg4Dch7F4VaiC4BAVYGhDMEiTc6jxuBOpEkg1CBUzk X-IronPort-AV: E=Sophos;i="4.97,946,1389744000"; d="scan'208";a="320982284" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-5.cisco.com with ESMTP; 28 Apr 2014 20:23:20 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3SKNKon015551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 28 Apr 2014 20:23:20 GMT Received: from MAMILLE2-M-T03K.local (10.129.24.57) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 28 Apr 2014 15:23:19 -0500 Message-ID: <535EB8B7.8050406@cisco.com> Date: Mon, 28 Apr 2014 14:23:19 -0600 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: IETF PRECIS WG References: <535EB227.6050300@cisco.com> In-Reply-To: <535EB227.6050300@cisco.com> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <535EB227.6050300@cisco.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.129.24.57] Archived-At: http://mailarchive.ietf.org/arch/msg/precis/zmWPxpGa6qKSRa-AzWK90kZMVII Subject: [precis] Fwd: [Json] I-JSON Topic #3: Unicode 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, 28 Apr 2014 20:23:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I realize this is mostly off-topic for this WG, but I also think there's a good chance to solicit UNICODE expertise here. The JSON WG is working on restricted profile of JSON ([I-JSON]), and one of the restrictions are on what is acceptable Unicode. What was acceptable in RFC 7159 (as well as RFC 4627, ECMA 262, and ECMA 404) is frankly atrocious, but could not be completely fixed in those documents for a myriad of reasons. The intent of I-JSON is to tell its users "don't do that". We would really appreciate if someone here can read through draft-bray-i-json-01 2.1. and help us make it as correct as we can. The relevant discussion starts with < http://www.ietf.org/mail-archive/web/json/current/msg02782.html > on the mailing list "json@ietf.org". Thank you in advance, - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. [I-JSON] "The I-JSON Message Format" < http://tools.ietf.org/html/draft-bray-i-json > - -------- Original Message -------- Subject: [Json] I-JSON Topic #3: Unicode Date: Mon, 28 Apr 2014 13:55:19 -0600 From: Matt Miller To: IETF JSON WG "draft-i-json-01 excludes the use of, and I quote, 'Surrogates or Noncharacters'. Is that the right use of Unicode nomenclature? This really matters and I think it?s OK now, but first-class Unicode lawyering is required here." If you have suggestions for better text -- or if you believe the current text is adequate -- please respond to this thread with your suggestions or reasoning. _______________________________________________ json mailing list json@ietf.org https://www.ietf.org/mailman/listinfo/json -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTXri3AAoJEDWi+S0W7cO1nxIIAJpYRDLSwVaZznqk1+XO2N+t rFvatansPQsAi2N2UX9wOFDtOXdps+BT8lRtRk4UtY6+zZg7pZhwlmH5fX5S0WKz b95wMLzSeoF5ScRYQKJmTUAY2VbEjWYw6NvLFJvL6Uyj5b6LKnrM+/89jetfi133 Dk2YFkacFIqVr0jj4z+KkYhwypP5zcnn7drDf0rJFt9Q+cL5gxtIkGbeCSzS9J9p ScGCwEsnhiU4lBlGOr2i48uTt7XiI+gKv213tqduwlOtVRsqh9s+6tAbtcepzSak nWVS0jcOpYsOwMZmxjmhFcau++AbEEsutJM2ATFKaP7PboIOpmgNzwRRHzTIQb8= =43NM -----END PGP SIGNATURE-----