From stpeter@stpeter.im Thu Sep 13 14:08:16 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2986421F8592 for ; Thu, 13 Sep 2012 14:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.682 X-Spam-Level: X-Spam-Status: No, score=-102.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wf-dkuee-99M for ; Thu, 13 Sep 2012 14:08:14 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CE4F021F8643 for ; Thu, 13 Sep 2012 14:08:14 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E4E2540D96 for ; Thu, 13 Sep 2012 15:08:59 -0600 (MDT) Message-ID: <50524B3C.9080500@stpeter.im> Date: Thu, 13 Sep 2012 15:08:12 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "precis@ietf.org" References: <20120913210629.12923.17349.idtracker@ietfa.amsl.com> In-Reply-To: <20120913210629.12923.17349.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.4 X-Forwarded-Message-Id: <20120913210629.12923.17349.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [precis] Fwd: I-D Action: draft-melnikov-precis-saslprepbis-02.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 21:08:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI. - -------- Original Message -------- Subject: I-D Action: draft-melnikov-precis-saslprepbis-02.txt Date: Thu, 13 Sep 2012 14:06:29 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Preparation and Comparison of Internationalized Strings Representing Simple User Names and Passwords Author(s) : Peter Saint-Andre Alexey Melnikov Filename : draft-melnikov-precis-saslprepbis-02.txt Pages : 11 Date : 2012-09-13 Abstract: This document describes how to handle Unicode strings representing simple user names and passwords, primarily for purposes of comparison. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN and SCRAM-SHA-1), as well as other protocols that exchange simple user names or user passwords. This document obsoletes RFC 4013. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-melnikov-precis-saslprepbis There's also a htmlized version available at: http://tools.ietf.org/html/draft-melnikov-precis-saslprepbis-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-melnikov-precis-saslprepbis-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBSSzwACgkQNL8k5A2w/vyaDACfTnwuB9+67qU9p4IlgIuFi1KI dtMAoNVsww33zSsxerlhcpZdSIQC7pzx =HCky -----END PGP SIGNATURE----- From stpeter@stpeter.im Thu Sep 13 14:26:03 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B89F421F8618 for ; Thu, 13 Sep 2012 14:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.662 X-Spam-Level: X-Spam-Status: No, score=-102.662 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4nbEZm9rAHQ for ; Thu, 13 Sep 2012 14:26:03 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4061721F860E for ; Thu, 13 Sep 2012 14:26:03 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8AFCA40D96 for ; Thu, 13 Sep 2012 15:26:49 -0600 (MDT) Message-ID: <50524F6A.5090204@stpeter.im> Date: Thu, 13 Sep 2012 15:26:02 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "precis@ietf.org" References: <50524F33.5090003@stpeter.im> In-Reply-To: <50524F33.5090003@stpeter.im> X-Enigmail-Version: 1.4.4 X-Forwarded-Message-Id: <50524F33.5090003@stpeter.im> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [precis] Fwd: [kitten] changing "mapped to nothing" in SASLprep-bis X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 21:26:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI (following up on open issues from the Vancouver meeting)... - -------- Original Message -------- Subject: [kitten] changing "mapped to nothing" in SASLprep-bis Date: Thu, 13 Sep 2012 15:25:07 -0600 From: Peter Saint-Andre To: kitten@ietf.org Dear SASL experts, RFC 4013 states that certain Unicode code points that are commonly mapped to nothing (see Appendix B.1 of RFC 3454) can indeed be so mapped when preparing passwords (and usernames) in SASLprep. In working on draft-melnikov-precis-saslprepbis (which is intended to obsolete RFC 4013), Alexey Melnikov and I have followed the general approach of the PRECIS framework (and before that IDNA2008) by specifying that such code points would simply be disallowed. In Unicode 3.2 there are only 27 code points that are affected by this rule (e.g., U+00AD = SOFT HYPHEN), and since currently they are mapped to nothing they would not be stored in an authentication database. However, users might have included such characters in their usernames or passwords and thus might expect to input those characters when providing usernames or passwords for authentication purposes. Therefore, if we change these code points from "mapped to nothing" to disallowed, it is possible a small number users might experience an error when inputting these characters with updated versions of their software, instead of the smooth operation they experienced in the past. Alexey and I would like to solicit feedback on this issue from participants in the KITTEN WG and especially from those who have implemented and deployed software that uses SASLprep. Please send your feedback to the kitten@ietf.org list or directly to me and Alexey. Thanks! Peter _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBST2oACgkQNL8k5A2w/vyTAwCeNrPbFeFTvj/qvYpsE2PRb/bs Fs0An2df/4NHg03Dw4WR32bqStlDmvS2 =ZTZQ -----END PGP SIGNATURE----- From stpeter@stpeter.im Fri Sep 14 09:25:19 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A88A421F8514 for ; Fri, 14 Sep 2012 09:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.649 X-Spam-Level: X-Spam-Status: No, score=-102.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1Sz8UWw6Xwb for ; Fri, 14 Sep 2012 09:25:19 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5B76021F8484 for ; Fri, 14 Sep 2012 09:25:17 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CA93C404FF for ; Fri, 14 Sep 2012 10:26:05 -0600 (MDT) Message-ID: <50535A6B.8010702@stpeter.im> Date: Fri, 14 Sep 2012 10:25:15 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "precis@ietf.org" References: <20120914162208.30845.65648.idtracker@ietfa.amsl.com> In-Reply-To: <20120914162208.30845.65648.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.4 X-Forwarded-Message-Id: <20120914162208.30845.65648.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [precis] Fwd: I-D Action: draft-melnikov-precis-saslprepbis-03.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 16:25:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry, in -02 we had neglected to update the spec regarding Pete Resnick's feedback about bidirectionality of passwords. Alexey and I have addressed that now, thus the quick -03 release (changing one paragraph at the end of Section 3.2). Peter - -------- Original Message -------- Subject: I-D Action: draft-melnikov-precis-saslprepbis-03.txt Date: Fri, 14 Sep 2012 09:22:08 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Preparation and Comparison of Internationalized Strings Representing Simple User Names and Passwords Author(s) : Peter Saint-Andre Alexey Melnikov Filename : draft-melnikov-precis-saslprepbis-03.txt Pages : 11 Date : 2012-09-14 Abstract: This document describes how to handle Unicode strings representing simple user names and passwords, primarily for purposes of comparison. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN and SCRAM-SHA-1), as well as other protocols that exchange simple user names or passwords. This document obsoletes RFC 4013. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-melnikov-precis-saslprepbis There's also a htmlized version available at: http://tools.ietf.org/html/draft-melnikov-precis-saslprepbis-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-melnikov-precis-saslprepbis-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBTWmsACgkQNL8k5A2w/vzKAgCfcJVptes7qR3TrlAtixpNkhNy Y7kAoIH4CTjhL/9qBqPwVo/r/bWq55Xr =F64+ -----END PGP SIGNATURE----- From marc.blanchet@viagenie.ca Fri Sep 14 10:50:17 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9159B21F84B2 for ; Fri, 14 Sep 2012 10:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqkBN-+Q4KJ0 for ; Fri, 14 Sep 2012 10:50:16 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id D81DC21F84A1 for ; Fri, 14 Sep 2012 10:50:16 -0700 (PDT) Received: from h99.viagenie.ca (h99.viagenie.ca [206.123.31.99]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 23863425E9 for ; Fri, 14 Sep 2012 13:50:16 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1278) From: Marc Blanchet In-Reply-To: <50535A6B.8010702@stpeter.im> Date: Fri, 14 Sep 2012 13:50:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120914162208.30845.65648.idtracker@ietfa.amsl.com> <50535A6B.8010702@stpeter.im> To: precis@ietf.org X-Mailer: Apple Mail (2.1278) Subject: Re: [precis] Fwd: I-D Action: draft-melnikov-precis-saslprepbis-03.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 17:50:17 -0000 It would be good to have members to review this document. Any takers? Marc. Le 2012-09-14 =E0 12:25, Peter Saint-Andre a =E9crit : > Sorry, in -02 we had neglected to update the spec regarding Pete > Resnick's feedback about bidirectionality of passwords. Alexey and I > have addressed that now, thus the quick -03 release (changing one > paragraph at the end of Section 3.2). >=20 > Peter >=20 > - -------- Original Message -------- > Subject: I-D Action: draft-melnikov-precis-saslprepbis-03.txt > Date: Fri, 14 Sep 2012 09:22:08 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : Preparation and Comparison of = Internationalized > Strings Representing Simple User Names and Passwords > Author(s) : Peter Saint-Andre > Alexey Melnikov > Filename : draft-melnikov-precis-saslprepbis-03.txt > Pages : 11 > Date : 2012-09-14 >=20 > Abstract: > This document describes how to handle Unicode strings representing > simple user names and passwords, primarily for purposes of > comparison. This profile is intended to be used by Simple > Authentication and Security Layer (SASL) mechanisms (such as PLAIN > and SCRAM-SHA-1), as well as other protocols that exchange simple > user names or passwords. This document obsoletes RFC 4013. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-melnikov-precis-saslprepbis >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-melnikov-precis-saslprepbis-03 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-melnikov-precis-saslprepbis-03 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 From mamille2@cisco.com Fri Sep 14 10:59:22 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6273521F852C for ; Fri, 14 Sep 2012 10:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNkhvDppW89S for ; Fri, 14 Sep 2012 10:59:21 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 84D1A21F84DF for ; Fri, 14 Sep 2012 10:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7047; q=dns/txt; s=iport; t=1347645561; x=1348855161; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Kh/g1UB7Irddj7mVsAgvm0JmbLv8aue1b7BGbcbxc7Q=; b=THtCPMJB/YuVm65gNTF/jXAe2HBzUpa37OLitoeqry16gzbgFBVCr9Gn 3Wg51RfD2JF06FEWBes+sk2ZdR2W86iHyiwSati8lUvYVzVAhW75R4Isz shtiYbAiu3H0RGFExfpzKuwGPnpwf61bbjJ6NYtxqhZTYHRwtOK46hRPc A=; X-Files: smime.p7s, PGP.sig : 2214, 535 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAA5wU1CtJXHA/2dsb2JhbABFvAKBB4IgAQEBAwEBAQEPAVsLBQcEAgEIEQMBAi8CJQsUCQgCBA4FCQUUh2UGC5s8oCOLFYYIYAOOaYEghViBFIoGgx6BaYJmghc X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="sig'?p7s'?scan'208";a="121723335" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 14 Sep 2012 17:59:21 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8EHxK81017943 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Sep 2012 17:59:21 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.219]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0298.004; Fri, 14 Sep 2012 12:59:20 -0500 From: "Matt Miller (mamille2)" To: Marc Blanchet Thread-Topic: [precis] Fwd: I-D Action: draft-melnikov-precis-saslprepbis-03.txt Thread-Index: AQHNkqFrL1wd8dQUnUW/2yN+kjmd95eKc+MA Date: Fri, 14 Sep 2012 17:59:20 +0000 Message-ID: <28C5DC14-8A46-4612-813F-1D5EB696775B@cisco.com> References: <20120914162208.30845.65648.idtracker@ietfa.amsl.com> <50535A6B.8010702@stpeter.im> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-pgp-agent: GPGMail 1.3.3 x-originating-ip: [64.101.72.40] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19182.004 x-tm-as-result: No--39.496000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-8--28826498" MIME-Version: 1.0 Cc: "" Subject: Re: [precis] Fwd: I-D Action: draft-melnikov-precis-saslprepbis-03.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 17:59:22 -0000 --Apple-Mail-8--28826498 Content-Type: multipart/signed; boundary=Apple-Mail-7--28826506; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail-7--28826506 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I've got it open to review now (-: - m&m Matt Miller - Cisco Systems, Inc. On Sep 14, 2012, at 11:50, Marc Blanchet wrote: > It would be good to have members to review this document. Any takers? >=20 > Marc. >=20 > Le 2012-09-14 =E0 12:25, Peter Saint-Andre a =E9crit : >=20 >> Sorry, in -02 we had neglected to update the spec regarding Pete >> Resnick's feedback about bidirectionality of passwords. Alexey and I >> have addressed that now, thus the quick -03 release (changing one >> paragraph at the end of Section 3.2). >>=20 >> Peter >>=20 >> - -------- Original Message -------- >> Subject: I-D Action: draft-melnikov-precis-saslprepbis-03.txt >> Date: Fri, 14 Sep 2012 09:22:08 -0700 >> From: internet-drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>=20 >>=20 >> Title : Preparation and Comparison of = Internationalized >> Strings Representing Simple User Names and Passwords >> Author(s) : Peter Saint-Andre >> Alexey Melnikov >> Filename : draft-melnikov-precis-saslprepbis-03.txt >> Pages : 11 >> Date : 2012-09-14 >>=20 >> Abstract: >> This document describes how to handle Unicode strings representing >> simple user names and passwords, primarily for purposes of >> comparison. This profile is intended to be used by Simple >> Authentication and Security Layer (SASL) mechanisms (such as PLAIN >> and SCRAM-SHA-1), as well as other protocols that exchange simple >> user names or passwords. This document obsoletes RFC 4013. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-melnikov-precis-saslprepbis >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-melnikov-precis-saslprepbis-03 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-melnikov-precis-saslprepbis-03= >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>=20 >>=20 >=20 > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis --Apple-Mail-7--28826506 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDkxNDE3NTky MVowIwYJKoZIhvcNAQkEMRYEFGsv63SbaqiX8/o9QvqcK7KoO2a6MIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQBLNM/YcTGj0fZUXguYXwGd+PG//XdqLX/MwIlJuLtaaCjV1guF45MC/dEn EQFqW2Q4+uauWlkNBY5BA+hS/JhU8Me5fxBCqAuTAati36/LWSepROypO+XMCYviMEl/Pqapm58y 4PQTLP+eYOxSS7vMT5WH1jXW1prLRjJYYwdPDexgg2f9cNsyRa8XK2E9sa9tUDYCMSMZcfGksUgW MfU3j4H77h0uwYbnP6SxfDkZGZYOJR/wHhlP52WRYlJlIPQx48adOcVVzLH9Oh2wR+hAyDCJ76s0 tfaQDM1fWZq+iYHn4ZZgyhJAWcnP8YtxdL/Rl0Mq4od5bNZNXQFiUb6VAAAAAAAA --Apple-Mail-7--28826506-- --Apple-Mail-8--28826498 Content-Type: application/pgp-signature; x-mac-type=70674453; name="PGP.sig" Content-Description: This is a digitally signed message part Content-Disposition: inline; filename="PGP.sig" Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJQU3B5AAoJEJq6Ou0cgrSP/xkIAIyP7OZzihMAmRPqQvfB0KAH 1+c9YrfmirYorGhiDGEwIFEO/Ha7BI8NofSB/ZCimdjLq2vzDOll4gmmAuOdWcvj 8/gGDyZCItpYgu+TvYecsFDbzOgRVz/ZBnGq/WNEktG5w5+O3RRnCtLMmn7YVfiS ZcZb8kC2YaY4JIvDcLpfasf0c/Lu4434P22257QSy0Qmt3u+4GGMWT0UfvkBCg76 bggj5W35RQFeUHU/lNo/IP9dRaDKA3EcyU1oo4JVXQFVigzdSQ2nCaKyUChTCxo1 QZ7DiHmGwhqETAIGURBqFiRxJ6/s3QjC7lgXFYuTZnn36Yty5F4NUj//aCBi9Ww= =c8Qt -----END PGP SIGNATURE----- --Apple-Mail-8--28826498-- From stpeter@stpeter.im Mon Sep 17 08:43:59 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A9D21F867E for ; Mon, 17 Sep 2012 08:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.624 X-Spam-Level: X-Spam-Status: No, score=-102.624 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Q8bqTX0gsI2 for ; Mon, 17 Sep 2012 08:43:59 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB7121F8667 for ; Mon, 17 Sep 2012 08:43:59 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A3C0740D52 for ; Mon, 17 Sep 2012 09:44:57 -0600 (MDT) Message-ID: <5057453D.1040502@stpeter.im> Date: Mon, 17 Sep 2012 09:43:57 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "precis@ietf.org" References: <50569984.10301@it.aoyama.ac.jp> In-Reply-To: <50569984.10301@it.aoyama.ac.jp> X-Enigmail-Version: 1.4.4 X-Forwarded-Message-Id: <50569984.10301@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: [precis] Fwd: Re: [http-auth] http-auth BOF X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 15:43:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Of interest regarding SASLprep... - -------- Original Message -------- Subject: Re: [http-auth] http-auth BOF Date: Mon, 17 Sep 2012 12:31:16 +0900 From: "Martin J. Dürst" Organization: Aoyama Gakuin University To: KIHARA, Boku CC: Peter Saint-Andre , "http-auth@ietf.org" I wanted to make exactly the same comment as Mr. Kihara. To give a simple example, when inputting the character/word "flower", most Japanese would type the four keys 'h', 'a', 'n', 'a', which simply corresponds to the pronunciation of that word, "hana". This is then converted to syllabic writing "はな", and from there to the actual character for flower, "花", as it would be used in everyday writing. However, there are other characters that are pronounced "hana", such as "華" (a variant character for flower), "鼻" (nose), and so on. To select the correct character, various keys (space, arrow keys, number keys, return,...) are used. To make sure the right character is selected, the user has to *visually* check (-> shoulder attack) and confirm it. As a result, as Mr. Kihara already explained, these characters are not used for passwords in Japanese. Because the same homophone problem for Han characters applies in Chinese and Korean, the situation is the same there. In terms of entropy, Han characters would indeed contribute a lot, but because they require visual checking when entering, they are in general not suited for passwords. Regards, Martin. On 2012/09/15 3:35, KIHARA, Boku wrote: > 2012/9/15 Peter Saint-Andre: >> On 9/14/12 9:09 AM, KIHARA, Boku wrote: >>> I heard a discussion about i18n of passwords: >>> about Chinese characters (of course used in Japan too), there >>> are many characters that have the same pronunciations so they >>> are input by input method software. Users type sentences in >>> latin characters (such as pinyin and roma-ji) then pick >>> intended characters from candidates. When inputting passwords, >>> typically input method software are disabled and userstype >>> unconverted characters. As a result, passwords become within >>> ascii range. The problem might be more noticeable in non-ascii >>> locales where characters are input directly from keyboards. >> >> Hello Kihara-san, >> >> Could you please clarify what you mean by "unconverted >> characters"? It seems that you mean these are characters from the >> ASCII range not converted into their CJ equivalents, but I'd like >> to make sure. > > Exactly. I meant they are ASCII characters that are not processed > by input method software. In Japan, the input process is often > called "Kanji Henkan" (Chinese characters conversion) so I used the > word. > >>> By the way, I think i18ning passwords in at least CJ locales >>> will cause another problem that conversion process can be >>> vulnerable to shoulder attacks :< >> >> When you say "i18ning passwords", do you mean allowing >> characters outside the ASCII range? >> >> Of course, we like to enable lots of entropy in passwords, so >> limiting the allowable characters to the ASCII range would be at >> odds with that desire. > > By all means passwords should become more secure and allowing > non-ASCII characters is very good way. I only intended to notice > that there may be issues to be solved and I am sorry if my message > was misleading. > >> By the way, some of these considerations are relevant to SASLprep >> (RFC 4013) and its proposed replacement >> (draft-melnikov-precis-saslprepbis), so I hope you will review >> the latter specification and provide feedback on the >> precis@ietf.org and kitten@ietf.org lists. :) > > Sure. I hope my little knowledge can help...:< > > Regards, Boku KIHARA > _______________________________________________ http-auth mailing > list http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBXRT0ACgkQNL8k5A2w/vyBnQCgqHqmsFLuNJIPqa6YzeQVHotc 8xMAni0OJ+lRavA1CHfc5m+H5imQ+87U =+6Ex -----END PGP SIGNATURE----- From mamille2@cisco.com Mon Sep 17 11:09:36 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028C421F86DF for ; Mon, 17 Sep 2012 11:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtBXYbso1nxW for ; Mon, 17 Sep 2012 11:09:35 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id DD58921F86A7 for ; Mon, 17 Sep 2012 11:09:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8440; q=dns/txt; s=iport; t=1347905375; x=1349114975; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Tw4PuEeJKECVFiBwwG9AvqeEsqUB8rM3jeEr/mdOnn8=; b=NKi0X6/MjBuuFgkEuljH+8ayEsG2BvpeyK/ZImLg5E2YnNwehTrir2rp f1AlmgPKk8+VEyAq2LMXlbyg3uw5p7NCDbvd40Yp4cDrmVevzdz1Anyry 2htrzHc3CL1kOC1jLgdCPBc5X9qb2ZvfiuZ/AP8CW5X/y9hQeZtqj75XT U=; X-Files: smime.p7s, PGP.sig : 2214, 535 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADhmV1CtJXG+/2dsb2JhbABEvCGBB4IgAQEBBAEBAQ8BWwsMBAIBGQMBAi8CJQsUCQgCBA4FCQUUh14Lmkefe4shhghgA45pgSCFWYEUigaDHoFpgmaCFw X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="sig'?p7s'?scan'208";a="122469451" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 17 Sep 2012 18:09:34 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8HI9YO2001024 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Sep 2012 18:09:34 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.219]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.001; Mon, 17 Sep 2012 13:09:34 -0500 From: "Matt Miller (mamille2)" To: Peter Saint-Andre Thread-Topic: Review of draft-melnikov-precis-saslprepbis-03 Thread-Index: AQHNlP+WokQ1fNsRykSn+UGgjKzevw== Date: Mon, 17 Sep 2012 18:09:33 +0000 Message-ID: <8FD6CBCE-60CD-4049-A0E6-B2388D6919DF@cisco.com> References: <20120914162208.30845.65648.idtracker@ietfa.amsl.com> <50535A6B.8010702@stpeter.im> In-Reply-To: <50535A6B.8010702@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-pgp-agent: GPGMail 1.3.3 x-originating-ip: [64.101.72.40] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19188.004 x-tm-as-result: No--43.680300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2-230986717" MIME-Version: 1.0 Cc: "precis@ietf.org" Subject: [precis] Review of draft-melnikov-precis-saslprepbis-03 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 18:09:36 -0000 --Apple-Mail-2-230986717 Content-Type: multipart/signed; boundary=Apple-Mail-1-230986712; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail-1-230986712 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This was started as a review of draft-melnikov-precis-saslprepbis-02. = -03 already addresses most of the questions and concerns I had with -02 = (-: regarding -03: * 2.3 (Simple User Names - Migration) :: It would be tremendously = helpful to have examples for each point raised. * 3.2 (Passwords - Preparation) :: I do wonder about the rationale for = step 2) (map all non-ASCII space to ASCII space). I myself have not run = into conditions where this would matter, but I mostly deal with US-based = consumers with passwords almost exclusively in the ASCII range. On the = surface, it seems a bit contradictory in principle to the "no bidi rule" = rationale that is included. I'm not advocating for retention or removal = of step 2), but rather for providing a rationale (one way or the other). * 3.3 (Passwords - Migration) :: It would be tremendously helpful to = have examples for each point raised. * I wonder if each migration section ought to be merged into something = larger. I do think that more needs to be said about the migration not = just of the data upon which the software operates on, but also of the = software itself. It is not common for client- and server-based software = to be updated in lockstep, and I can see questions coming up about it. - m&m Matt Miller - Cisco Systems, Inc. On Sep 14, 2012, at 10:25, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Sorry, in -02 we had neglected to update the spec regarding Pete > Resnick's feedback about bidirectionality of passwords. Alexey and I > have addressed that now, thus the quick -03 release (changing one > paragraph at the end of Section 3.2). >=20 > Peter >=20 > - -------- Original Message -------- > Subject: I-D Action: draft-melnikov-precis-saslprepbis-03.txt > Date: Fri, 14 Sep 2012 09:22:08 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : Preparation and Comparison of = Internationalized > Strings Representing Simple User Names and Passwords > Author(s) : Peter Saint-Andre > Alexey Melnikov > Filename : draft-melnikov-precis-saslprepbis-03.txt > Pages : 11 > Date : 2012-09-14 >=20 > Abstract: > This document describes how to handle Unicode strings representing > simple user names and passwords, primarily for purposes of > comparison. This profile is intended to be used by Simple > Authentication and Security Layer (SASL) mechanisms (such as PLAIN > and SCRAM-SHA-1), as well as other protocols that exchange simple > user names or passwords. This document obsoletes RFC 4013. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-melnikov-precis-saslprepbis >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-melnikov-precis-saslprepbis-03 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-melnikov-precis-saslprepbis-03 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ >=20 > iEYEARECAAYFAlBTWmsACgkQNL8k5A2w/vzKAgCfcJVptes7qR3TrlAtixpNkhNy > Y7kAoIH4CTjhL/9qBqPwVo/r/bWq55Xr > =3DF64+ > -----END PGP SIGNATURE----- > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis --Apple-Mail-1-230986712 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDkxNzE4MDkz NFowIwYJKoZIhvcNAQkEMRYEFKSSlvnw4GzCYoswuWHehurfjo5tMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQCW/jf90oPHp0Kfuvq197Q61+8cNmba0lC/zaQLCgrrjIdVxrodEDF2cLzp EzKEZOi2NA4jvQ26mHy+82hlFohcks34qurLioNhT92eV/mc67kk2kvDTYodTn+o6NXdRsv+8VkS o+sMXMkXn+FfEXoDlCOmJGLDsgYNeNJSWcJyLwVtbk0WxntUsT+rAVBsfS1ik2qchaZzRveNFl6b GBpQaULFdVqjRlTqtOsHL9Uj25VZvUbBc67dwx5yxbvvFB+4xuQleSfWrhOihG0HkSnvGJamyf0/ fYRE/t35FC2rJ9qYG0KRjMsWXyMBdkCafcSl8aTRBV/PX/9ecKSKe43dAAAAAAAA --Apple-Mail-1-230986712-- --Apple-Mail-2-230986717 Content-Type: application/pgp-signature; x-mac-type=70674453; name="PGP.sig" Content-Description: This is a digitally signed message part Content-Disposition: inline; filename="PGP.sig" Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJQV2deAAoJEJq6Ou0cgrSPsE4IAKYmc9e/gRPFBat8Z5PyNqDl HGFgdSPdwI+9NS2ztHQFTgYlqAQdhcROIX/h2gxkX2uTd/DuB2KraafLQT6euOjA zjeI6BNYvWK+MsU7seY/Xm34cou0weplPyxYbHdVfVYPk5fwX5qn9PF6tb2yvmls iTzfEEUr5Hq0M8OhcJG183WLaRSnfQE1vAxgl1sbTxBTK5vx/j1+bXnOa7Ieg2a0 dLOIVSZqnL9DK2L9IY9342GW006xVay+k1+CIXAZ4AYRta6CV0o8Z83MWIRaEVGs cd0qTx8SiqED8Fh+67XxsHvYHz3U+TXYurKZBgSEW3RrJZ5mOmaIIkXjxAc4Te0= =0yvV -----END PGP SIGNATURE----- --Apple-Mail-2-230986717-- From alexey.melnikov@isode.com Mon Sep 17 11:20:21 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E2621F8700 for ; Mon, 17 Sep 2012 11:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36O4fdX6lk+l for ; Mon, 17 Sep 2012 11:20:21 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id C98D421F86EA for ; Mon, 17 Sep 2012 11:20:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1347906019; d=isode.com; s=selector; i=@isode.com; bh=jd55oOh/qJcO3zd6NLmgMdsKKb9nPa5ogYVmgOrcMOc=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=PR5efSw+d5ZT+OvHGA58wk4KRJPiL1Ldg5gLb7JI6xkRwWDcjfw731YYjbGQ4PArn2lO/h IQumbrdiLmqb1yyRzWc+to3an2FPc1j8iy3WzYoOnkiAXJulh2PStYbrtdNwsbB+PZYcKz KY9J78p9zsSAbLyFCpglUvabSfrbs0M=; Received: from [192.168.1.3] ((unknown) [94.29.63.162]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 17 Sep 2012 19:20:19 +0100 X-SMTP-Protocol-Errors: NORDNS References: <20120914162208.30845.65648.idtracker@ietfa.amsl.com> <50535A6B.8010702@stpeter.im> <8FD6CBCE-60CD-4049-A0E6-B2388D6919DF@cisco.com> In-Reply-To: <8FD6CBCE-60CD-4049-A0E6-B2388D6919DF@cisco.com> Message-Id: <817D19D4-1615-440A-8F75-DEAEFE0BEA58@isode.com> X-Mailer: iPad Mail (9B206) From: Alexey Melnikov Date: Mon, 17 Sep 2012 19:21:57 +0100 To: "Matt Miller (mamille2)" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Cc: "precis@ietf.org" Subject: Re: [precis] Review of draft-melnikov-precis-saslprepbis-03 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 18:20:21 -0000 Hi Matt, Sent from my iPad On 17 Sep 2012, at 19:09, "Matt Miller (mamille2)" wrot= e: > * 3.2 (Passwords - Preparation) :: I do wonder about the rationale for ste= p 2) (map all non-ASCII space to ASCII space). I myself have not run into c= onditions where this would matter, but I mostly deal with US-based consumers= with passwords almost exclusively in the ASCII range. On the surface, it s= eems a bit contradictory in principle to the "no bidi rule" rationale that i= s included. I'm not advocating for retention or removal of step 2), but rath= er for providing a rationale (one way or the other). This rule was always in SASLPrep, so this is trying to preserve some sort of= backward compatibility. Whether it is a good enough reason to keep the rule= - I don't know. From stpeter@stpeter.im Mon Sep 17 13:03:41 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04FD21F84F8 for ; Mon, 17 Sep 2012 13:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.321 X-Spam-Level: X-Spam-Status: No, score=-102.321 tagged_above=-999 required=5 tests=[AWL=-0.322, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pC6AkclkeiDk for ; Mon, 17 Sep 2012 13:03:40 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 90A9B21F84F6 for ; Mon, 17 Sep 2012 13:03:40 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5BB1F4005A; Mon, 17 Sep 2012 14:04:39 -0600 (MDT) Message-ID: <5057821A.1050903@stpeter.im> Date: Mon, 17 Sep 2012 14:03:38 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Alexey Melnikov References: <20120914162208.30845.65648.idtracker@ietfa.amsl.com> <50535A6B.8010702@stpeter.im> <8FD6CBCE-60CD-4049-A0E6-B2388D6919DF@cisco.com> <817D19D4-1615-440A-8F75-DEAEFE0BEA58@isode.com> In-Reply-To: <817D19D4-1615-440A-8F75-DEAEFE0BEA58@isode.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "precis@ietf.org" Subject: Re: [precis] Review of draft-melnikov-precis-saslprepbis-03 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 20:03:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/17/12 12:21 PM, Alexey Melnikov wrote: > On 17 Sep 2012, at 19:09, "Matt Miller (mamille2)" > wrote: [I agree with the other points that Matt raised. Thanks for the review!] >> * 3.2 (Passwords - Preparation) :: I do wonder about the >> rationale for step 2) (map all non-ASCII space to ASCII space). >> I myself have not run into conditions where this would matter, >> but I mostly deal with US-based consumers with passwords almost >> exclusively in the ASCII range. On the surface, it seems a bit >> contradictory in principle to the "no bidi rule" rationale that >> is included. I'm not advocating for retention or removal of step >> 2), but rather for providing a rationale (one way or the other). > > This rule was always in SASLPrep, so this is trying to preserve > some sort of backward compatibility. Whether it is a good enough > reason to keep the rule - I don't know. This rule applied to stringprep via Appendix B.1 in RFC 3454: http://tools.ietf.org/html/rfc3454#appendix-B.1 In the interest of full disclosure, the code points involved were: U+00AD SOFT HYPHEN U+034F COMBINING GRAPHEME JOINER U+1806 MONGOLIAN TODO SOFT HYPHEN U+180B MONGOLIAN FREE VARIATION SELECTOR ONE U+180C MONGOLIAN FREE VARIATION SELECTOR TWO U+180D MONGOLIAN FREE VARIATION SELECTOR THREE U+200B ZERO WIDTH SPACE U+200C ZERO WIDTH NON-JOINER U+200D ZERO WIDTH JOINER U+2060 WORD JOINER U+FE00 VARIATION SELECTOR-1 [...other variation selectors here...] U+FE0F VARIATION SELECTOR-13 U+FEFF ZERO WIDTH NO-BREAK SPACE As far as I can see, we have two alternatives for SASLprep-bis: 1. Continue to map those code points to nothing. 2. Disallow those code points by subclassing the FreeClass. I don't have a strong feeling either way, although mapping to nothing has always struck me as a wimpy approach and I'd probably prefer to explicitly disallow unwanted code points... Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBXghoACgkQNL8k5A2w/vxvswCgp5O1xCtdmHZZCHD1STFxfdOM JjAAoOFaF2uPI68gKzM27e/kpRItCkAO =xbD4 -----END PGP SIGNATURE----- From stpeter@stpeter.im Wed Sep 19 07:21:01 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 633CF21F8713 for ; Wed, 19 Sep 2012 07:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iS1p4TCNObkS for ; Wed, 19 Sep 2012 07:21:00 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA3421F870B for ; Wed, 19 Sep 2012 07:21:00 -0700 (PDT) Received: from [10.6.21.229] (unknown [74.93.1.137]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1AFF340D52 for ; Wed, 19 Sep 2012 08:22:05 -0600 (MDT) Message-ID: <5059D4CF.30206@stpeter.im> Date: Wed, 19 Sep 2012 07:21:03 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "precis@ietf.org" X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [precis] registration policy for subclasses X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 14:21:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Currently, the RFC 5226 registration policy defined for subclasses is "First Come, First Served". Do we think that a slightly higher review standard is needed for subclasses, for instance "Expert Review" or even "Specification Required"? Although in general I am in favor of the lowest bar possible for registration, it strikes me that for subclasses we might want something more than "First Come, First Served" (IMHO "Expert Review" would be enough). For base class usage registrations, I think "First Come, First Served" is appropriate, although I would be open to "Expert Review" for those registrations as well.) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBZ1M8ACgkQNL8k5A2w/vyKeQCgsbZJrGbn6gH+Q+wBKp3D8vyk MoIAoLsyWF4R2a2qGkIqJCbW3WHmUImz =rf5n -----END PGP SIGNATURE----- From marc.blanchet@viagenie.ca Wed Sep 19 08:33:18 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6367A21F86EB for ; Wed, 19 Sep 2012 08:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1779hvltr2tF for ; Wed, 19 Sep 2012 08:33:17 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3F421F86E5 for ; Wed, 19 Sep 2012 08:33:17 -0700 (PDT) Received: from [IPv6:2620::230:c000:b43f:3ddc:9648:3500] (unknown [IPv6:2620:0:230:c000:b43f:3ddc:9648:3500]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EAB9E41364; Wed, 19 Sep 2012 11:33:15 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Marc Blanchet In-Reply-To: <5059D4CF.30206@stpeter.im> Date: Wed, 19 Sep 2012 11:33:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5059D4CF.30206@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1278) Cc: "precis@ietf.org" Subject: Re: [precis] registration policy for subclasses X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 15:33:18 -0000 I think that Expert review is probably the best for any kind. The main = reason to me is to have someone to help the "customer", such as: have = you really thought about reusing one of the current defined classes = instead of creating a new one? have you thought about the transition = problem? =85 Kind of a way to interact with the "customer" before too = late. We do want to minimize the number of sub-classes (or in general = classes), therefore having an "interception" mechanism would be useful. Marc. Le 2012-09-19 =E0 10:21, Peter Saint-Andre a =E9crit : > Currently, the RFC 5226 registration policy defined for subclasses is > "First Come, First Served". Do we think that a slightly higher review > standard is needed for subclasses, for instance "Expert Review" or > even "Specification Required"? Although in general I am in favor of > the lowest bar possible for registration, it strikes me that for > subclasses we might want something more than "First Come, First > Served" (IMHO "Expert Review" would be enough). For base class usage > registrations, I think "First Come, First Served" is appropriate, > although I would be open to "Expert Review" for those registrations as > well.) >=20 > Peter >=20 > - --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 From internet-drafts@ietf.org Wed Sep 19 10:34:37 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A61121F86E4; Wed, 19 Sep 2012 10:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSqktwvmrLHG; Wed, 19 Sep 2012 10:34:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E5121F874C; Wed, 19 Sep 2012 10:34:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120919173436.3501.50026.idtracker@ietfa.amsl.com> Date: Wed, 19 Sep 2012 10:34:36 -0700 Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-problem-statement-08.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 17:34:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Preparation and Comparison of Internation= alized Strings Working Group of the IETF. Title : Stringprep Revision and PRECIS Problem Statement Author(s) : Marc Blanchet Andrew Sullivan Filename : draft-ietf-precis-problem-statement-08.txt Pages : 31 Date : 2012-09-19 Abstract: If a protocol expects to compare two strings and is prepared only for those strings to be ASCII, then using Unicode codepoints in those strings requires they be prepared somehow. Internationalizing Domain Names in Applications (here called IDNA2003) defined and used Stringprep and Nameprep. Other protocols subsequently defined Stringprep profiles. A new approach different from Stringprep and Nameprep is used for a revision of IDNA2003 (called IDNA2008). Other Stringprep profiles need to be similarly updated or a replacement of Stringprep needs to be designed. This document outlines the issues to be faced by those designing a Stringprep replacement. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-problem-statement There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-precis-problem-statement-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-precis-problem-statement-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From marc.blanchet@viagenie.ca Wed Sep 19 10:37:20 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 791DD21F875D for ; Wed, 19 Sep 2012 10:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-dl-gAO-Tpr for ; Wed, 19 Sep 2012 10:37:20 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id EF07021F86E4 for ; Wed, 19 Sep 2012 10:37:19 -0700 (PDT) Received: from h99.viagenie.ca (h99.viagenie.ca [206.123.31.99]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4F13541596 for ; Wed, 19 Sep 2012 13:37:14 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1278) From: Marc Blanchet In-Reply-To: <20120919173436.3501.50026.idtracker@ietfa.amsl.com> Date: Wed, 19 Sep 2012 13:37:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <027D71A7-43B8-4588-9861-E9DB3BE6ACEF@viagenie.ca> References: <20120919173436.3501.50026.idtracker@ietfa.amsl.com> To: precis@ietf.org X-Mailer: Apple Mail (2.1278) Subject: Re: [precis] I-D Action: draft-ietf-precis-problem-statement-08.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 17:37:20 -0000 Hello, just minor mods to satisfy ID-Nits. No substantive changes. Regards, Marc. Le 2012-09-19 =E0 13:34, internet-drafts@ietf.org a =E9crit : >=20 > 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. >=20 > Title : Stringprep Revision and PRECIS Problem = Statement > Author(s) : Marc Blanchet > Andrew Sullivan > Filename : draft-ietf-precis-problem-statement-08.txt > Pages : 31 > Date : 2012-09-19 >=20 > Abstract: > If a protocol expects to compare two strings and is prepared only = for > those strings to be ASCII, then using Unicode codepoints in those > strings requires they be prepared somehow. Internationalizing = Domain > Names in Applications (here called IDNA2003) defined and used > Stringprep and Nameprep. Other protocols subsequently defined > Stringprep profiles. A new approach different from Stringprep and > Nameprep is used for a revision of IDNA2003 (called IDNA2008). = Other > Stringprep profiles need to be similarly updated or a replacement of > Stringprep needs to be designed. This document outlines the issues > to be faced by those designing a Stringprep replacement. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-precis-problem-statement >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-precis-problem-statement-08 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-precis-problem-statement-08 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From stpeter@stpeter.im Wed Sep 19 12:42:34 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5FD521E8034 for ; Wed, 19 Sep 2012 12:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.639 X-Spam-Level: X-Spam-Status: No, score=-100.639 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ip28dv-M5gVK for ; Wed, 19 Sep 2012 12:42:34 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 701DB21F85DA for ; Wed, 19 Sep 2012 12:42:34 -0700 (PDT) Received: from [192.168.15.114] (unknown [50.0.103.34]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BDD8E40DA5; Wed, 19 Sep 2012 13:43:36 -0600 (MDT) Message-ID: <505A2025.1000608@stpeter.im> Date: Wed, 19 Sep 2012 12:42:29 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Marc Blanchet References: <5059D4CF.30206@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "precis@ietf.org" Subject: Re: [precis] registration policy for subclasses X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 19:42:35 -0000 Hi Marc, that makes sense for subclasses. I'm not as concerned about uses of the base classes, but there also I think that it would be good to provide some guidance for our customers ("did you choose the right Unicode normalization form, casemapping rules, and bidirectional handling?"), so I'd be fine with Expert Review for both subclass registrations and usage registrations. Thanks for the feedback! Peter On 9/19/12 8:33 AM, Marc Blanchet wrote: > I think that Expert review is probably the best for any kind. The > main reason to me is to have someone to help the "customer", such as: > have you really thought about reusing one of the current defined > classes instead of creating a new one? have you thought about the > transition problem? … Kind of a way to interact with the > "customer" before too late. We do want to minimize the number of > sub-classes (or in general classes), therefore having an > "interception" mechanism would be useful. > > Marc. > > Le 2012-09-19 à 10:21, Peter Saint-Andre a écrit : > >> Currently, the RFC 5226 registration policy defined for subclasses >> is "First Come, First Served". Do we think that a slightly higher >> review standard is needed for subclasses, for instance "Expert >> Review" or even "Specification Required"? Although in general I am >> in favor of the lowest bar possible for registration, it strikes me >> that for subclasses we might want something more than "First Come, >> First Served" (IMHO "Expert Review" would be enough). For base >> class usage registrations, I think "First Come, First Served" is >> appropriate, although I would be open to "Expert Review" for those >> registrations as well.) >> >> Peter >> From duerst@it.aoyama.ac.jp Wed Sep 19 17:42:58 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABDC21E8048 for ; Wed, 19 Sep 2012 17:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.992 X-Spam-Level: X-Spam-Status: No, score=-103.992 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ao7N5aFZeYnm for ; Wed, 19 Sep 2012 17:42:57 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 2D76F21E8041 for ; Wed, 19 Sep 2012 17:42:56 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q8K0gjbP010232 for ; Thu, 20 Sep 2012 09:42:45 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 1a9b_65b3_18278660_02bc_11e2_83b0_001d096c5782; Thu, 20 Sep 2012 09:42:45 +0900 Received: from [IPv6:::1] ([133.2.210.1]:57605) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 20 Sep 2012 09:42:47 +0900 Message-ID: <505A6682.9040304@it.aoyama.ac.jp> Date: Thu, 20 Sep 2012 09:42:42 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Peter Saint-Andre References: <5059D4CF.30206@stpeter.im> <505A2025.1000608@stpeter.im> In-Reply-To: <505A2025.1000608@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "precis@ietf.org" Subject: Re: [precis] registration policy for subclasses X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 00:42:58 -0000 I definitely agree with Peter and Marc. For decisions that essentially involve the whole Unicode repertoire, some "customer advice" will be appreciated. Ideally, that should happen on a mailing list, so that others than the Expert Reviewer him/herself may be able to contribute. Regards, Martin. On 2012/09/20 4:42, Peter Saint-Andre wrote: > Hi Marc, that makes sense for subclasses. I'm not as concerned about > uses of the base classes, but there also I think that it would be good > to provide some guidance for our customers ("did you choose the right > Unicode normalization form, casemapping rules, and bidirectional > handling?"), so I'd be fine with Expert Review for both subclass > registrations and usage registrations. > > Thanks for the feedback! > > Peter > > On 9/19/12 8:33 AM, Marc Blanchet wrote: >> I think that Expert review is probably the best for any kind. The >> main reason to me is to have someone to help the "customer", such as: >> have you really thought about reusing one of the current defined >> classes instead of creating a new one? have you thought about the >> transition problem? … Kind of a way to interact with the >> "customer" before too late. We do want to minimize the number of >> sub-classes (or in general classes), therefore having an >> "interception" mechanism would be useful. >> >> Marc. >> >> Le 2012-09-19 à 10:21, Peter Saint-Andre a écrit : >> >>> Currently, the RFC 5226 registration policy defined for subclasses >>> is "First Come, First Served". Do we think that a slightly higher >>> review standard is needed for subclasses, for instance "Expert >>> Review" or even "Specification Required"? Although in general I am >>> in favor of the lowest bar possible for registration, it strikes me >>> that for subclasses we might want something more than "First Come, >>> First Served" (IMHO "Expert Review" would be enough). For base >>> class usage registrations, I think "First Come, First Served" is >>> appropriate, although I would be open to "Expert Review" for those >>> registrations as well.) >>> >>> Peter >>> > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis From stpeter@stpeter.im Thu Sep 20 11:23:49 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C59921F86A2; Thu, 20 Sep 2012 11:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsnvglftY5cB; Thu, 20 Sep 2012 11:23:48 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2874C21F84B6; Thu, 20 Sep 2012 11:23:48 -0700 (PDT) Received: from [192.168.1.182] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6EDC140DA5; Thu, 20 Sep 2012 12:24:56 -0600 (MDT) Message-ID: <505B5F32.3020604@stpeter.im> Date: Thu, 20 Sep 2012 12:23:46 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Pete Resnick X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "precis@ietf.org" Subject: [precis] Document Shepherd Write-Up for draft-ietf-precis-problem-statement-08 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 18:23:49 -0000 Dear Pete (PRECIS WG cc'd, IESG secretary bcc'd): In accordance with RFC 4858, here is the Document Shepherd Write-Up for "Stringprep Revision and PRECIS Problem Statement" (draft-ietf-precis-problem-statement-08). Peter ### Specification: draft-ietf-precis-problem-statement-08 Shepherd: Peter Saint-Andre Date: 2012-09-20 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Informational. Why is this the proper type of RFC? The document does not define any protocol and thus is not appropriate for the standards track. Informational is the usual type for problem statements. Is this type of RFC indicated in the title page header? Yes. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: ### Technical Summary If a protocol expects to compare two strings and is prepared only for those strings to be ASCII, then using Unicode codepoints in those strings requires they be prepared somehow. Internationalizing Domain Names in Applications (here called IDNA2003) defined and used Stringprep and Nameprep. Other protocols subsequently defined Stringprep profiles. A new approach different from Stringprep and Nameprep is used for a revision of IDNA2003 (called IDNA2008). Other Stringprep profiles need to be similarly updated or a replacement of Stringprep needs to be designed. This document outlines the issues to be faced by those designing a Stringprep replacement. Working Group Summary The document records the consensus from discussion at the NEWPREP BoF (IETF 77, March 2010) and the resulting PRECIS WG regarding the problem to be solved in developing a replacement for the Stringprep technology in application protocols other than IDNA. There has not been controversy about the nature of the problem to be solved, and consensus was not rough. Document Quality The document has provided a clear basis for work on the proposed PRECIS framework, and thus has served its purpose. Personnel The Document Shepherd is Peter Saint-Andre. The Responsible Area Director is Pete Resnick. ### (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I have reviewed each iteration of the document while it was under development in the working group. I have also more carefully reviewed the version (08) being forwarded to the IESG. In my opinion, the document accurately reflects the consensus of the working group and is ready for publication (although on a final reading I noticed some small but obvious linguistic errors, suitable for correction by the RFC Editor). (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has been reviewed by a number of knowledgeable participants within the PRECIS WG. I do not have concerns about the depth or breadth of review. Naturally, the protocol specifications that attempt to solve the problems outlined in this document will require more thorough review. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. The entire document discusses internationalization, albeit in an informational fashion. Based on my experience with the topic, I conclude that the document is well within the bounds of good practices for internationalization, for instance by building on the work already completed in the IDNA2008 effort. In my opinion, no more specialized or broad reviews are needed with regard to this informational problem statement. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. It is important to publish this document so as to provide a foundation for the working group's protocol development. The area of work is complex, making a problem statement all the more valuable. I was uncomfortable with the fact that a prior version of this document foreshadowed the proposed solution by recommending particular string classes, but that text was removed (appropriately, I think) and thus I am now comfortable with the document in its entirety. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. As document shepherd I have confirmed that the authors are not personally aware of any IPR related to this document. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures have been filed in relation to this document. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? With the caveat that the PRECIS WG (as is true of other working groups focused on internationalization) does not contain a large number of participants, let alone active participants, I would say that the WG consensus for publishing this document is solid. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) I am not aware of any threatened appeals or areas of significant conflict regarding this document. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The nits triggered by version -07 have been fixed in -08. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal reviews were appropriate for this problem statement. (13) Have all references within this document been identified as either normative or informative? Given that the document itself is informative, no normative references were appropriate and all of the references are informative. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? There are no normative references. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. There are no downward normative references. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This document does not change the status of any existing RFCs. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). This document has no actions for the IANA, and that is correct. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No registries are to be created by this document. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Not applicable. END ### From internet-drafts@ietf.org Thu Sep 20 11:44:47 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADCF21E8090; Thu, 20 Sep 2012 11:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7ayNKr6aPd3; Thu, 20 Sep 2012 11:44:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52A921E8039; Thu, 20 Sep 2012 11:44:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120920184446.6874.68341.idtracker@ietfa.amsl.com> Date: Thu, 20 Sep 2012 11:44:46 -0700 Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-nickname-01.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 18:44:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Preparation and Comparison of Internation= alized Strings Working Group of the IETF. Title : Preparation and Comparison of Nicknames Author(s) : Peter Saint-Andre Filename : draft-ietf-precis-nickname-01.txt Pages : 7 Date : 2012-09-20 Abstract: This document describes how to prepare and compare Unicode strings representing nicknames, primarily as used within textual chatrooms. This profile is intended to be used by chatroom technologies based on both the Message Session Relay Protocol (MSRP) and the Extensible Messaging and Presence Protocol (XMPP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-nickname There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-precis-nickname-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-precis-nickname-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stpeter@stpeter.im Thu Sep 20 11:48:11 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8D421F86B8 for ; Thu, 20 Sep 2012 11:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wJROHIRdZi2 for ; Thu, 20 Sep 2012 11:48:10 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id EE5B221F86B7 for ; Thu, 20 Sep 2012 11:48:09 -0700 (PDT) Received: from [192.168.1.182] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E554140DA5 for ; Thu, 20 Sep 2012 12:49:18 -0600 (MDT) Message-ID: <505B64E9.3000609@stpeter.im> Date: Thu, 20 Sep 2012 12:48:09 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "precis@ietf.org" X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [precis] updated I-Ds... X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 18:48:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 While in airports and on airplanes over the last few days, I had a chance to review all of the PRECIS-related specifications. I'll soon be publishing revised I-Ds containing small changes (and have just done so for the nickname draft). Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBbZOkACgkQNL8k5A2w/vzkLACgg2oFGL+FYFs+TyU8wB6L0Z+x 7UkAoPS25vM8nEN2J86maJFdcxq1y48R =/uDa -----END PGP SIGNATURE----- From stpeter@stpeter.im Thu Sep 20 11:48:41 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A88721E8084 for ; Thu, 20 Sep 2012 11:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtQoVslHoyzS for ; Thu, 20 Sep 2012 11:48:41 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 085DA21E804B for ; Thu, 20 Sep 2012 11:48:41 -0700 (PDT) Received: from [192.168.1.182] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0784940DA5 for ; Thu, 20 Sep 2012 12:49:49 -0600 (MDT) Message-ID: <505B6508.2060601@stpeter.im> Date: Thu, 20 Sep 2012 12:48:40 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: precis@ietf.org References: <20120920184446.6874.68341.idtracker@ietfa.amsl.com> In-Reply-To: <20120920184446.6874.68341.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [precis] I-D Action: draft-ietf-precis-nickname-01.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 18:48:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 IMHO this I-D is now ready for WGLC. YMMV... On 9/20/12 12:44 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Preparation and > Comparison of Internationalized Strings Working Group of the IETF. > > Title : Preparation and Comparison of Nicknames Author(s) > : Peter Saint-Andre Filename : > draft-ietf-precis-nickname-01.txt Pages : 7 Date > : 2012-09-20 > > Abstract: This document describes how to prepare and compare > Unicode strings representing nicknames, primarily as used within > textual chatrooms. This profile is intended to be used by chatroom > technologies based on both the Message Session Relay Protocol > (MSRP) and the Extensible Messaging and Presence Protocol (XMPP). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-precis-nickname > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-precis-nickname-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-nickname-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ precis mailing > list precis@ietf.org https://www.ietf.org/mailman/listinfo/precis > - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBbZQgACgkQNL8k5A2w/vwsGQCgoKbGt8Gvmf3qgmoLlYqRBSDf oFoAnjFgyYg2Fkm3aJCmujWOaqDd2X95 =X6rR -----END PGP SIGNATURE----- From stpeter@stpeter.im Thu Sep 20 12:31:39 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF5321F86E4 for ; Thu, 20 Sep 2012 12:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynLrniQ9iN7A for ; Thu, 20 Sep 2012 12:31:38 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id DD33F21F86A2 for ; Thu, 20 Sep 2012 12:31:38 -0700 (PDT) Received: from [192.168.1.182] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 34F5F40DA5 for ; Thu, 20 Sep 2012 13:32:47 -0600 (MDT) Message-ID: <505B6F19.109@stpeter.im> Date: Thu, 20 Sep 2012 13:31:37 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "precis@ietf.org" X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [precis] width mapping in draft-yoneya-precis-mappings X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 19:31:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Section 3.1 of draft-yoneya-precis-mappings states: Width mapping will increase backward compatibility with Stringprep [RFC3454] and precis framework [I-D.ietf-precis-framework]. Because in a Stringprep profile which specifies Unicode normalization form KC (NFKC) for normalization method, fullwidth/halfwidth characters are mapped into its compatible form. If a precis framework profile specified NFKC (which is not recommended), width mapping might not be useful. Is backward compatibility the only reason to specify width mapping? If so, then it would be good to say that width mapping is appropriate for technologies that are migrating from stringprep (with NFKC) to precis, but not for technologies that never had a stringprep profile. If not, then it would be good to explain why it can be appropriate for a technology that uses precis (but never used stringprep) to specify width mapping. For example, perhaps width mapping helps to prevent violations of the "principle of least user surprise" because users in language communities with fullwidth and halfwidth characters might not be able to tell the difference between various widths on common devices. In my opinion, some discussion of the security implications of width mapping (e.g., the possibility of more "fase positives") would also be helpful. Thanks! Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBbbxkACgkQNL8k5A2w/vwbdwCfWoKE3UInmTbnBMG4Zbv9gHfr JTAAoJBXvP/FsphnbmPXxjnYeYKu204f =i6jZ -----END PGP SIGNATURE----- From mamille2@cisco.com Fri Sep 21 07:55:03 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B15821F8820 for ; Fri, 21 Sep 2012 07:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.26 X-Spam-Level: X-Spam-Status: No, score=-10.26 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AV9DzsIkNPL for ; Fri, 21 Sep 2012 07:55:02 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 816A521F881D for ; Fri, 21 Sep 2012 07:55:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7962; q=dns/txt; s=iport; t=1348239302; x=1349448902; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Vhq2gTIslVMtCdOIFex7Ca42tHm3ZvpHTHVkaJ7fPdU=; b=mlBBk4rmBHaDUg7GntKYomH9n6GgZRAJgNURqBWM94v5WqxPCW0yYzJQ CggVeRFGYCXz+/I48hrzUb8aVNIFxXfG55jWk+W7Xpl/Db1TaGEyTD7IH Un7qI3KAH3mMiOCux6e0X3ql2lOZa6V/0qDa6XmTs2wAuFEyWmZ8tTSUh Q=; X-Files: smime.p7s, PGP.sig : 2214, 535 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAIp+XFCtJV2b/2dsb2JhbABFvhGBCIIgAQEBAwESAV0JBQsCAQgYGBYCMCUCBA4FDhSHXQYLmSegF4scgwiCPmADjmqBIIVagRWNJIFpgmeBWiIb X-IronPort-AV: E=Sophos;i="4.80,463,1344211200"; d="sig'?p7s'?scan'208";a="124030727" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 21 Sep 2012 14:55:02 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8LEt1ZA030653 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Sep 2012 14:55:01 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.219]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Fri, 21 Sep 2012 09:55:01 -0500 From: "Matt Miller (mamille2)" To: Peter Saint-Andre Thread-Topic: [precis] Review of draft-melnikov-precis-saslprepbis-03 Thread-Index: AQHNlP+WokQ1fNsRykSn+UGgjKzev5ePLHaAgAAcaQCABfMjgA== Date: Fri, 21 Sep 2012 14:55:01 +0000 Message-ID: <27C17524-DB6B-45AB-90D2-38A77CAD91F2@cisco.com> References: <20120914162208.30845.65648.idtracker@ietfa.amsl.com> <50535A6B.8010702@stpeter.im> <8FD6CBCE-60CD-4049-A0E6-B2388D6919DF@cisco.com> <817D19D4-1615-440A-8F75-DEAEFE0BEA58@isode.com> <5057821A.1050903@stpeter.im> In-Reply-To: <5057821A.1050903@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-pgp-agent: GPGMail 1.3.3 x-originating-ip: [64.101.72.40] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19200.001 x-tm-as-result: No--37.067700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-6-564922190" MIME-Version: 1.0 Cc: "precis@ietf.org" Subject: Re: [precis] Review of draft-melnikov-precis-saslprepbis-03 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 14:55:03 -0000 --Apple-Mail-6-564922190 Content-Type: multipart/signed; boundary=Apple-Mail-5-564922188; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail-5-564922188 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 17, 2012, at 14:03, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 9/17/12 12:21 PM, Alexey Melnikov wrote: >=20 >> On 17 Sep 2012, at 19:09, "Matt Miller (mamille2)"=20 >> wrote: >=20 > [I agree with the other points that Matt raised. Thanks for the = review!] >=20 >>> * 3.2 (Passwords - Preparation) :: I do wonder about the >>> rationale for step 2) (map all non-ASCII space to ASCII space). >>> I myself have not run into conditions where this would matter, >>> but I mostly deal with US-based consumers with passwords almost >>> exclusively in the ASCII range. On the surface, it seems a bit >>> contradictory in principle to the "no bidi rule" rationale that >>> is included. I'm not advocating for retention or removal of step >>> 2), but rather for providing a rationale (one way or the other). >>=20 >> This rule was always in SASLPrep, so this is trying to preserve >> some sort of backward compatibility. Whether it is a good enough >> reason to keep the rule - I don't know. >=20 I just thought it a bit odd that there's a nice big paragraph explaining = how a bidi rule would reduce entropy, but the mapping of all non-ASCII = space to ASCII space (which would also reduce entropy, theoretically) is = a single sentence. However, I'm willing to more than happy to suspend my perceptions over = this if others are content with the current text. > This rule applied to stringprep via Appendix B.1 in RFC 3454: >=20 > http://tools.ietf.org/html/rfc3454#appendix-B.1 >=20 > In the interest of full disclosure, the code points involved were: >=20 > U+00AD SOFT HYPHEN > U+034F COMBINING GRAPHEME JOINER > U+1806 MONGOLIAN TODO SOFT HYPHEN > U+180B MONGOLIAN FREE VARIATION SELECTOR ONE > U+180C MONGOLIAN FREE VARIATION SELECTOR TWO > U+180D MONGOLIAN FREE VARIATION SELECTOR THREE > U+200B ZERO WIDTH SPACE > U+200C ZERO WIDTH NON-JOINER > U+200D ZERO WIDTH JOINER > U+2060 WORD JOINER > U+FE00 VARIATION SELECTOR-1 > [...other variation selectors here...] > U+FE0F VARIATION SELECTOR-13 > U+FEFF ZERO WIDTH NO-BREAK SPACE >=20 > As far as I can see, we have two alternatives for SASLprep-bis: >=20 > 1. Continue to map those code points to nothing. >=20 > 2. Disallow those code points by subclassing the FreeClass. >=20 > I don't have a strong feeling either way, although mapping to nothing > has always struck me as a wimpy approach and I'd probably prefer to > explicitly disallow unwanted code points... >=20 Well, about the first 1/3 of those are also listed in Appendix C.1.2, = which were mapped to U+0020 in RFC 4013. Specifically: U+00A0 NO-BREAK SPACE U+1680 OGHAM SPACE MARK U+2000 EN QUAD U+2001 EM QUAD U+2002 EN SPACE U+2003 EM SPACE U+2004 THREE-PER-EM SPACE U+2005 FOUR-PER-EM SPACE U+2006 SIX-PER-EM SPACE U+2007 FIGURE SPACE U+2008 PUNCTUATION SPACE U+2009 THIN SPACE U+200A HAIR SPACE U+200B ZERO WIDTH SPACE U+202F NARROW NO-BREAK SPACE U+205F MEDIUM MATHEMATICAL SPACE U+3000 IDEOGRAPHIC SPACE For the purposes of passwords, I don't really know if mapping {Zs} code = points to U+0020 is a good idea or not. On one side, more code points = means more options (good IMO), but on the other hand I doubt these are = values most "password" text entry widgets make easy (or even possible) = to input in a predictable manner. As for the rest of B.1, I'm more inclined to disallow (which I think is = the case for FreeClass now) than map to nothing. - m&m Matt Miller - Cisco Systems, Inc. --Apple-Mail-5-564922188 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDkyMTE0NTUw OVowIwYJKoZIhvcNAQkEMRYEFP/b3alRw7mA8QsYz+rqgdlfNgXCMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQBGEQkq8fd3Q4o/GbeNuj193a0Uyh2aewXZeEMuG6zTlAl5Ypj/iGa/MMPl eb/k8Rb1ucjGJYzs4wRVJ7/aqcYte+BY4VObucPDrsLXjZHIxIwwYeFj71tDJdGGdaqYzsrYtfns JpUTegSjgMII7frpehZHZctBeLLwgwwBY674njV6BgErJL71W57Ha3I+Auy2WqNBGkGdfmONIOy4 QMEMHcW7QPklUQvJwJvED09GKM04KE8ojqsqoy31FHspancCywRhrl9iSEb29X8NvIxvLDr/jzJd 0BVJXyE0rIULPp3AqiVBrbQLQj2ExAas8Yz2asxmyMRlprzDhisw6VGQAAAAAAAA --Apple-Mail-5-564922188-- --Apple-Mail-6-564922190 Content-Type: application/pgp-signature; x-mac-type=70674453; name="PGP.sig" Content-Description: This is a digitally signed message part Content-Disposition: inline; filename="PGP.sig" Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJQXH/OAAoJEJq6Ou0cgrSPEOoIAI7lyB/Gkl1olb8nRm9ytxhC oNWhGSf6cEJTytGGRXyE4CGcVnrOts7GbgmQigqpywi4ea7VCy2oghGQUMVaiJLF wUMYJ2Z8kSmhbq6ZBXIDd8YR7TASALPmfKghVM3XBLAfqre3MbbXi0lPrT4YTHS4 zyTAWL3iBUJYCdqmlbOQQIjjC5K2ffI51S87cB9QKavWhy1Cs+y0rDnJkK19NgAm ahzwwyUPsokFatR8D1ueU4rjiZMuMU/hEtyTcW+1T0+qM6T/WufPhUQlf9qAXSWv MACtOVSkjnv3ge6OL0OenM5VX0tysu8dPPGszrHZtaXXJfBAUrYY6LG1NVgf51c= =+W5V -----END PGP SIGNATURE----- --Apple-Mail-6-564922190-- From stpeter@stpeter.im Fri Sep 21 08:01:22 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A432721F882E for ; Fri, 21 Sep 2012 08:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.452 X-Spam-Level: X-Spam-Status: No, score=-102.452 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CicyaD5--2VT for ; Fri, 21 Sep 2012 08:01:22 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD3D21F8830 for ; Fri, 21 Sep 2012 08:01:22 -0700 (PDT) Received: from [64.101.72.41] (unknown [64.101.72.41]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 22E8440DA5; Fri, 21 Sep 2012 09:02:32 -0600 (MDT) Message-ID: <505C7D56.9010106@stpeter.im> Date: Fri, 21 Sep 2012 08:44:38 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <5059D4CF.30206@stpeter.im> <505A2025.1000608@stpeter.im> <505A6682.9040304@it.aoyama.ac.jp> In-Reply-To: <505A6682.9040304@it.aoyama.ac.jp> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "precis@ietf.org" Subject: Re: [precis] registration policy for subclasses X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 15:01:22 -0000 I'll post proposed text about the registration policies to this list in the next few days. On 9/19/12 6:42 PM, "Martin J. Dürst" wrote: > I definitely agree with Peter and Marc. For decisions that essentially > involve the whole Unicode repertoire, some "customer advice" will be > appreciated. Ideally, that should happen on a mailing list, so that > others than the Expert Reviewer him/herself may be able to contribute. > > Regards, Martin. > > On 2012/09/20 4:42, Peter Saint-Andre wrote: >> Hi Marc, that makes sense for subclasses. I'm not as concerned about >> uses of the base classes, but there also I think that it would be good >> to provide some guidance for our customers ("did you choose the right >> Unicode normalization form, casemapping rules, and bidirectional >> handling?"), so I'd be fine with Expert Review for both subclass >> registrations and usage registrations. >> >> Thanks for the feedback! >> >> Peter >> >> On 9/19/12 8:33 AM, Marc Blanchet wrote: >>> I think that Expert review is probably the best for any kind. The >>> main reason to me is to have someone to help the "customer", such as: >>> have you really thought about reusing one of the current defined >>> classes instead of creating a new one? have you thought about the >>> transition problem? … Kind of a way to interact with the >>> "customer" before too late. We do want to minimize the number of >>> sub-classes (or in general classes), therefore having an >>> "interception" mechanism would be useful. >>> >>> Marc. >>> >>> Le 2012-09-19 à 10:21, Peter Saint-Andre a écrit : >>> >>>> Currently, the RFC 5226 registration policy defined for subclasses >>>> is "First Come, First Served". Do we think that a slightly higher >>>> review standard is needed for subclasses, for instance "Expert >>>> Review" or even "Specification Required"? Although in general I am >>>> in favor of the lowest bar possible for registration, it strikes me >>>> that for subclasses we might want something more than "First Come, >>>> First Served" (IMHO "Expert Review" would be enough). For base >>>> class usage registrations, I think "First Come, First Served" is >>>> appropriate, although I would be open to "Expert Review" for those >>>> registrations as well.) >>>> >>>> Peter >>>> From stpeter@stpeter.im Fri Sep 21 08:28:18 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71B121F8741 for ; Fri, 21 Sep 2012 08:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.293 X-Spam-Level: X-Spam-Status: No, score=-102.293 tagged_above=-999 required=5 tests=[AWL=-0.294, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5MSDQ0jZWWf for ; Fri, 21 Sep 2012 08:28:18 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id EB1EC21F851E for ; Fri, 21 Sep 2012 08:28:17 -0700 (PDT) Received: from [64.101.72.41] (unknown [64.101.72.41]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5204D40DA5; Fri, 21 Sep 2012 09:29:29 -0600 (MDT) Message-ID: <505C8790.1050909@stpeter.im> Date: Fri, 21 Sep 2012 09:28:16 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Matt Miller (mamille2)" References: <20120914162208.30845.65648.idtracker@ietfa.amsl.com> <50535A6B.8010702@stpeter.im> <8FD6CBCE-60CD-4049-A0E6-B2388D6919DF@cisco.com> <817D19D4-1615-440A-8F75-DEAEFE0BEA58@isode.com> <5057821A.1050903@stpeter.im> <27C17524-DB6B-45AB-90D2-38A77CAD91F2@cisco.com> In-Reply-To: <27C17524-DB6B-45AB-90D2-38A77CAD91F2@cisco.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "precis@ietf.org" Subject: Re: [precis] Review of draft-melnikov-precis-saslprepbis-03 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 15:28:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/21/12 8:55 AM, Matt Miller (mamille2) wrote: > > On Sep 17, 2012, at 14:03, Peter Saint-Andre wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 9/17/12 12:21 PM, Alexey Melnikov wrote: >> >>> On 17 Sep 2012, at 19:09, "Matt Miller (mamille2)" >>> wrote: >> >> [I agree with the other points that Matt raised. Thanks for the >> review!] >> >>>> * 3.2 (Passwords - Preparation) :: I do wonder about the >>>> rationale for step 2) (map all non-ASCII space to ASCII >>>> space). I myself have not run into conditions where this >>>> would matter, but I mostly deal with US-based consumers with >>>> passwords almost exclusively in the ASCII range. On the >>>> surface, it seems a bit contradictory in principle to the >>>> "no bidi rule" rationale that is included. I'm not advocating >>>> for retention or removal of step 2), but rather for providing >>>> a rationale (one way or the other). >>> >>> This rule was always in SASLPrep, so this is trying to preserve >>> some sort of backward compatibility. Whether it is a good >>> enough reason to keep the rule - I don't know. >> > > I just thought it a bit odd that there's a nice big paragraph > explaining how a bidi rule would reduce entropy, but the mapping > of all non-ASCII space to ASCII space (which would also reduce > entropy, theoretically) is a single sentence. > > However, I'm willing to more than happy to suspend my perceptions > over this if others are content with the current text. The bidi rule would be an addition to the rules, beyond what was in RFC 4013. The mapping of non-ASCII space to ASCII space was in RFC 4013 all along. That doesn't make it right, but it does make it a precedent and we'll need to figure out if we think it's right to follow that precedent or break with it. >> This rule applied to stringprep via Appendix B.1 in RFC 3454: >> >> http://tools.ietf.org/html/rfc3454#appendix-B.1 >> >> In the interest of full disclosure, the code points involved >> were: >> >> U+00AD SOFT HYPHEN U+034F COMBINING GRAPHEME JOINER U+1806 >> MONGOLIAN TODO SOFT HYPHEN U+180B MONGOLIAN FREE VARIATION >> SELECTOR ONE U+180C MONGOLIAN FREE VARIATION SELECTOR TWO U+180D >> MONGOLIAN FREE VARIATION SELECTOR THREE U+200B ZERO WIDTH SPACE >> U+200C ZERO WIDTH NON-JOINER U+200D ZERO WIDTH JOINER U+2060 WORD >> JOINER U+FE00 VARIATION SELECTOR-1 [...other variation selectors >> here...] U+FE0F VARIATION SELECTOR-13 U+FEFF ZERO WIDTH NO-BREAK >> SPACE >> >> As far as I can see, we have two alternatives for SASLprep-bis: >> >> 1. Continue to map those code points to nothing. >> >> 2. Disallow those code points by subclassing the FreeClass. >> >> I don't have a strong feeling either way, although mapping to >> nothing has always struck me as a wimpy approach and I'd >> probably prefer to explicitly disallow unwanted code points... >> > > Well, about the first 1/3 of those are also listed in Appendix > C.1.2, My count differs from yours. As far as I can see, the only code point listed in both B.1 and C.1.2 was U+200B ZERO WIDTH SPACE. > which were mapped to U+0020 in RFC 4013. Good point. I don't know why RFC 4013 invoked both B.1 and C.1.2. > Specifically: > > U+00A0 NO-BREAK SPACE U+1680 OGHAM SPACE MARK U+2000 EN QUAD > U+2001 EM QUAD U+2002 EN SPACE U+2003 EM SPACE U+2004 THREE-PER-EM > SPACE U+2005 FOUR-PER-EM SPACE U+2006 SIX-PER-EM SPACE U+2007 > FIGURE SPACE U+2008 PUNCTUATION SPACE U+2009 THIN SPACE U+200A HAIR > SPACE U+200B ZERO WIDTH SPACE U+202F NARROW NO-BREAK SPACE U+205F > MEDIUM MATHEMATICAL SPACE U+3000 IDEOGRAPHIC SPACE It's unclear to me how software that complied with RFC 4013 would have handled the code points that appeared in both B.1 and C.1.2 of RFC 3454 (i.e., U+200B). > For the purposes of passwords, I don't really know if mapping {Zs} > code points to U+0020 is a good idea or not. On one side, more > code points means more options (good IMO), but on the other hand I > doubt these are values most "password" text entry widgets make easy > (or even possible) to input in a predictable manner. Yes, and I think that's the stronger argument than the argument from precedent. To a large degree, these code points are used for things like typography and are not easily accessible for input purposes in IMEs or password widgets. Another argument is that these space-ish code points are not easily perceivable either as you are typing them or inputting them. However, let's not forget that that typically you can't see what you're typing or inputting in a password field anyway, because of the perceived threat of over-the-shoulder attacks. That makes this advice in RFC 3454 somewhat off-tangent: Space characters can make accurate visual transcription of strings nearly impossible and could lead to user entry errors in many ways. After all, typically we're not visually transcribing passwords. > As for the rest of B.1, I'm more inclined to disallow (which I > think is the case for FreeClass now) than map to nothing. That's my take, too. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBch5AACgkQNL8k5A2w/vyswQCfSEYzf0XH+gVBqTusDuZ+tvHo k+kAoMWn96U9GRB2ZEus/KOG6aVlohcf =gnVC -----END PGP SIGNATURE----- From stpeter@stpeter.im Fri Sep 21 10:37:11 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B427A21F877B for ; Fri, 21 Sep 2012 10:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5CaJCiEEsnc for ; Fri, 21 Sep 2012 10:37:09 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CAE2521F8762 for ; Fri, 21 Sep 2012 10:37:09 -0700 (PDT) Received: from [64.101.72.41] (unknown [64.101.72.41]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 535C340D52; Fri, 21 Sep 2012 11:38:21 -0600 (MDT) Message-ID: <505CA5C4.1050904@stpeter.im> Date: Fri, 21 Sep 2012 11:37:08 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "precis@ietf.org" References: <5059D4CF.30206@stpeter.im> <505A2025.1000608@stpeter.im> <505A6682.9040304@it.aoyama.ac.jp> <505C7D56.9010106@stpeter.im> In-Reply-To: <505C7D56.9010106@stpeter.im> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [precis] registration policy for subclasses X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 17:37:11 -0000 Here is proposed text for the IANA considerations related to the subclasses registry and the usage registry. I've changed the information requested for subclasses because I noticed (while working on 6122bis) that there was a lot of overlap between the subclass registrations and the usage registrations. I've also added bullet lists of topics that reviewers might focus on. Feedback would be appreciated. Thanks! /psa ### 10.3. PRECIS Subclasses Registry IANA is requested to create a registry of subclasses that use the PRECIS base string classes. In accordance with [RFC5226], the registration policy is "Expert Review". This policy was chosen in order to ensure that "customers" of PRECIS receive appropriate guidance regarding the sometimes complex and subtle internationalization issues related to subclassing of PRECIS base classes. The registration template is as follows: Subclass: [the name of the subclass] Base Class: [which base class is being subclassed] Exclusions: [a brief description of the specific code points that are excluded or of the properties based on which characters are excluded, e.g., "Eight legacy characters in the ASCII range." or "Any character that has a compatibility equivalent, i.e., the HasCompat category."] Specification: [a pointer to relevant documentation, such as an RFC or Internet-Draft] In order to request a review, the registrant shall send a completed template to the precis@ietf.org list or its designated successor. There are several factors to focus on while reviewing subclass registrations: o Is the problem well-defined? o Is it clear what applications will use this subclass? o Would an existing base class or subclass solve the problem? o Are the defined exclusions a reasonable solution to the problem for the relevant applications? o Is the subclass clearly defined? o Does the subclass reduce the degree to which human users would be surprised by application behavior (the "principle of least user surprise")? o Is the subclass based on an appropriate dividing line between user interface (culture, context, intent, locale, device limitations) and the use of conformant strings in protocol elements? o Does the subclass introduce any new security concerns (e.g., false positives for authentication or authorization)? 10.4. PRECIS Usage Registry IANA is requested to create a registry of application protocols that use the base string classes. The registry will include one entry for each use (e.g., if a protocol uses both the NameClass and the FreeClass then the specification for that protocol would submit two registrations). In accordance with [RFC5226], the registration policy is "Expert Review". This policy was chosen in order to ensure that "customers" of PRECIS receive appropriate guidance regarding the sometimes complex and subtle internationalization issues related to use of PRECIS base classes. The registration template is as follows: Applicability: [the specific protocol elements to which this usage applies, e.g., "Localparts in XMPP addresses."] Base Class: [the base string class that is being used or subclassed] Subclass: [whether the protocol has defined a subclass of the base class and, if so, the name of the subclass, e.g., "Yes, LocalpartNameClass."] Normalization: [which Unicode normalization form is applied, e.g., "NFC"] Casemapping: [the behavioral rule for handling of case, e.g., "Map uppercase and titlecase characters to lowercase."] Additional Mappings: [any additional mappings are required or recommended, e.g., "Map non-ASCII space characters to ASCII space."] Directionality: [the behavioral rule for handling of right-to-left code points, e.g., "The 'Bidi Rule' defined in RFC 5893 applies."] Specification: [a pointer to relevant documentation, such as an RFC or Internet-Draft] In order to request a review, the registrant shall send a completed template to the precis@ietf.org list or its designated successor. There are several factors to focus on while reviewing usage registrations: o Does the specification define what kinds of applications are involved and the protocol elements to which this usage applies? o Is there a base class or subclass that would be more appropriate to use? o Are the normalization, casemapping, additional mappings, and directionality handling appropriate for the intended use? o Does the usage reduce the degree to which human users would be surprised by application behavior (the "principle of least user surprise")? o Is the usage based on an appropriate dividing line between user interface (culture, context, intent, locale, device limitations) and the use of conformant strings in protocol elements? o Does the usage introduce any new security concerns (e.g., false positives for authentication or authorization)? ### On 9/21/12 8:44 AM, Peter Saint-Andre wrote: > I'll post proposed text about the registration policies to this list in > the next few days. > > On 9/19/12 6:42 PM, "Martin J. Dürst" wrote: >> I definitely agree with Peter and Marc. For decisions that essentially >> involve the whole Unicode repertoire, some "customer advice" will be >> appreciated. Ideally, that should happen on a mailing list, so that >> others than the Expert Reviewer him/herself may be able to contribute. >> >> Regards, Martin. >> >> On 2012/09/20 4:42, Peter Saint-Andre wrote: >>> Hi Marc, that makes sense for subclasses. I'm not as concerned about >>> uses of the base classes, but there also I think that it would be good >>> to provide some guidance for our customers ("did you choose the right >>> Unicode normalization form, casemapping rules, and bidirectional >>> handling?"), so I'd be fine with Expert Review for both subclass >>> registrations and usage registrations. >>> >>> Thanks for the feedback! >>> >>> Peter >>> >>> On 9/19/12 8:33 AM, Marc Blanchet wrote: >>>> I think that Expert review is probably the best for any kind. The >>>> main reason to me is to have someone to help the "customer", such as: >>>> have you really thought about reusing one of the current defined >>>> classes instead of creating a new one? have you thought about the >>>> transition problem? … Kind of a way to interact with the >>>> "customer" before too late. We do want to minimize the number of >>>> sub-classes (or in general classes), therefore having an >>>> "interception" mechanism would be useful. >>>> >>>> Marc. >>>> >>>> Le 2012-09-19 à 10:21, Peter Saint-Andre a écrit : >>>> >>>>> Currently, the RFC 5226 registration policy defined for subclasses >>>>> is "First Come, First Served". Do we think that a slightly higher >>>>> review standard is needed for subclasses, for instance "Expert >>>>> Review" or even "Specification Required"? Although in general I am >>>>> in favor of the lowest bar possible for registration, it strikes me >>>>> that for subclasses we might want something more than "First Come, >>>>> First Served" (IMHO "Expert Review" would be enough). For base >>>>> class usage registrations, I think "First Come, First Served" is >>>>> appropriate, although I would be open to "Expert Review" for those >>>>> registrations as well.) >>>>> >>>>> Peter >>>>> From stpeter@stpeter.im Fri Sep 21 11:53:17 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5FD11E808D for ; Fri, 21 Sep 2012 11:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5UV02pDXNhN for ; Fri, 21 Sep 2012 11:53:16 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 55C7021F8625 for ; Fri, 21 Sep 2012 11:53:16 -0700 (PDT) Received: from [64.101.72.41] (unknown [64.101.72.41]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E02AB40D52 for ; Fri, 21 Sep 2012 12:54:27 -0600 (MDT) Message-ID: <505CB79A.1010202@stpeter.im> Date: Fri, 21 Sep 2012 12:53:14 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "precis@ietf.org" References: <5059D4CF.30206@stpeter.im> <505A2025.1000608@stpeter.im> <505A6682.9040304@it.aoyama.ac.jp> <505C7D56.9010106@stpeter.im> <505CA5C4.1050904@stpeter.im> In-Reply-To: <505CA5C4.1050904@stpeter.im> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [precis] registration policy for subclasses X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 18:53:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 One further thought: would it make sense to capture the fact that some new precis usages obsolete a old stringprep profiles? For example: Applicability: Localparts in XMPP addresses. Base Class: NameClass Subclass: Yes, LocalpartNameClass. Obsoletes: Nodeprep profile of stringprep. [...] Peter On 9/21/12 11:37 AM, Peter Saint-Andre wrote: > Here is proposed text for the IANA considerations related to the > subclasses registry and the usage registry. I've changed the > information requested for subclasses because I noticed (while > working on 6122bis) that there was a lot of overlap between the > subclass registrations and the usage registrations. I've also added > bullet lists of topics that reviewers might focus on. Feedback > would be appreciated. > > Thanks! > > /psa > > ### > > 10.3. PRECIS Subclasses Registry > > IANA is requested to create a registry of subclasses that use the > PRECIS base string classes. In accordance with [RFC5226], the > registration policy is "Expert Review". This policy was chosen in > order to ensure that "customers" of PRECIS receive appropriate > guidance regarding the sometimes complex and subtle > internationalization issues related to subclassing of PRECIS base > classes. > > The registration template is as follows: > > Subclass: [the name of the subclass] Base Class: [which base > class is being subclassed] Exclusions: [a brief description of the > specific code points that are excluded or of the properties based > on which characters are excluded, e.g., "Eight legacy characters in > the ASCII range." or "Any character that has a compatibility > equivalent, i.e., the HasCompat category."] Specification: [a > pointer to relevant documentation, such as an RFC or > Internet-Draft] > > In order to request a review, the registrant shall send a > completed template to the precis@ietf.org list or its designated > successor. > > There are several factors to focus on while reviewing subclass > registrations: > > o Is the problem well-defined? o Is it clear what applications > will use this subclass? o Would an existing base class or subclass > solve the problem? o Are the defined exclusions a reasonable > solution to the problem for the relevant applications? o Is the > subclass clearly defined? o Does the subclass reduce the degree to > which human users would be surprised by application behavior (the > "principle of least user surprise")? o Is the subclass based on an > appropriate dividing line between user interface (culture, context, > intent, locale, device limitations) and the use of conformant > strings in protocol elements? o Does the subclass introduce any > new security concerns (e.g., false positives for authentication or > authorization)? > > 10.4. PRECIS Usage Registry > > IANA is requested to create a registry of application protocols > that use the base string classes. The registry will include one > entry for each use (e.g., if a protocol uses both the NameClass and > the FreeClass then the specification for that protocol would submit > two registrations). In accordance with [RFC5226], the > registration policy is "Expert Review". This policy was chosen in > order to ensure that "customers" of PRECIS receive appropriate > guidance regarding the sometimes complex and subtle > internationalization issues related to use of PRECIS base classes. > > The registration template is as follows: > > Applicability: [the specific protocol elements to which this > usage applies, e.g., "Localparts in XMPP addresses."] Base Class: > [the base string class that is being used or subclassed] Subclass: > [whether the protocol has defined a subclass of the base class and, > if so, the name of the subclass, e.g., "Yes, LocalpartNameClass."] > Normalization: [which Unicode normalization form is applied, > e.g., "NFC"] Casemapping: [the behavioral rule for handling of > case, e.g., "Map uppercase and titlecase characters to > lowercase."] Additional Mappings: [any additional mappings are > required or recommended, e.g., "Map non-ASCII space characters to > ASCII space."] Directionality: [the behavioral rule for handling > of right-to-left code points, e.g., "The 'Bidi Rule' defined in RFC > 5893 applies."] Specification: [a pointer to relevant > documentation, such as an RFC or Internet-Draft] > > In order to request a review, the registrant shall send a > completed template to the precis@ietf.org list or its designated > successor. > > There are several factors to focus on while reviewing usage > registrations: > > o Does the specification define what kinds of applications are > involved and the protocol elements to which this usage applies? o > Is there a base class or subclass that would be more appropriate to > use? o Are the normalization, casemapping, additional mappings, > and directionality handling appropriate for the intended use? o > Does the usage reduce the degree to which human users would be > surprised by application behavior (the "principle of least user > surprise")? o Is the usage based on an appropriate dividing line > between user interface (culture, context, intent, locale, device > limitations) and the use of conformant strings in protocol > elements? o Does the usage introduce any new security concerns > (e.g., false positives for authentication or authorization)? > > ### > > On 9/21/12 8:44 AM, Peter Saint-Andre wrote: >> I'll post proposed text about the registration policies to this >> list in the next few days. >> >> On 9/19/12 6:42 PM, "Martin J. Dürst" wrote: >>> I definitely agree with Peter and Marc. For decisions that >>> essentially involve the whole Unicode repertoire, some >>> "customer advice" will be appreciated. Ideally, that should >>> happen on a mailing list, so that others than the Expert >>> Reviewer him/herself may be able to contribute. >>> >>> Regards, Martin. >>> >>> On 2012/09/20 4:42, Peter Saint-Andre wrote: >>>> Hi Marc, that makes sense for subclasses. I'm not as >>>> concerned about uses of the base classes, but there also I >>>> think that it would be good to provide some guidance for our >>>> customers ("did you choose the right Unicode normalization >>>> form, casemapping rules, and bidirectional handling?"), so >>>> I'd be fine with Expert Review for both subclass >>>> registrations and usage registrations. >>>> >>>> Thanks for the feedback! >>>> >>>> Peter >>>> >>>> On 9/19/12 8:33 AM, Marc Blanchet wrote: >>>>> I think that Expert review is probably the best for any >>>>> kind. The main reason to me is to have someone to help the >>>>> "customer", such as: have you really thought about reusing >>>>> one of the current defined classes instead of creating a >>>>> new one? have you thought about the transition problem? … >>>>> Kind of a way to interact with the "customer" before too >>>>> late. We do want to minimize the number of sub-classes (or >>>>> in general classes), therefore having an "interception" >>>>> mechanism would be useful. >>>>> >>>>> Marc. >>>>> >>>>> Le 2012-09-19 à 10:21, Peter Saint-Andre a écrit : >>>>> >>>>>> Currently, the RFC 5226 registration policy defined for >>>>>> subclasses is "First Come, First Served". Do we think >>>>>> that a slightly higher review standard is needed for >>>>>> subclasses, for instance "Expert Review" or even >>>>>> "Specification Required"? Although in general I am in >>>>>> favor of the lowest bar possible for registration, it >>>>>> strikes me that for subclasses we might want something >>>>>> more than "First Come, First Served" (IMHO "Expert >>>>>> Review" would be enough). For base class usage >>>>>> registrations, I think "First Come, First Served" is >>>>>> appropriate, although I would be open to "Expert Review" >>>>>> for those registrations as well.) >>>>>> >>>>>> Peter >>>>>> -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBct5oACgkQNL8k5A2w/vy/JwCeOuSYD6Pb6qkxjhDjXa7aPOqU 8JsAoJQj8n5SO2FAOckN63yUEXGWM6Sa =ekNz -----END PGP SIGNATURE----- From duerst@it.aoyama.ac.jp Sat Sep 22 04:06:39 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8215D21F8757 for ; Sat, 22 Sep 2012 04:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.48 X-Spam-Level: X-Spam-Status: No, score=-101.48 tagged_above=-999 required=5 tests=[AWL=-1.690, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ur+NprkS0Cnz for ; Sat, 22 Sep 2012 04:06:35 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id D056021F8752 for ; Sat, 22 Sep 2012 04:06:32 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q8MB6Omi029952 for ; Sat, 22 Sep 2012 20:06:24 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 1581_0ea0_8c4b9154_04a5_11e2_964e_001d096c5782; Sat, 22 Sep 2012 20:06:24 +0900 Received: from [IPv6:::1] ([133.2.210.1]:45315) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sat, 22 Sep 2012 20:06:25 +0900 Message-ID: <505D9BA9.7010505@it.aoyama.ac.jp> Date: Sat, 22 Sep 2012 20:06:17 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Peter Saint-Andre References: <505B6F19.109@stpeter.im> In-Reply-To: <505B6F19.109@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "precis@ietf.org" Subject: Re: [precis] width mapping in draft-yoneya-precis-mappings X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 11:06:39 -0000 Hello Peter, others, On 2012/09/21 4:31, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Section 3.1 of draft-yoneya-precis-mappings states: > > Width mapping will increase backward compatibility with Stringprep > [RFC3454] and precis framework [I-D.ietf-precis-framework]. Because > in a Stringprep profile which specifies Unicode normalization form KC > (NFKC) for normalization method, fullwidth/halfwidth characters are > mapped into its compatible form. If a precis framework profile > specified NFKC (which is not recommended), width mapping might not be > useful. > > Is backward compatibility the only reason to specify width mapping? I very much don't think so. The full-width/half-width distinction that came to Unicode from East Asian Encodings is an artifact from the age of fixed character cell widths. In high-quality typesetting, there are various conventions for when to use one or the other form (and the "half-width" form is set in proportional type). But in everyday use, it's just mostly happenstance that decides which form is used. > If so, then it would be good to say that width mapping is appropriate > for technologies that are migrating from stringprep (with NFKC) to > precis, but not for technologies that never had a stringprep profile. > > If not, then it would be good to explain why it can be appropriate for > a technology that uses precis (but never used stringprep) to specify > width mapping. For example, perhaps width mapping helps to prevent > violations of the "principle of least user surprise" because users in > language communities with fullwidth and halfwidth characters might not > be able to tell the difference between various widths on common devices. "Might not be able to tell the difference" is the wrong expression. It's not too difficult to spot and identify the difference. It's much more a "not being motivated to spot the difference". An average American reader would be perfectly able to tell the difference between serif and sans-serif type. But when they read or write something, they (in most cases) just don't care. Why should they? So (I wish it were not, but) indeed width mapping is way more important than just for backwards compatibility. NFKC is in stringprep simply because the design team wanted to have a width mapping for IDNA 2003, and specifying NFKC was the easiest way to get there. In practice, width mapping is way more important than many of the mappings in NFC. And it's definitely the most important part of NFKC. > In my opinion, some discussion of the security implications of width > mapping (e.g., the possibility of more "fase positives") would also be > helpful. I don't think there will be false positives. Saying that e.g. IBM and ＩＢＭ are should be two different things is simply crazy. So it should be either width mapping, or the less basic forms (i.e. full-width for Latin and half-width for Kana,...) should be prohibited. Regards, Martin. > Thanks! > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iEYEARECAAYFAlBbbxkACgkQNL8k5A2w/vwbdwCfWoKE3UInmTbnBMG4Zbv9gHfr > JTAAoJBXvP/FsphnbmPXxjnYeYKu204f > =i6jZ > -----END PGP SIGNATURE----- > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis > From duerst@it.aoyama.ac.jp Sat Sep 22 04:08:31 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADFE21F8752 for ; Sat, 22 Sep 2012 04:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.311 X-Spam-Level: X-Spam-Status: No, score=-101.311 tagged_above=-999 required=5 tests=[AWL=-1.521, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dYtukBlZiHq for ; Sat, 22 Sep 2012 04:08:27 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 074F521F863C for ; Sat, 22 Sep 2012 04:08:26 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q8MB8Qad031331 for ; Sat, 22 Sep 2012 20:08:26 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 18cd_b47e_d4dc82de_04a5_11e2_82df_001d096c566a; Sat, 22 Sep 2012 20:08:25 +0900 Received: from [IPv6:::1] ([133.2.210.1]:54751) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sat, 22 Sep 2012 20:08:27 +0900 Message-ID: <505D9C23.1090307@it.aoyama.ac.jp> Date: Sat, 22 Sep 2012 20:08:19 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Peter Saint-Andre References: <5059D4CF.30206@stpeter.im> <505A2025.1000608@stpeter.im> <505A6682.9040304@it.aoyama.ac.jp> <505C7D56.9010106@stpeter.im> <505CA5C4.1050904@stpeter.im> <505CB79A.1010202@stpeter.im> In-Reply-To: <505CB79A.1010202@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "precis@ietf.org" Subject: Re: [precis] registration policy for subclasses X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 11:08:31 -0000 On 2012/09/22 3:53, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > One further thought: would it make sense to capture the fact that some > new precis usages obsolete a old stringprep profiles? What does "obsoletes" mean here? Is the result still the same (just a different framework), or are changes to the definition allowed? Regards, Martin. > For example: > > Applicability: Localparts in XMPP addresses. > Base Class: NameClass > Subclass: Yes, LocalpartNameClass. > Obsoletes: Nodeprep profile of stringprep. > [...] > > Peter > > On 9/21/12 11:37 AM, Peter Saint-Andre wrote: >> Here is proposed text for the IANA considerations related to the >> subclasses registry and the usage registry. I've changed the >> information requested for subclasses because I noticed (while >> working on 6122bis) that there was a lot of overlap between the >> subclass registrations and the usage registrations. I've also added >> bullet lists of topics that reviewers might focus on. Feedback >> would be appreciated. >> >> Thanks! >> >> /psa >> >> ### >> >> 10.3. PRECIS Subclasses Registry >> >> IANA is requested to create a registry of subclasses that use the >> PRECIS base string classes. In accordance with [RFC5226], the >> registration policy is "Expert Review". This policy was chosen in >> order to ensure that "customers" of PRECIS receive appropriate >> guidance regarding the sometimes complex and subtle >> internationalization issues related to subclassing of PRECIS base >> classes. >> >> The registration template is as follows: >> >> Subclass: [the name of the subclass] Base Class: [which base >> class is being subclassed] Exclusions: [a brief description of the >> specific code points that are excluded or of the properties based >> on which characters are excluded, e.g., "Eight legacy characters in >> the ASCII range." or "Any character that has a compatibility >> equivalent, i.e., the HasCompat category."] Specification: [a >> pointer to relevant documentation, such as an RFC or >> Internet-Draft] >> >> In order to request a review, the registrant shall send a >> completed template to the precis@ietf.org list or its designated >> successor. >> >> There are several factors to focus on while reviewing subclass >> registrations: >> >> o Is the problem well-defined? o Is it clear what applications >> will use this subclass? o Would an existing base class or subclass >> solve the problem? o Are the defined exclusions a reasonable >> solution to the problem for the relevant applications? o Is the >> subclass clearly defined? o Does the subclass reduce the degree to >> which human users would be surprised by application behavior (the >> "principle of least user surprise")? o Is the subclass based on an >> appropriate dividing line between user interface (culture, context, >> intent, locale, device limitations) and the use of conformant >> strings in protocol elements? o Does the subclass introduce any >> new security concerns (e.g., false positives for authentication or >> authorization)? >> >> 10.4. PRECIS Usage Registry >> >> IANA is requested to create a registry of application protocols >> that use the base string classes. The registry will include one >> entry for each use (e.g., if a protocol uses both the NameClass and >> the FreeClass then the specification for that protocol would submit >> two registrations). In accordance with [RFC5226], the >> registration policy is "Expert Review". This policy was chosen in >> order to ensure that "customers" of PRECIS receive appropriate >> guidance regarding the sometimes complex and subtle >> internationalization issues related to use of PRECIS base classes. >> >> The registration template is as follows: >> >> Applicability: [the specific protocol elements to which this >> usage applies, e.g., "Localparts in XMPP addresses."] Base Class: >> [the base string class that is being used or subclassed] Subclass: >> [whether the protocol has defined a subclass of the base class and, >> if so, the name of the subclass, e.g., "Yes, LocalpartNameClass."] >> Normalization: [which Unicode normalization form is applied, >> e.g., "NFC"] Casemapping: [the behavioral rule for handling of >> case, e.g., "Map uppercase and titlecase characters to >> lowercase."] Additional Mappings: [any additional mappings are >> required or recommended, e.g., "Map non-ASCII space characters to >> ASCII space."] Directionality: [the behavioral rule for handling >> of right-to-left code points, e.g., "The 'Bidi Rule' defined in RFC >> 5893 applies."] Specification: [a pointer to relevant >> documentation, such as an RFC or Internet-Draft] >> >> In order to request a review, the registrant shall send a >> completed template to the precis@ietf.org list or its designated >> successor. >> >> There are several factors to focus on while reviewing usage >> registrations: >> >> o Does the specification define what kinds of applications are >> involved and the protocol elements to which this usage applies? o >> Is there a base class or subclass that would be more appropriate to >> use? o Are the normalization, casemapping, additional mappings, >> and directionality handling appropriate for the intended use? o >> Does the usage reduce the degree to which human users would be >> surprised by application behavior (the "principle of least user >> surprise")? o Is the usage based on an appropriate dividing line >> between user interface (culture, context, intent, locale, device >> limitations) and the use of conformant strings in protocol >> elements? o Does the usage introduce any new security concerns >> (e.g., false positives for authentication or authorization)? >> >> ### >> >> On 9/21/12 8:44 AM, Peter Saint-Andre wrote: >>> I'll post proposed text about the registration policies to this >>> list in the next few days. >>> >>> On 9/19/12 6:42 PM, "Martin J. Dürst" wrote: >>>> I definitely agree with Peter and Marc. For decisions that >>>> essentially involve the whole Unicode repertoire, some >>>> "customer advice" will be appreciated. Ideally, that should >>>> happen on a mailing list, so that others than the Expert >>>> Reviewer him/herself may be able to contribute. >>>> >>>> Regards, Martin. >>>> >>>> On 2012/09/20 4:42, Peter Saint-Andre wrote: >>>>> Hi Marc, that makes sense for subclasses. I'm not as >>>>> concerned about uses of the base classes, but there also I >>>>> think that it would be good to provide some guidance for our >>>>> customers ("did you choose the right Unicode normalization >>>>> form, casemapping rules, and bidirectional handling?"), so >>>>> I'd be fine with Expert Review for both subclass >>>>> registrations and usage registrations. >>>>> >>>>> Thanks for the feedback! >>>>> >>>>> Peter >>>>> >>>>> On 9/19/12 8:33 AM, Marc Blanchet wrote: >>>>>> I think that Expert review is probably the best for any >>>>>> kind. The main reason to me is to have someone to help the >>>>>> "customer", such as: have you really thought about reusing >>>>>> one of the current defined classes instead of creating a >>>>>> new one? have you thought about the transition problem? … >>>>>> Kind of a way to interact with the "customer" before too >>>>>> late. We do want to minimize the number of sub-classes (or >>>>>> in general classes), therefore having an "interception" >>>>>> mechanism would be useful. >>>>>> >>>>>> Marc. >>>>>> >>>>>> Le 2012-09-19 à 10:21, Peter Saint-Andre a écrit : >>>>>> >>>>>>> Currently, the RFC 5226 registration policy defined for >>>>>>> subclasses is "First Come, First Served". Do we think >>>>>>> that a slightly higher review standard is needed for >>>>>>> subclasses, for instance "Expert Review" or even >>>>>>> "Specification Required"? Although in general I am in >>>>>>> favor of the lowest bar possible for registration, it >>>>>>> strikes me that for subclasses we might want something >>>>>>> more than "First Come, First Served" (IMHO "Expert >>>>>>> Review" would be enough). For base class usage >>>>>>> registrations, I think "First Come, First Served" is >>>>>>> appropriate, although I would be open to "Expert Review" >>>>>>> for those registrations as well.) >>>>>>> >>>>>>> Peter >>>>>>> > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iEYEARECAAYFAlBct5oACgkQNL8k5A2w/vy/JwCeOuSYD6Pb6qkxjhDjXa7aPOqU > 8JsAoJQj8n5SO2FAOckN63yUEXGWM6Sa > =ekNz > -----END PGP SIGNATURE----- > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis From stpeter@stpeter.im Sun Sep 23 10:09:24 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD3A21F8489 for ; Sun, 23 Sep 2012 10:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8y17sodg+dIq for ; Sun, 23 Sep 2012 10:09:23 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3844321F8487 for ; Sun, 23 Sep 2012 10:09:23 -0700 (PDT) Received: from [192.168.1.197] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4872340E08; Sun, 23 Sep 2012 11:10:41 -0600 (MDT) Message-ID: <505F4245.7040708@stpeter.im> Date: Sun, 23 Sep 2012 11:09:25 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <5059D4CF.30206@stpeter.im> <505A2025.1000608@stpeter.im> <505A6682.9040304@it.aoyama.ac.jp> <505C7D56.9010106@stpeter.im> <505CA5C4.1050904@stpeter.im> <505CB79A.1010202@stpeter.im> <505D9C23.1090307@it.aoyama.ac.jp> In-Reply-To: <505D9C23.1090307@it.aoyama.ac.jp> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "precis@ietf.org" Subject: Re: [precis] registration policy for subclasses X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2012 17:09:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/22/12 5:08 AM, "Martin J. Dürst" wrote: > On 2012/09/22 3:53, Peter Saint-Andre wrote: One further thought: > would it make sense to capture the fact that some new precis usages > obsolete a old stringprep profiles? > >> What does "obsoletes" mean here? Is the result still the same >> (just a different framework), or are changes to the definition >> allowed? Good question. I mean "replaces" or "supersedes", where going forward the new Precis usage is intended to be used instead of the old Stringprep profile when handling the relevant protocol elements. For example, the Precis profiles we're defining in draft-ietf-xmpp-6122bis for XMPP localparts and resourceparts are intended to be used in the future instead of the Nodeprep and Resourceprep profiles of Stringprep first defined in RFC 3920. Although in the XMPP community we are working to make sure that the new Precis profiles have very similar output to the old Stringprep profiles (i.e., the same result using a different framework), I think any changes to the definition are a matter for the application protocol and not the Precis framework. Another way to handle this matter is to make sure that the application protocol specs contain an IANA action to change the status of the relevant Stringprep profile(s): http://www.iana.org/assignments/stringprep-profiles/stringprep-profiles.xml Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBfQkUACgkQNL8k5A2w/vzGSACgtudyUwkQ48ssylX2LjC9OLja Oi8AoNG6xUGKCHBKnk2M1qNa4OckcQRl =QnFO -----END PGP SIGNATURE----- From stpeter@stpeter.im Sun Sep 23 10:55:19 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A76A621F84F5 for ; Sun, 23 Sep 2012 10:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6dvr-8BBtqe for ; Sun, 23 Sep 2012 10:55:19 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1885A21F84B6 for ; Sun, 23 Sep 2012 10:55:19 -0700 (PDT) Received: from [192.168.1.197] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4A90E40E08 for ; Sun, 23 Sep 2012 11:56:37 -0600 (MDT) Message-ID: <505F4D08.70205@stpeter.im> Date: Sun, 23 Sep 2012 11:55:20 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "precis@ietf.org" X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [precis] order of mapping in draft-yoneya-precis-mappings X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2012 17:55:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Section 5 of draft-yoneya-precis-mappings states that the additional mappings are to be performed before applying the rules from draft-ietf-precis-framework. This seems to imply that these additional mappings will be applied before Unicode normalization. In Vancouver, I thought we concluded that we want to perform normalization before applying other mappings (as is done in IDNA2008). It would be good for us to be completely clear about the order here, in the framework spec, and in the specs for application protocols that reuse PRECIS. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBfTQgACgkQNL8k5A2w/vy7OACg1RXn1DY4aGioUJPBV/WnhUe7 bHsAnjoO8/md8c97YQyQed3+tAv4vCDN =fMhi -----END PGP SIGNATURE----- From internet-drafts@ietf.org Sun Sep 23 11:12:27 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF5021F84FC; Sun, 23 Sep 2012 11:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.493 X-Spam-Level: X-Spam-Status: No, score=-102.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HgCsVppHuN7I; Sun, 23 Sep 2012 11:12:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 811F821F8512; Sun, 23 Sep 2012 11:12:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120923181226.7826.8087.idtracker@ietfa.amsl.com> Date: Sun, 23 Sep 2012 11:12:26 -0700 Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-framework-06.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2012 18:12:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Preparation and Comparison of Internation= alized Strings Working Group of the IETF. Title : PRECIS Framework: Preparation and Comparison of Internat= ionalized Strings in Application Protocols Author(s) : Peter Saint-Andre Marc Blanchet Filename : draft-ietf-precis-framework-06.txt Pages : 67 Date : 2012-09-23 Abstract: Application protocols using Unicode code points in protocol strings need to prepare such strings in order to perform comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation and comparison of internationalized strings (a.k.a. "PRECIS") in a way that depends on the properties of Unicode code points and thus is agile with respect to versions of Unicode. As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454). A specification that reuses this framework can either directly use the base string classes or subclass the base string classes as needed. This framework takes an approach similar to the revised internationalized domain names in applications (IDNA) technology (RFC 5890, RFC 5891, RFC 5892, RFC 5893, RFC 5894) and thus adheres to the high-level design goals described in RFC 4690, albeit for application technologies other than the Domain Name System (DNS). 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-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-precis-framework-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sun Sep 23 11:12:47 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB85B21F851B; Sun, 23 Sep 2012 11:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-XpIJGN2uKm; Sun, 23 Sep 2012 11:12:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C1721F851E; Sun, 23 Sep 2012 11:12:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120923181247.12678.53883.idtracker@ietfa.amsl.com> Date: Sun, 23 Sep 2012 11:12:47 -0700 Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-nickname-02.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2012 18:12:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Preparation and Comparison of Internation= alized Strings Working Group of the IETF. Title : Preparation and Comparison of Nicknames Author(s) : Peter Saint-Andre Filename : draft-ietf-precis-nickname-02.txt Pages : 7 Date : 2012-09-23 Abstract: This document describes how to prepare and compare Unicode strings representing nicknames, primarily as used within textual chatrooms. This profile is intended to be used by chatroom technologies based on both the Message Session Relay Protocol (MSRP) and the Extensible Messaging and Presence Protocol (XMPP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-nickname There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-precis-nickname-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-precis-nickname-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stpeter@stpeter.im Sun Sep 23 11:19:41 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C64421F84A1 for ; Sun, 23 Sep 2012 11:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcNJTF4bsfx6 for ; Sun, 23 Sep 2012 11:19:40 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0AAA521F848B for ; Sun, 23 Sep 2012 11:19:39 -0700 (PDT) Received: from [192.168.1.197] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1C5EC40DA5 for ; Sun, 23 Sep 2012 12:20:58 -0600 (MDT) Message-ID: <505F52BD.8070807@stpeter.im> Date: Sun, 23 Sep 2012 12:19:41 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: precis@ietf.org References: <20120923181226.7826.8087.idtracker@ietfa.amsl.com> In-Reply-To: <20120923181226.7826.8087.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [precis] I-D Action: draft-ietf-precis-framework-06.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2012 18:19:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Editorial review and proposed changes to the IANA registration rules. I figured that publishing a revised I-D would be the easiest way for folks to review the changes I have proposed... On 9/23/12 12:12 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Preparation and > Comparison of Internationalized Strings Working Group of the IETF. > > Title : PRECIS Framework: Preparation and Comparison of > Internationalized Strings in Application Protocols Author(s) > : Peter Saint-Andre Marc Blanchet Filename : > draft-ietf-precis-framework-06.txt Pages : 67 Date > : 2012-09-23 > > Abstract: Application protocols using Unicode code points in > protocol strings need to prepare such strings in order to perform > comparison operations (e.g., for purposes of authentication or > authorization). This document defines a framework enabling > application protocols to perform the preparation and comparison of > internationalized strings (a.k.a. "PRECIS") in a way that depends > on the properties of Unicode code points and thus is agile with > respect to versions of Unicode. As a result, this framework > provides a more sustainable approach to the handling of > internationalized strings than the previous framework, known as > Stringprep (RFC 3454). A specification that reuses this framework > can either directly use the base string classes or subclass the > base string classes as needed. This framework takes an approach > similar to the revised internationalized domain names in > applications (IDNA) technology (RFC 5890, RFC 5891, RFC 5892, RFC > 5893, RFC 5894) and thus adheres to the high-level design goals > described in RFC 4690, albeit for application technologies other > than the Domain Name System (DNS). 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-06 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-framework-06 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ precis mailing > list precis@ietf.org https://www.ietf.org/mailman/listinfo/precis > - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBfUr0ACgkQNL8k5A2w/vxg0gCgnIuDr283yV0JkVEi/QRYrK78 VngAoMe7SVrSFod/YJsjCe7laCJdFWBz =6zNv -----END PGP SIGNATURE----- From stpeter@stpeter.im Sun Sep 23 11:19:46 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89B821F84FD for ; Sun, 23 Sep 2012 11:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a07Q4TSPlo4h for ; Sun, 23 Sep 2012 11:19:46 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 53EC521F848B for ; Sun, 23 Sep 2012 11:19:46 -0700 (PDT) Received: from [192.168.1.197] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0697E40DA5 for ; Sun, 23 Sep 2012 12:21:04 -0600 (MDT) Message-ID: <505F52C5.3020506@stpeter.im> Date: Sun, 23 Sep 2012 12:19:49 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: precis@ietf.org References: <20120923181247.12678.53883.idtracker@ietfa.amsl.com> In-Reply-To: <20120923181247.12678.53883.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [precis] I-D Action: draft-ietf-precis-nickname-02.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2012 18:19:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Minor changes to align with the IANA registration template in the framework... On 9/23/12 12:12 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Preparation and > Comparison of Internationalized Strings Working Group of the IETF. > > Title : Preparation and Comparison of Nicknames Author(s) > : Peter Saint-Andre Filename : > draft-ietf-precis-nickname-02.txt Pages : 7 Date > : 2012-09-23 > > Abstract: This document describes how to prepare and compare > Unicode strings representing nicknames, primarily as used within > textual chatrooms. This profile is intended to be used by chatroom > technologies based on both the Message Session Relay Protocol > (MSRP) and the Extensible Messaging and Presence Protocol (XMPP). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-precis-nickname > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-precis-nickname-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-nickname-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ precis mailing > list precis@ietf.org https://www.ietf.org/mailman/listinfo/precis > - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBfUsQACgkQNL8k5A2w/vzvagCg2m0QHYTm99Y5jg3WjIa894mq grYAmwcQmKbw+795SEDq9FfM00MowusU =djOK -----END PGP SIGNATURE----- From stpeter@stpeter.im Sun Sep 23 11:32:59 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BEA921F851A for ; Sun, 23 Sep 2012 11:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJivF4FzTpWI for ; Sun, 23 Sep 2012 11:32:59 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 180FD21F8518 for ; Sun, 23 Sep 2012 11:32:59 -0700 (PDT) Received: from [192.168.1.197] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C11F940DA5 for ; Sun, 23 Sep 2012 12:34:17 -0600 (MDT) Message-ID: <505F55DD.8020500@stpeter.im> Date: Sun, 23 Sep 2012 12:33:01 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "precis@ietf.org" References: <505F55CF.3070006@stpeter.im> In-Reply-To: <505F55CF.3070006@stpeter.im> X-Enigmail-Version: 1.4.4 X-Forwarded-Message-Id: <505F55CF.3070006@stpeter.im> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [precis] Fwd: Re: [xmpp] I-D Action: draft-ietf-xmpp-6122bis-04.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2012 18:32:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI. - -------- Original Message -------- Subject: Re: [xmpp] I-D Action: draft-ietf-xmpp-6122bis-04.txt Date: Sun, 23 Sep 2012 12:32:47 -0600 From: Peter Saint-Andre To: xmpp@ietf.org Relatively minor changes to align with the PRECIS framework spec, and also a more substantive change to recommend mapping of fullwidth and halfwidth characters to their decomposition mappings... On 9/23/12 12:31 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Extensible Messaging > and Presence Protocol Working Group of the IETF. > > Title : Extensible Messaging and Presence Protocol > (XMPP): Address Format Author(s) : Peter Saint-Andre > Filename : draft-ietf-xmpp-6122bis-04.txt Pages : 21 > Date : 2012-09-23 > > Abstract: This document defines the address format for the > Extensible Messaging and Presence Protocol (XMPP), including > support for code points outside the ASCII range. This document > obsoletes RFC 6122. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-6122bis-04 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ xmpp mailing list > xmpp@ietf.org https://www.ietf.org/mailman/listinfo/xmpp > _______________________________________________ xmpp mailing list xmpp@ietf.org https://www.ietf.org/mailman/listinfo/xmpp -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBfVd0ACgkQNL8k5A2w/vwZqQCgziBL0wmTDEwY6zl5ROSwPd4E 5l8AoOOKUeULvUKmD9ZDqI2A3bPo43YD =A6+P -----END PGP SIGNATURE----- From stpeter@stpeter.im Sun Sep 23 11:45:05 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A81121F8471 for ; Sun, 23 Sep 2012 11:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsiMw17182oG for ; Sun, 23 Sep 2012 11:45:04 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 82E8421F846B for ; Sun, 23 Sep 2012 11:45:04 -0700 (PDT) Received: from [192.168.1.197] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3247940DA5 for ; Sun, 23 Sep 2012 12:46:23 -0600 (MDT) Message-ID: <505F58B2.1010207@stpeter.im> Date: Sun, 23 Sep 2012 12:45:06 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "precis@ietf.org" References: <20120923184314.9420.26172.idtracker@ietfa.amsl.com> In-Reply-To: <20120923184314.9420.26172.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.4 X-Forwarded-Message-Id: <20120923184314.9420.26172.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [precis] Fwd: I-D Action: draft-melnikov-precis-saslprepbis-04.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2012 18:45:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As with the precis-nickname and xmpp-6122bis, updated to reflect the newer IANA registration rules. Also beefed up the migration section per recent list discussion. - -------- Original Message -------- Subject: I-D Action: draft-melnikov-precis-saslprepbis-04.txt Date: Sun, 23 Sep 2012 11:43:14 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Preparation and Comparison of Internationalized Strings Representing Simple User Names and Passwords Author(s) : Peter Saint-Andre Alexey Melnikov Filename : draft-melnikov-precis-saslprepbis-04.txt Pages : 12 Date : 2012-09-23 Abstract: This document describes how to handle Unicode strings representing simple user names and passwords, primarily for purposes of comparison. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN and SCRAM-SHA-1), as well as other protocols that exchange simple user names or passwords. This document obsoletes RFC 4013. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-melnikov-precis-saslprepbis There's also a htmlized version available at: http://tools.ietf.org/html/draft-melnikov-precis-saslprepbis-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-melnikov-precis-saslprepbis-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBfWLIACgkQNL8k5A2w/vwHLQCgpEmOWokgQpjOvXpbmdU/XoDU IcMAoJNHMkjfjTX2hURDwtL3fZUs0ues =yGAw -----END PGP SIGNATURE----- From duerst@it.aoyama.ac.jp Mon Sep 24 00:06:18 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C7621E8043 for ; Mon, 24 Sep 2012 00:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.173 X-Spam-Level: X-Spam-Status: No, score=-101.173 tagged_above=-999 required=5 tests=[AWL=-1.383, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlGFj9qxYJnD for ; Mon, 24 Sep 2012 00:06:17 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 9166921E8040 for ; Mon, 24 Sep 2012 00:06:15 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q8O764Zc017835 for ; Mon, 24 Sep 2012 16:06:05 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 114b_8ae6_4de4e4ac_0616_11e2_a0bb_001d096c566a; Mon, 24 Sep 2012 16:06:03 +0900 Received: from [IPv6:::1] ([133.2.210.1]:33021) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 24 Sep 2012 16:06:04 +0900 Message-ID: <5060065A.6050108@it.aoyama.ac.jp> Date: Mon, 24 Sep 2012 16:06:02 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Peter Saint-Andre References: <5059D4CF.30206@stpeter.im> <505A2025.1000608@stpeter.im> <505A6682.9040304@it.aoyama.ac.jp> <505C7D56.9010106@stpeter.im> <505CA5C4.1050904@stpeter.im> <505CB79A.1010202@stpeter.im> <505D9C23.1090307@it.aoyama.ac.jp> <505F4245.7040708@stpeter.im> In-Reply-To: <505F4245.7040708@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "precis@ietf.org" Subject: Re: [precis] registration policy for subclasses X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 07:06:18 -0000 Given that there are quite a lot of ways in which this "obsoletion" can happen, I think an entry of the form Obsoletes: foo is totally inappropriate. It should be replaced by some more detailled description, such as (just an example): Historical Relationship: This registration is intended to replace the "foo" stringprep profile wherever possible. It the data has been carefully checked to avoid any changes from the "foo" profile, with the exception that this profile is no longer based on a fixed version of Unicode and therefore includes more characters. Also, the two characters BAR and BAZ were excluded because they lead to heavy ... in practice. Specifications are recommended to update their references to this registration after a careful analysis of the consequences. As I said, this is just an example, but I hope it shows the idea. Regards, Martin. On 2012/09/24 2:09, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 9/22/12 5:08 AM, "Martin J. Dürst" wrote: >> On 2012/09/22 3:53, Peter Saint-Andre wrote: One further thought: >> would it make sense to capture the fact that some new precis usages >> obsolete a old stringprep profiles? >> >>> What does "obsoletes" mean here? Is the result still the same >>> (just a different framework), or are changes to the definition >>> allowed? > > Good question. I mean "replaces" or "supersedes", where going forward > the new Precis usage is intended to be used instead of the old > Stringprep profile when handling the relevant protocol elements. For > example, the Precis profiles we're defining in draft-ietf-xmpp-6122bis > for XMPP localparts and resourceparts are intended to be used in the > future instead of the Nodeprep and Resourceprep profiles of Stringprep > first defined in RFC 3920. Although in the XMPP community we are > working to make sure that the new Precis profiles have very similar > output to the old Stringprep profiles (i.e., the same result using a > different framework), I think any changes to the definition are a > matter for the application protocol and not the Precis framework. > > Another way to handle this matter is to make sure that the application > protocol specs contain an IANA action to change the status of the > relevant Stringprep profile(s): > > http://www.iana.org/assignments/stringprep-profiles/stringprep-profiles.xml > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iEYEARECAAYFAlBfQkUACgkQNL8k5A2w/vzGSACgtudyUwkQ48ssylX2LjC9OLja > Oi8AoNG6xUGKCHBKnk2M1qNa4OckcQRl > =QnFO > -----END PGP SIGNATURE----- > From stpeter@stpeter.im Mon Sep 24 08:04:34 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2786721F87C8 for ; Mon, 24 Sep 2012 08:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.431 X-Spam-Level: X-Spam-Status: No, score=-102.431 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UaJ7bEn-2Jaf for ; Mon, 24 Sep 2012 08:04:33 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFF621F87C4 for ; Mon, 24 Sep 2012 08:04:33 -0700 (PDT) Received: from [64.101.72.41] (unknown [64.101.72.41]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 42ABB40E10; Mon, 24 Sep 2012 09:05:54 -0600 (MDT) Message-ID: <5060711D.8010200@stpeter.im> Date: Mon, 24 Sep 2012 08:41:33 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <5059D4CF.30206@stpeter.im> <505A2025.1000608@stpeter.im> <505A6682.9040304@it.aoyama.ac.jp> <505C7D56.9010106@stpeter.im> <505CA5C4.1050904@stpeter.im> <505CB79A.1010202@stpeter.im> <505D9C23.1090307@it.aoyama.ac.jp> <505F4245.7040708@stpeter.im> <5060065A.6050108@it.aoyama.ac.jp> In-Reply-To: <5060065A.6050108@it.aoyama.ac.jp> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "precis@ietf.org" Subject: Re: [precis] registration policy for subclasses X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 15:04:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 You're probably right. Those "in the know" who actually read the relevant specs are well aware of these historical relationships. Tracking which PRECIS usages replace which Stringprep profiles might be something that is better left to a wiki, not an IANA registry. On 9/24/12 1:06 AM, "Martin J. Dürst" wrote: > Given that there are quite a lot of ways in which this "obsoletion" > can happen, I think an entry of the form > > Obsoletes: foo > > is totally inappropriate. It should be replaced by some more > detailled description, such as (just an example): > > Historical Relationship: This registration is intended to replace > the "foo" stringprep profile wherever possible. It the data has > been carefully checked to avoid any changes from the "foo" profile, > with the exception that this profile is no longer based on a fixed > version of Unicode and therefore includes more characters. Also, > the two characters BAR and BAZ were excluded because they lead to > heavy ... in practice. Specifications are recommended to update > their references to this registration after a careful analysis of > the consequences. > > As I said, this is just an example, but I hope it shows the idea. > > Regards, Martin. > > On 2012/09/24 2:09, Peter Saint-Andre wrote: On 9/22/12 5:08 AM, > "Martin J. Dürst" wrote: >>>> On 2012/09/22 3:53, Peter Saint-Andre wrote: One further >>>> thought: would it make sense to capture the fact that some >>>> new precis usages obsolete a old stringprep profiles? >>>> >>>>> What does "obsoletes" mean here? Is the result still the >>>>> same (just a different framework), or are changes to the >>>>> definition allowed? > > Good question. I mean "replaces" or "supersedes", where going > forward the new Precis usage is intended to be used instead of the > old Stringprep profile when handling the relevant protocol > elements. For example, the Precis profiles we're defining in > draft-ietf-xmpp-6122bis for XMPP localparts and resourceparts are > intended to be used in the future instead of the Nodeprep and > Resourceprep profiles of Stringprep first defined in RFC 3920. > Although in the XMPP community we are working to make sure that the > new Precis profiles have very similar output to the old Stringprep > profiles (i.e., the same result using a different framework), I > think any changes to the definition are a matter for the > application protocol and not the Precis framework. > > Another way to handle this matter is to make sure that the > application protocol specs contain an IANA action to change the > status of the relevant Stringprep profile(s): > > http://www.iana.org/assignments/stringprep-profiles/stringprep-profiles.xml > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBgcR0ACgkQNL8k5A2w/vyJFwCgpalBsopDctr2HxMtTiI2Sn68 u3wAoJL5N45YgkHDBranX7O2t1Cy/3mJ =qQQ/ -----END PGP SIGNATURE----- From alexey.melnikov@isode.com Tue Sep 25 04:32:40 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7563921F88A0 for ; Tue, 25 Sep 2012 04:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.644 X-Spam-Level: X-Spam-Status: No, score=-101.644 tagged_above=-999 required=5 tests=[AWL=-0.637, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DggcPpBFJLF7 for ; Tue, 25 Sep 2012 04:32:39 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id C3F7721F88AB for ; Tue, 25 Sep 2012 04:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1348572743; d=isode.com; s=selector; i=@isode.com; bh=dFEK3JXGyLhL/zM+9BnvupiMHr6NYt9z8dYU7XbVNGA=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=PD7Vkvmi/DQyML5S04kctRNxBAxS7H792I/ylLDB9+2AkEpyA68Q2OOUxiHOhaBlsVaCsw glZdZqnk/EG22rcDQQY5JH02cMoxYWVucl9pWwnhPHDw5/AS+gQmuXhgU0kg2XLtLpX9DV y8YPd25pDBymSq1GhPfK8gsclIxHkwk=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 25 Sep 2012 12:32:23 +0100 Message-ID: <5060BD8D.5090600@isode.com> Date: Mon, 24 Sep 2012 21:07:41 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Peter Saint-Andre References: <20120914162208.30845.65648.idtracker@ietfa.amsl.com> <50535A6B.8010702@stpeter.im> <8FD6CBCE-60CD-4049-A0E6-B2388D6919DF@cisco.com> <817D19D4-1615-440A-8F75-DEAEFE0BEA58@isode.com> <5057821A.1050903@stpeter.im> In-Reply-To: <5057821A.1050903@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "precis@ietf.org" Subject: Re: [precis] Review of draft-melnikov-precis-saslprepbis-03 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 11:32:40 -0000 On 17/09/2012 21:03, Peter Saint-Andre wrote: > On 9/17/12 12:21 PM, Alexey Melnikov wrote: >> On 17 Sep 2012, at 19:09, "Matt Miller (mamille2)" >> wrote: > [I agree with the other points that Matt raised. Thanks for the review!] > >>> * 3.2 (Passwords - Preparation) :: I do wonder about the >>> rationale for step 2) (map all non-ASCII space to ASCII space). >>> I myself have not run into conditions where this would matter, >>> but I mostly deal with US-based consumers with passwords almost >>> exclusively in the ASCII range. On the surface, it seems a bit >>> contradictory in principle to the "no bidi rule" rationale that >>> is included. I'm not advocating for retention or removal of step >>> 2), but rather for providing a rationale (one way or the other). >> This rule was always in SASLPrep, so this is trying to preserve >> some sort of backward compatibility. Whether it is a good enough >> reason to keep the rule - I don't know. > This rule applied to stringprep via Appendix B.1 in RFC 3454: > > http://tools.ietf.org/html/rfc3454#appendix-B.1 > > In the interest of full disclosure, the code points involved were: > > U+00AD SOFT HYPHEN > U+034F COMBINING GRAPHEME JOINER > U+1806 MONGOLIAN TODO SOFT HYPHEN > U+180B MONGOLIAN FREE VARIATION SELECTOR ONE > U+180C MONGOLIAN FREE VARIATION SELECTOR TWO > U+180D MONGOLIAN FREE VARIATION SELECTOR THREE > U+200B ZERO WIDTH SPACE > U+200C ZERO WIDTH NON-JOINER > U+200D ZERO WIDTH JOINER > U+2060 WORD JOINER > U+FE00 VARIATION SELECTOR-1 > [...other variation selectors here...] > U+FE0F VARIATION SELECTOR-13 > U+FEFF ZERO WIDTH NO-BREAK SPACE > > As far as I can see, we have two alternatives for SASLprep-bis: > > 1. Continue to map those code points to nothing. Did you mean "continue to map them to U+0020"? > 2. Disallow those code points by subclassing the FreeClass. > > I don't have a strong feeling either way, although mapping to nothing > has always struck me as a wimpy approach and I'd probably prefer to > explicitly disallow unwanted code points... From stpeter@stpeter.im Tue Sep 25 12:26:03 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70D3A21F88A4 for ; Tue, 25 Sep 2012 12:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.28 X-Spam-Level: X-Spam-Status: No, score=-102.28 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlddjZ3JEzXu for ; Tue, 25 Sep 2012 12:26:02 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7744A21F889A for ; Tue, 25 Sep 2012 12:26:02 -0700 (PDT) Received: from [64.101.72.41] (unknown [64.101.72.41]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2268040067; Tue, 25 Sep 2012 13:27:26 -0600 (MDT) Message-ID: <50620548.7010004@stpeter.im> Date: Tue, 25 Sep 2012 13:26:00 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Alexey Melnikov References: <20120914162208.30845.65648.idtracker@ietfa.amsl.com> <50535A6B.8010702@stpeter.im> <8FD6CBCE-60CD-4049-A0E6-B2388D6919DF@cisco.com> <817D19D4-1615-440A-8F75-DEAEFE0BEA58@isode.com> <5057821A.1050903@stpeter.im> <5060BD8D.5090600@isode.com> In-Reply-To: <5060BD8D.5090600@isode.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "precis@ietf.org" Subject: Re: [precis] Review of draft-melnikov-precis-saslprepbis-03 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 19:26:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/24/12 2:07 PM, Alexey Melnikov wrote: > On 17/09/2012 21:03, Peter Saint-Andre wrote: >> On 9/17/12 12:21 PM, Alexey Melnikov wrote: >>> On 17 Sep 2012, at 19:09, "Matt Miller (mamille2)" >>> wrote: >> [I agree with the other points that Matt raised. Thanks for the >> review!] >> >>>> * 3.2 (Passwords - Preparation) :: I do wonder about the >>>> rationale for step 2) (map all non-ASCII space to ASCII >>>> space). I myself have not run into conditions where this >>>> would matter, but I mostly deal with US-based consumers with >>>> passwords almost exclusively in the ASCII range. On the >>>> surface, it seems a bit contradictory in principle to the "no >>>> bidi rule" rationale that is included. I'm not advocating for >>>> retention or removal of step 2), but rather for providing a >>>> rationale (one way or the other). >>> This rule was always in SASLPrep, so this is trying to >>> preserve some sort of backward compatibility. Whether it is a >>> good enough reason to keep the rule - I don't know. >> This rule applied to stringprep via Appendix B.1 in RFC 3454: >> >> http://tools.ietf.org/html/rfc3454#appendix-B.1 >> >> In the interest of full disclosure, the code points involved >> were: >> >> U+00AD SOFT HYPHEN U+034F COMBINING GRAPHEME JOINER U+1806 >> MONGOLIAN TODO SOFT HYPHEN U+180B MONGOLIAN FREE VARIATION >> SELECTOR ONE U+180C MONGOLIAN FREE VARIATION SELECTOR TWO U+180D >> MONGOLIAN FREE VARIATION SELECTOR THREE U+200B ZERO WIDTH SPACE >> U+200C ZERO WIDTH NON-JOINER U+200D ZERO WIDTH JOINER U+2060 WORD >> JOINER U+FE00 VARIATION SELECTOR-1 [...other variation selectors >> here...] U+FE0F VARIATION SELECTOR-13 U+FEFF ZERO WIDTH NO-BREAK >> SPACE >> >> As far as I can see, we have two alternatives for SASLprep-bis: >> >> 1. Continue to map those code points to nothing. > Did you mean "continue to map them to U+0020"? No, but I might not have said what I meant. :) RFC 4013 specified two mappings: 1. Map non-ASCII space characters to U+0020. This applied to the code points listed in Appendix C.1.2 of RFC 3454, i.e.: U+00A0 NO-BREAK SPACE U+1680 OGHAM SPACE MARK U+2000 EN QUAD U+2001 EM QUAD U+2002 EN SPACE U+2003 EM SPACE U+2004 THREE-PER-EM SPACE U+2005 FOUR-PER-EM SPACE U+2006 SIX-PER-EM SPACE U+2007 FIGURE SPACE U+2008 PUNCTUATION SPACE U+2009 THIN SPACE U+200A HAIR SPACE U+200B ZERO WIDTH SPACE U+202F NARROW NO-BREAK SPACE U+205F MEDIUM MATHEMATICAL SPACE U+3000 IDEOGRAPHIC SPACE I think that mapping continues to make sense for passwords (it doesn't apply to usernames because the PRECIS usage for the SASL builds on NameClass). However, the reasoning provided in RFC 3454 might lead us to conclude that non-ASCII space characters are acceptable in passwords: Space characters can make accurate visual transcription of strings nearly impossible and could lead to user entry errors in many ways. I don't see a strong reason to allow the non-ASCII space characters (we've got plenty of entropy as it is), but I wouldn't object if people wanted to allow them. 2. Map the "commonly mapped to nothing" characters to nothing (i.e., delete them from the input string). This applied to the code points listed in Appendix B.1 of RFC 3454, i.e.: U+00AD SOFT HYPHEN U+034F COMBINING GRAPHEME JOINER U+1806 MONGOLIAN TODO SOFT HYPHEN U+180B MONGOLIAN FREE VARIATION SELECTOR ONE U+180C MONGOLIAN FREE VARIATION SELECTOR TWO U+180D MONGOLIAN FREE VARIATION SELECTOR THREE U+200B ZERO WIDTH SPACE U+200C ZERO WIDTH NON-JOINER U+200D ZERO WIDTH JOINER U+2060 WORD JOINER U+FE00 VARIATION SELECTOR-1 [...other variation selectors here...] U+FE0F VARIATION SELECTOR-13 U+FEFF ZERO WIDTH NO-BREAK SPACE (Strangely, as noted, U+200B ZERO WIDTH SPACE shows up in both of those lists.) I think that mapping continues to make sense for usernames and passwords because, as noted in Section 3.1 of RFC 3454, some of those characters "are only useful in line-based text, and are otherwise invisible and ignored" whereas the others "affect glyph choice and glyph placement, but do not bear semantics". Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBiBUgACgkQNL8k5A2w/vzx3QCeOUr8swxEw7GKvFanlFk+Ogg7 ThsAnAxDvPm5ZB5pmRh0Y/G3SlvJxK9X =h2Lm -----END PGP SIGNATURE----- From stpeter@stpeter.im Thu Sep 27 17:32:21 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83CA321F8530 for ; Thu, 27 Sep 2012 17:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UF-lttUYst7Y for ; Thu, 27 Sep 2012 17:32:20 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A726721F8546 for ; Thu, 27 Sep 2012 17:32:20 -0700 (PDT) Received: from [192.168.1.249] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9EA9240058; Thu, 27 Sep 2012 18:33:52 -0600 (MDT) Message-ID: <5064E44E.8080305@stpeter.im> Date: Thu, 27 Sep 2012 17:42:06 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <505B6F19.109@stpeter.im> <505D9BA9.7010505@it.aoyama.ac.jp> In-Reply-To: <505D9BA9.7010505@it.aoyama.ac.jp> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "precis@ietf.org" Subject: Re: [precis] width mapping in draft-yoneya-precis-mappings X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 00:32:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Martin, thanks for the helpful explanation. Comments at end. On 9/22/12 5:06 AM, "Martin J. Dürst" wrote: > Hello Peter, others, > > On 2012/09/21 4:31, Peter Saint-Andre wrote: Section 3.1 of > draft-yoneya-precis-mappings states: > > Width mapping will increase backward compatibility with Stringprep > [RFC3454] and precis framework [I-D.ietf-precis-framework]. > Because in a Stringprep profile which specifies Unicode > normalization form KC (NFKC) for normalization method, > fullwidth/halfwidth characters are mapped into its compatible form. > If a precis framework profile specified NFKC (which is not > recommended), width mapping might not be useful. > > Is backward compatibility the only reason to specify width > mapping? > >> I very much don't think so. The full-width/half-width distinction >> that came to Unicode from East Asian Encodings is an artifact >> from the age of fixed character cell widths. In high-quality >> typesetting, there are various conventions for when to use one or >> the other form (and the "half-width" form is set in proportional >> type). But in everyday use, it's just mostly happenstance that >> decides which form is used. > > If so, then it would be good to say that width mapping is > appropriate for technologies that are migrating from stringprep > (with NFKC) to precis, but not for technologies that never had a > stringprep profile. > > If not, then it would be good to explain why it can be appropriate > for a technology that uses precis (but never used stringprep) to > specify width mapping. For example, perhaps width mapping helps to > prevent violations of the "principle of least user surprise" > because users in language communities with fullwidth and halfwidth > characters might not be able to tell the difference between various > widths on common devices. > >> "Might not be able to tell the difference" is the wrong >> expression. It's not too difficult to spot and identify the >> difference. It's much more a "not being motivated to spot the >> difference". An average American reader would be perfectly able >> to tell the difference between serif and sans-serif type. But >> when they read or write something, they (in most cases) just >> don't care. Why should they? > >> So (I wish it were not, but) indeed width mapping is way more >> important than just for backwards compatibility. > >> NFKC is in stringprep simply because the design team wanted to >> have a width mapping for IDNA 2003, and specifying NFKC was the >> easiest way to get there. In practice, width mapping is way more >> important than many of the mappings in NFC. And it's definitely >> the most important part of NFKC. > > In my opinion, some discussion of the security implications of > width mapping (e.g., the possibility of more "fase positives") > would also be helpful. > >> I don't think there will be false positives. Saying that e.g. IBM >> and ＩＢＭ are should be two different things is simply crazy. So it >> should be either width mapping, or the less basic forms (i.e. >> full-width for Latin and half-width for Kana,...) should be >> prohibited. That all makes sense. It sounds as if we'll want to advise PRECIS usages and subclasses to strongly consider performing width mapping. Do you think it is so important that we ought to think about adding it to the framework alongside casemapping and the other "first-class" PRECIS rules? Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBk5E4ACgkQNL8k5A2w/vxsDQCdHj7nRoX89MWQ36b0LdOAKhei yzgAn17jS1E1yUxbOLvX30As1K0pge97 =SJnY -----END PGP SIGNATURE-----