From nobody Tue Apr 7 21:31:04 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8741B2DCF; Tue, 7 Apr 2015 21:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uD9dJlE6xR1o; Tue, 7 Apr 2015 21:31:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFD21B2DD3; Tue, 7 Apr 2015 21:31:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150408043100.24615.54372.idtracker@ietfa.amsl.com> Date: Tue, 07 Apr 2015 21:31:00 -0700 Archived-At: Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-mappings-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 04:31:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Preparation and Comparison of Internationalized Strings Working Group of the IETF. Title : Mapping characters for PRECIS classes Authors : Yoshiro YONEYA Takahiro Nemoto Filename : draft-ietf-precis-mappings-09.txt Pages : 11 Date : 2015-04-07 Abstract: The framework for preparation and comparison of internationalized strings ("PRECIS") defines several classes of strings for preparation and comparison. Case mapping is defined because many protocols perform case-sensitive or case-insensitive string comparison and so preparation of the string is mandatory. The Internationalized Domain Names in Applications (IDNA) and the PRECIS problem statement describes mappings for internationalized strings that are not limited to case, but include width mapping and mapping of delimiters and other specials that can be taken into consideration. This document provides guidelines for authors of protocol profiles of the PRECIS framework and describes several mappings that can be applied between receiving user input and passing permitted code points to internationalized protocols. The mappings described here are expected to be applied as an additional mapping and locale-/context- dependent case mapping. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-mappings/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-precis-mappings-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-mappings-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 7 23:31:37 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E92C1AD376 for ; Tue, 7 Apr 2015 23:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.702 X-Spam-Level: X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6CYHl86DggY for ; Tue, 7 Apr 2015 23:31:34 -0700 (PDT) Received: from mail.kmd.keio.ac.jp (mail.kmd.keio.ac.jp [131.113.138.164]) by ietfa.amsl.com (Postfix) with ESMTP id 862601AD370 for ; Tue, 7 Apr 2015 23:31:34 -0700 (PDT) Received: from [100.64.32.16] (unknown [133.2.56.33]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kmd.keio.ac.jp (Postfix) with ESMTPSA id 706207F978 for ; Wed, 8 Apr 2015 15:31:25 +0900 (JST) (envelope-from t.nemo10@kmd.keio.ac.jp) From: Takahiro Nemoto Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Apr 2015 15:31:22 +0900 References: <20150408043100.24615.54372.idtracker@ietfa.amsl.com> To: precis@ietf.org Message-Id: <37C9062B-A49C-482D-97AC-5CB2D0E3D968@kmd.keio.ac.jp> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [precis] Fwd: I-D Action: draft-ietf-precis-mappings-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 06:31:36 -0000 Dear all,=20 Yoneya-san and I have submitted the latest version of precis mappings = document.=20 As we have confirmed that there is not inconsistency between this = document and the latest framework document,=20 we think that this document is ready for WG LC.=20 So I would appreciate it if you could perform the WG LC again to this = document. Regards, Nemo -- Takahiro Nemoto t.nemo10@kmd.keio.ac.jp =E8=BB=A2=E9=80=81=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=83=E3=82=BB=E3= =83=BC=E3=82=B8=EF=BC=9A > =E5=B7=AE=E5=87=BA=E4=BA=BA: internet-drafts@ietf.org > =E4=BB=B6=E5=90=8D: [precis] I-D Action: = draft-ietf-precis-mappings-09.txt > =E6=97=A5=E4=BB=98: 2015=E5=B9=B44=E6=9C=888=E6=97=A5 13:31:00 JST > =E5=AE=9B=E5=85=88: > CC: precis@ietf.org >=20 >=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 : Mapping characters for PRECIS classes > Authors : Yoshiro YONEYA > Takahiro Nemoto > Filename : draft-ietf-precis-mappings-09.txt > Pages : 11 > Date : 2015-04-07 >=20 > Abstract: > The framework for preparation and comparison of internationalized > strings ("PRECIS") defines several classes of strings for = preparation > and comparison. Case mapping is defined because many protocols > perform case-sensitive or case-insensitive string comparison and so > preparation of the string is mandatory. The Internationalized = Domain > Names in Applications (IDNA) and the PRECIS problem statement > describes mappings for internationalized strings that are not = limited > to case, but include width mapping and mapping of delimiters and > other specials that can be taken into consideration. This document > provides guidelines for authors of protocol profiles of the PRECIS > framework and describes several mappings that can be applied between > receiving user input and passing permitted code points to > internationalized protocols. The mappings described here are > expected to be applied as an additional mapping and locale-/context- > dependent case mapping. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-precis-mappings/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-precis-mappings-09 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-precis-mappings-09 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis From nobody Wed Apr 8 05:49:17 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91F401A1ADB for ; Wed, 8 Apr 2015 05:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JENjQgUGyTBM for ; Wed, 8 Apr 2015 05:49:14 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id E1FC71A1AE3 for ; Wed, 8 Apr 2015 05:49:12 -0700 (PDT) Received: from h194.viagenie.ca (h194.viagenie.ca [206.123.31.194]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D980245D10 for ; Wed, 8 Apr 2015 08:49:14 -0400 (EDT) From: Marc Blanchet Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <0EE693CB-5411-44BD-A479-53249DE171BE@viagenie.ca> Date: Wed, 8 Apr 2015 08:49:11 -0400 To: precis@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [precis] WGLC on draft-ietf-precis-mappings X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 12:49:15 -0000 Hello, this is a 2 weeks working group last call (WGLC) on = draft-ietf-precis-mappings, starting today and closing on april 22nd = 23:59 UTC. Please send your comments and support to the list. Regards, Marc&Alexey= From nobody Wed Apr 8 12:26:40 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E2E1B354A for ; Wed, 8 Apr 2015 12:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sm8tkLcZF0z0 for ; Wed, 8 Apr 2015 12:26:37 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id E1EF21B354B for ; Wed, 8 Apr 2015 12:26:29 -0700 (PDT) Received: from kuwa.viagenie.ca (kuwa.viagenie.ca [206.123.31.98]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6F6B8403DC for ; Wed, 8 Apr 2015 15:26:31 -0400 (EDT) From: Marc Blanchet Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <193DDCE0-0CF6-4AB8-B47B-770EB3DCF7E4@viagenie.ca> Date: Wed, 8 Apr 2015 15:26:28 -0400 To: precis@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [precis] ietf dallas minutes X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 19:26:39 -0000 Hello, someone volunteered to take minutes of our session in Dallas. Could = that person please send me your notes, asap? Regards, Marc.= From nobody Thu Apr 9 07:14:16 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC0A1A1EF3 for ; Thu, 9 Apr 2015 07:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ci02qfsuPClF for ; Thu, 9 Apr 2015 07:14:13 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 85C1C1A1BED for ; Thu, 9 Apr 2015 07:14:13 -0700 (PDT) Received: from h194.viagenie.ca (h194.viagenie.ca [206.123.31.194]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 44EF940371 for ; Thu, 9 Apr 2015 10:14:15 -0400 (EDT) From: Marc Blanchet Content-Type: multipart/alternative; boundary="Apple-Mail=_5DF4FE25-786B-41C7-860C-5D0909FF819D" Message-Id: <12831B72-39E7-427B-80EA-5E610C2ADB14@viagenie.ca> Date: Thu, 9 Apr 2015 10:14:12 -0400 To: precis@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [precis] ietf dallas precis meeting minutes X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 14:14:15 -0000 --Apple-Mail=_5DF4FE25-786B-41C7-860C-5D0909FF819D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, I created short meeting minutes from memory. Posted = (https://www.ietf.org/proceedings/92/minutes/minutes-92-precis = ).=20 Please send any changes to the chairs = (mailto:precis-chairs@tools.ietf.org = ) Regards, Marc.= --Apple-Mail=_5DF4FE25-786B-41C7-860C-5D0909FF819D Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hello,
 I created short meeting minutes from memory. Posted (https://www.ietf.org/proceedings/92/minutes/minutes-92-precis). 

Please send any changes to the chairs (mailto:precis-chairs@tools.ietf.org)

Regards, Marc.
--Apple-Mail=_5DF4FE25-786B-41C7-860C-5D0909FF819D-- From nobody Fri Apr 10 14:26:53 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0369B1A8A6D for ; Fri, 10 Apr 2015 14:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.711 X-Spam-Level: X-Spam-Status: No, score=-5.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07iwBgWmDkC2 for ; Fri, 10 Apr 2015 14:26:48 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E89611A8A63 for ; Fri, 10 Apr 2015 14:26:47 -0700 (PDT) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t3ALQkKx015690 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 10 Apr 2015 17:26:46 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com t3ALQkKx015690 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1428701206; bh=YXMnaMqn0Fp/GUyorHdQoRV4UnM=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=XWOKFVuw0Wdxcp/tS7wNS5TiS8Jj7kXNSI8v2ZeKwPgJe+PYWZMGCMdA8r9zGBIkz k63b60oA/OlBVtcziK/OVOfSLXryZXXZcZM58+MR40oHPdvz8oLnnRBRWphcSGu2JL mudhZHf/eg/aX+OaJ0c7Qq+/aHh2w4Gx28R/M+C0= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com t3ALQkKx015690 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd06.lss.emc.com (RSA Interceptor); Fri, 10 Apr 2015 17:26:19 -0400 Received: from mxhub37.corp.emc.com (mxhub37.corp.emc.com [128.222.70.104]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t3ALQM2L006874 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Apr 2015 17:26:23 -0400 Received: from MXHUB107.corp.emc.com (10.253.50.23) by mxhub37.corp.emc.com (128.222.70.104) with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 10 Apr 2015 17:26:22 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.93]) by MXHUB107.corp.emc.com ([10.253.50.23]) with mapi id 14.03.0224.002; Fri, 10 Apr 2015 17:26:21 -0400 From: "Black, David" To: Marc Blanchet , "precis@ietf.org" Thread-Topic: WGLC on draft-ietf-precis-mappings - David Black's comments Thread-Index: AdBz1PsBmG6eyD0rQtCdzKpxK63LYQ== Date: Fri, 10 Apr 2015 21:26:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.131] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: [precis] WGLC on draft-ietf-precis-mappings - David Black's comments X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 21:26:52 -0000 The draft generally looks good - I have a few comments. [1] (editorial) Clarifications to the discussion of string matching. Section 1 Further, the handling of mappings other than case and width, such as delimiter, special, and local case, are also important in order to increase the probability that strings match as users expect. "increase the probability that strings match" -> "increase the probability that the resulting strings compare" Section 2.3 OLD The purpose of local case mapping is to increase the probability of a matching result from the comparison between uppercase and lowercase characters, targeting characters which mapping depends on locale or locale and context. NEW The purpose of local case mapping is to increase the probability of results that users expect when character case is changed (e.g., map uppercase to lowercase) between input and use in a protocol. Local case mapping selectively affects characters whose case mapping depends on locale or context. END OLD If an application supports users' locale and/or context , local case mapping can increase the probability of getting matching-results from the comparison between strings. NEW When an application supports users' locale and/or context, use of local case mapping can increase the probability that string comparisons yield the results that users expect. END [2] (technical) The use of mappings from SpecialCasing.txt is selective, based on locale and context. Section 1 OLD whereas the "local case mapping" rule provides an alternative to the case mapping rule specified in the PRECIS framework since it handles some locale-dependent and context-dependent mappings. NEW whereas the "local case mapping" rule provides locale-dependent and context-dependent alternative case mappings for specific target characters. Section 2.3 OLD The target characters of local case mapping are characters defined in the SpecialCasing.txt [Specialcasing] file in section 3.13 of the Unicode Standard [Unicode]. NEW The complete set of possible target characters for local case mapping are the characters specified in the SpecialCasing.txt [Specialcasing] file in section 3.13 of the Unicode Standard [Unicode], but the specific set of target characters selected for local case mapping depends on locale and/or context, as further explained in the SpeicalCasing.txt file. OLD The case folding method for a target character is to map into lower case as defined in SpecialCasing.txt. NEW The case folding method for a selected target character is to map into lower case as defined in SpecialCasing.txt. END [3] (editorial) Incomplete explanation in Appendix B Appendix B only states the result of Unicode default case folding of U+00DF; it needs to also state the result of Special Casing case folding. [4] (technical) Clarify Appendix C OLD As described in section Section 2.3, target characters of local case mapping are characters defined in SpecialCasing.txt. The Unicode Standard (at least, up to version 7.0.0) does not define mappings between "GREEK SMALL LETTER SIGMA" (U+03C3) (hereinafter referred to as "small sigma") and "GREEK SMALL LETTER FINAL SIGMA" (U+03C2) (hereinafter referred to as "final sigma") depend on context. Thus, final sigma is always mapped to small sigma by local case mapping. (Cf. Followings are comments in SpecialCasing.txt.) NEW As described in Section 2.3, the possible target characters of local case mapping are specified in SpecialCasing.txt. The Unicode Standard (at least, up to version 7.0.0) does not define any context-dependent mappings between "GREEK SMALL LETTER SIGMA" (U+03C3) (hereinafter refer= red to as "small sigma") and "GREEK SMALL LETTER FINAL SIGMA" (U+03C2) (hereinafter referred to as "final sigma"). Thus, local case mapping is not applicable to small sigma or final sigma, so case mapping in=20 the PRECIS framework always maps final sigma to small sigma, independent of context, as specified by Unicode Default Case Folding. (Note: Following comments are from SpecialCasing.txt.) END Thanks, --David > -----Original Message----- > From: precis [mailto:precis-bounces@ietf.org] On Behalf Of Marc Blanchet > Sent: Wednesday, April 08, 2015 8:49 AM > To: precis@ietf.org > Subject: [precis] WGLC on draft-ietf-precis-mappings >=20 > Hello, > this is a 2 weeks working group last call (WGLC) on draft-ietf-precis- > mappings, starting today and closing on april 22nd 23:59 UTC. Please send= your > comments and support to the list. >=20 > Regards, Marc&Alexey > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis From nobody Mon Apr 13 04:51:05 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 898611A924C for ; Mon, 13 Apr 2015 04:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.689 X-Spam-Level: X-Spam-Status: No, score=0.689 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQHJ8c_tsrCg for ; Mon, 13 Apr 2015 04:51:02 -0700 (PDT) Received: from statler.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 7E94D1A916A for ; Mon, 13 Apr 2015 04:51:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1428925861; d=isode.com; s=selector; i=@isode.com; bh=uaYu/IP9YGtx26wjgZbF/7kTRq7nghHUOkmRvIOzYEQ=; 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=iFVm9YR/9IrsFpYqqD/IZmHv+rtbpoc6dWhHEjluz87krNBSx4EloW3dz9ocrEGYHyc8CF kpVMM720rD4hLOpQn9zY2kIEAafZS7TYyC+Ei1v6dlNk4MMdfABeYK05oi6UjIUDr02Xv5 +3Fc5Tfl/qKgVl5R8W83kHYy9MBYL5g=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 13 Apr 2015 12:51:01 +0100 Message-ID: <552BADA2.2060903@isode.com> Date: Mon, 13 Apr 2015 12:50:58 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 To: precis@ietf.org References: <0EE693CB-5411-44BD-A479-53249DE171BE@viagenie.ca> In-Reply-To: <0EE693CB-5411-44BD-A479-53249DE171BE@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [precis] WGLC on draft-ietf-precis-mappings X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 11:51:03 -0000 On 08/04/2015 13:49, Marc Blanchet wrote: > Hello, > this is a 2 weeks working group last call (WGLC) on draft-ietf-precis-mappings, starting today and closing on april 22nd 23:59 UTC. Please send your comments and support to the list. (As a participant) I re-reviewed the document and it looks reasonable to me. I agree with editorial suggestions suggested by David. From nobody Mon Apr 13 14:46:37 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A46C01A896B for ; Mon, 13 Apr 2015 14:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJdxY9Plttsq for ; Mon, 13 Apr 2015 14:46:34 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DCF41A8938 for ; Mon, 13 Apr 2015 14:46:34 -0700 (PDT) Received: by igblo3 with SMTP id lo3so58490269igb.1 for ; Mon, 13 Apr 2015 14:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=5J7ITm94bvkRrpTczk4xJSvCTXbYDgXaWpThbdAsMbQ=; b=pSqPTGvXXv6cWpOinzHabWIgkKLhrO5z7sNpQOqr23NHxDZa0flwtnwKRw2Jpwg3F3 yNTI0jDHHTGeY+igY5corFA7mummjxb6R2D53MJpgI8/S8cdJ0V1bRVI3TfjtN1l2meV 34IkKR6RRFUka1zfrSpz+SQaTD6ZwCPL2oOVxw0jMAGh1FM4ObdYhqUEf+N6Y3by2GyP QT6npGKWbdoIb+vdxh1CrI8cZ+6SnmlindQ+CUhZV8lF+AqjOinE4NqFwMEU+ARqJM1F Nw5nztsHj3CNZEg17G9sggGxB+4oSo8SHObq+eenotHm+kDlba9/BOSVFKRHL5gv+EaV USoQ== MIME-Version: 1.0 X-Received: by 10.50.1.47 with SMTP id 15mr798718igj.40.1428961593993; Mon, 13 Apr 2015 14:46:33 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.7.130 with HTTP; Mon, 13 Apr 2015 14:46:33 -0700 (PDT) Date: Mon, 13 Apr 2015 17:46:33 -0400 X-Google-Sender-Auth: jNsglS77X5DBsWsUGyHW-IGwsA8 Message-ID: From: Barry Leiba To: peter@andyet.com Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: precis@ietf.org Subject: [precis] AD review of draft-ietf-precis-nickname X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 21:46:35 -0000 I'm getting to the documents I picked up from Pete when he left the IESG. While I await the shepherd writeup for draft-ietf-precis-nickname, here's my AD review of it. The items marked "DISCUSS" below are things I think we need to resolve before I request last call. It'd be nice to sort out the others before then too, but I won't hold things up for them. -------- DISCUSS -- Section 1.2 -- Many important terms used in this document are defined in [I-D.ietf-precis-framework], [RFC6365], and [Unicode]. I think that makes 6365 a normative reference. -- Section 3 -- The following examples illustrate strings that are not valid nicknames because they violate the format defined above. For this and examples 9 and 10, I'm confused. The text above does not tell me that "foo bar" is not a valid nickname -- only that the process of preparing it for comparison normalizes it to "foo bar" (and similarly for " foo "). Where is it that you say that the application of rule 2 is different from the application of other rules? -------- COMMENT -- Section 2.2 -- An entity that performs enforcement according to this profile MUST prepare a string as described in the previous section and MUST also apply the rules specified below for the Nickname profile (these rules MUST be applied in the order shown). Is the first part of that sentence necessary? Section 2.1 already has MUSTs; why do we have to repeat that you MUST apply Section 2.1? I'd just say: NEW An entity that performs enforcement according to this profile MUST apply the rules specified below for the Nickname profile, in the order shown below. END 2. Leading and trailing whitespace (i.e., one or more instances of the ASCII space character at the beginning or end of a nickname) MUST be removed (e.g., "stpeter " is mapped to "stpeter"). Most of our protocols consider HTAB to be "whitespace", but it isn't here (CHARACTER TABULATION isn't in the Zs category). Is that OK? Is it worth specifically mentioning that, considering how common it is? -- Section 5 -- Why does the text for "case mapping rule" say "for comparison purposes", while none of the others do? Nothing in the document text makes the case mapping rule special. -- Barry, Applications AD From nobody Mon Apr 13 17:13:36 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D85FE1B2A92 for ; Mon, 13 Apr 2015 17:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gq0jdW_NpfPB for ; Mon, 13 Apr 2015 17:13:32 -0700 (PDT) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15F301B2A8E for ; Mon, 13 Apr 2015 17:13:32 -0700 (PDT) Received: by iebrs15 with SMTP id rs15so2624342ieb.3 for ; Mon, 13 Apr 2015 17:13:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=V0gvb6FpbVJCqLIflQsvrZcYQs79g9DVW8hDt3dWvbA=; b=CP8Wt4KtGvKWlB1CP3Bo0wc24DaCKBiWiUI8iTZcm9DwQMiMpMNBEnE41b8tPXAg25 p1yaqB/jrHnu1Q+43sGrZ/8Q5qDf0uuVgPe7UuqECuh+SfPG5fHlB8I1FZ+idHD5fBCq F64AUj90XOcM+2Tquhtj5C65Hcn+3SBnGVnhftI+xL7OkvMrSAuxsr2rO9kof8d6iZeC o1qRNPynHkfwX/vPGtFEPOeRavhw+g9W8R63yyPve6OGQb50ldd96BhKjrYQoUrhSOQ7 z2fJgbhiMEJ1iJ8J5zBxPxDlar8wCgz/tcRDc38eWygPWAr/LyT1t1pLBaoMR+qF6EZR rf5Q== X-Gm-Message-State: ALoCoQkl3AUbkSIs6S69OIW/bkwriD2kjAldbZkY5V2WYGWy6pr9sbABqVrPpDcPtW16g6AtXBsG X-Received: by 10.50.221.98 with SMTP id qd2mr20303499igc.37.1428970411403; Mon, 13 Apr 2015 17:13:31 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id r39sm5865680ioe.25.2015.04.13.17.13.30 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Apr 2015 17:13:30 -0700 (PDT) Message-ID: <552C5BA9.7000803@andyet.net> Date: Mon, 13 Apr 2015 18:13:29 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Barry Leiba References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: precis@ietf.org Subject: Re: [precis] AD review of draft-ietf-precis-nickname X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 00:13:34 -0000 Hi Barry, thanks for the review. On 4/13/15 3:46 PM, Barry Leiba wrote: > I'm getting to the documents I picked up from Pete when he left the > IESG. While I await the shepherd writeup for > draft-ietf-precis-nickname, here's my AD review of it. The items > marked "DISCUSS" below are things I think we need to resolve before I > request last call. It'd be nice to sort out the others before then > too, but I won't hold things up for them. > > -------- > DISCUSS > > -- Section 1.2 -- > > Many important terms used in this document are defined in > [I-D.ietf-precis-framework], [RFC6365], and [Unicode]. > > I think that makes 6365 a normative reference. Indeed. We'll want to fix that in draft-ietf-precis-saslprepbis, too. > -- Section 3 -- > > The following examples illustrate strings that are not valid > nicknames because they violate the format defined above. > > For this and examples 9 and 10, I'm confused. The text above does not > tell me that "foo bar" is not a valid nickname -- only that the > process of preparing it for comparison normalizes it to "foo bar" (and > similarly for " foo "). Where is it that you say that the application > of rule 2 is different from the application of other rules? Right. I suggest that remove the second table, then. > -------- > COMMENT > > -- Section 2.2 -- > > An entity that performs enforcement according to this profile MUST > prepare a string as described in the previous section and MUST also > apply the rules specified below for the Nickname profile (these rules > MUST be applied in the order shown). > > Is the first part of that sentence necessary? Section 2.1 already has > MUSTs; why do we have to repeat that you MUST apply Section 2.1? I'd > just say: > > NEW > An entity that performs enforcement according to this profile MUST > apply the rules specified below for the Nickname profile, in the > order shown below. > END According to draft-ietf-precis-framework, preparation and enforcement are two separate acts. In addition, the preparation rules (§2.1) need to be applied first in order for the enforcement rules (§2.2) to be done correctly. So I would say that the first part of the sentence is indeed necessary. > 2. Leading and trailing whitespace (i.e., one or more instances > of the ASCII space character at the beginning or end of a > nickname) MUST be removed (e.g., "stpeter " is mapped to > "stpeter"). > > Most of our protocols consider HTAB to be "whitespace", but it isn't > here (CHARACTER TABULATION isn't in the Zs category). Is that OK? Because U+0009 (CHARACTER TABULATION) is a control character, it is disallowed by the PRECIS framework. Therefore I think it is OK to not consider it here. > Is > it worth specifically mentioning that, considering how common it is? We could do this to remove the confusion: OLD 2. Leading and trailing whitespace (i.e., one or more instances of the ASCII space character at the beginning or end of a nickname) MUST be removed (e.g., "stpeter " is mapped to "stpeter"). NEW 2. Any instances of the ASCII space character at the beginning or end of a nickname MUST be removed (e.g., "stpeter " is mapped to "stpeter"). > -- Section 5 -- > Why does the text for "case mapping rule" say "for comparison > purposes", while none of the others do? Nothing in the document text > makes the case mapping rule special. I think that's an artifact of an earlier version and can safely be removed. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Mon Apr 13 17:52:02 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7811B2BA9 for ; Mon, 13 Apr 2015 17:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCDu650epo19 for ; Mon, 13 Apr 2015 17:52:00 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 390061B2BA8 for ; Mon, 13 Apr 2015 17:52:00 -0700 (PDT) Received: by iedfl3 with SMTP id fl3so3655193ied.1 for ; Mon, 13 Apr 2015 17:51:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=PnSEmNrb76oY+/3cfOvJExojMcq4G4CqsORlHgKVmyo=; b=kVNRSEznFvDHQIhGwUMlo1vhblX1vwl087PmkIsKod0W0rPt8iOFApZHMsIcqPLhY3 rALc62+E4gngxyreV6YdVq4Vx+w2ebNuV2nyOOAf4RHFowZw0OSqzVhAWtkgsDHtDXpQ IZHD9MlCGk7gqOftq9j3VbjZxQwJx62Hu7HTfk5LS9wYf5jFlclLgXp3+5aj2D4m9q8y wKUF9uAxQlH1JASjhGh4+GtM5pOlA5JjHwkynNllXiQS1tHh6UmPmdMVrx6mT6z99Alh +eOX6Jice36o0sdTfOQNLbWn77fh+uMq1KZFzFsuP9gIGFQiqGLp6lhW2US2ICTuPzNC M4zA== MIME-Version: 1.0 X-Received: by 10.43.55.12 with SMTP id vw12mr22216021icb.30.1428972719758; Mon, 13 Apr 2015 17:51:59 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.7.130 with HTTP; Mon, 13 Apr 2015 17:51:59 -0700 (PDT) In-Reply-To: <552C5BA9.7000803@andyet.net> References: <552C5BA9.7000803@andyet.net> Date: Mon, 13 Apr 2015 20:51:59 -0400 X-Google-Sender-Auth: eT_iY0k-nHeLW1swJe0PWzK-yWk Message-ID: From: Barry Leiba To: "Peter Saint-Andre - &yet" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: precis@ietf.org Subject: Re: [precis] AD review of draft-ietf-precis-nickname X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 00:52:01 -0000 > Hi Barry, thanks for the review. You're welcome. And all your answers are perfect. Please post a revised I-D, and I'll start last call as soon as I get a shepherd writeup. I'm reviewing saslprepbis now, so please hold off on revising that until I'm done (probably tomorrow). Barry From nobody Mon Apr 13 18:18:31 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7691B2BE8; Mon, 13 Apr 2015 18:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsKEHHFpiO46; Mon, 13 Apr 2015 18:18:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7651B2BEB; Mon, 13 Apr 2015 18:18:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150414011815.12157.60306.idtracker@ietfa.amsl.com> Date: Mon, 13 Apr 2015 18:18:15 -0700 Archived-At: Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-nickname-17.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 01:18:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Preparation and Comparison of Internationalized Strings Working Group of the IETF. Title : Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames Author : Peter Saint-Andre Filename : draft-ietf-precis-nickname-17.txt Pages : 9 Date : 2015-04-13 Abstract: This document describes methods for handling Unicode strings representing nicknames. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-nickname/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-precis-nickname-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-nickname-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 13 18:18:32 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 587FF1B2BF4; Mon, 13 Apr 2015 18:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDAtagxZLf4T; Mon, 13 Apr 2015 18:18:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E879E1B2BEE; Mon, 13 Apr 2015 18:18:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150414011815.12157.25066.idtracker@ietfa.amsl.com> Date: Mon, 13 Apr 2015 18:18:15 -0700 Archived-At: Subject: [precis] New Version Notification - draft-ietf-precis-nickname-17.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 01:18:22 -0000 A new version (-17) has been submitted for draft-ietf-precis-nickname: http://www.ietf.org/internet-drafts/draft-ietf-precis-nickname-17.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-nickname/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-nickname-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Mon Apr 13 19:13:32 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A661B2C7C for ; Mon, 13 Apr 2015 19:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-cgvLd0rhoh for ; Mon, 13 Apr 2015 19:13:28 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72A811B2C7D for ; Mon, 13 Apr 2015 19:13:28 -0700 (PDT) Received: by iget9 with SMTP id t9so67216788ige.1 for ; Mon, 13 Apr 2015 19:13:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=6NXp6hPcinjjBzJmLXGRsDU/AfZM/aYaJ2CItIX8+jM=; b=seig9mP6cmd1e30oWgubq1y4RYsqRmik39VpCaungOZOlGH2l7aCLnh2Qx5CNnxXyI UBN3mf6PfXHEfOuJGnyP59U2zBCFRUqV/xGGOoZET1zfW97WZT2OEcW8jsmXNBoJTh5M sTKzcyJ9v5V0HHI8Bd6S/c7sGW7e4BOqZS+mF7ZfgR3NmlvvWu27cNbd038GP6fqSLet Y116CVNatF6MDu0lnIr8Bgk5Cb76oFseliC5jNy/IkFKBgOfLvfcB4RFgv165+qPBJNO LLrt0ADzAO4ty0kpEnf43r2OP9twcuIQxM3uM0yolX69taHuYXnnGuJBPtnH6Ov/+Dwe vR5g== MIME-Version: 1.0 X-Received: by 10.42.23.17 with SMTP id q17mr22718865icb.4.1428977607989; Mon, 13 Apr 2015 19:13:27 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.7.130 with HTTP; Mon, 13 Apr 2015 19:13:27 -0700 (PDT) Date: Mon, 13 Apr 2015 22:13:27 -0400 X-Google-Sender-Auth: 5sJoh0jCDcqYlb3EUQVFgtsM15s Message-ID: From: Barry Leiba To: Peter Saint-Andre , Alexey Melnikov Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: precis@ietf.org Subject: [precis] AD review of draft-ietf-precis-saslprepbis X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 02:13:30 -0000 As with the other document, the items marked "DISCUSS" below are things I think we need to resolve before I request last call. It'd be nice to sort out the others before then too, but I won't hold things up for them. -------- DISCUSS -- Section 2 -- Many important terms used in this document are defined in [I-D.ietf-precis-framework], [RFC5890], [RFC6365], and [Unicode]. I think this makes 5890 and 6365 normative references (you already have this one in the queue). -- Section 3.5 -- This says that identifiers can look like "Firstname Middlename Lastname", "because the PRECIS IdentifierClass allows any ASCII7 character, because spaces can be used to separate userpart instances". But when I look at the definition of IdentifierClass in precis-framework, my reading says that spaces are not valid in the IdentifierClass. And that's supported in example 8 in Table 2 (Section 3.6). Is my understanding of either Section 3.5 or the valid characters in IdentifierClass incorrect? -- Section 4.3 -- Example 16 in Table 4 seems wrong: non-ASCII spaces are allowed in FreeformClass, and enforcement rule 2 maps them all to ASCII space. It would seem that example 16 should be in Table 3, with a note something like "maps to (using ASCII space)". -------- COMMENT In the Abstract it's unfortunate that you mention 3454 without being able to say that it's been obsoleted by the precis framework doc. Because precis framework is a normative reference from here, maybe it's best to put in a placeholder for that, to be resolved at AUTH48. I'm also concerned that non-native readers might be uncertain that you're saying that SASLprep and Stringprep are "the previous approach" (rather than the "more sustainable approach"), and some re-wording could make that clearer. Maybe like this?: OLD This document describes methods for handling Unicode strings representing usernames and passwords. The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords than the previous approach, known as SASLprep (RFC 4013) and based on Stringprep (RFC 3454). This document obsoletes RFC 4013. NEW This document describes new methods for handling Unicode strings representing usernames and passwords. The previous approach was known as SASLprep (RFC 4013) and was based on Stringprep (RFC 3454). The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords. The precis framework, RFC XXXX, obsoletes RFC 3454, and this document obsoletes RFC 4013. END ...and then add an RFC Editor note to the beginning of the Introduction that asks them to replace "RFC XXXX" in the abstract with the RFC number of the precis framework document. I wouldn't normally say we need to repeat what precis framework already says, but you otherwise have a direct mention of Stringprep and its RFC number in the abstract, without any indication that it's now obsolete. In the Introduction (and elsewhere), httpauth-basicauth-update is in the RFC Editor queue and is only waiting on this document. httpauth-digest is also almost in the RFC Editor queue, and all these documents will be published together. Because of that, I don't think we should be citing RFC 2617 any more, and I think we should pull out that reference. -- Section 2 -- As used here, the term "password" is not literally limited to a word; i.e., a password could be a passphrase consisting of more than one word, perhaps separated by spaces or other such characters. What "such" characters? Maybe this works?: NEW As used here, the term "password" is not literally limited to a word. A password could be a passphrase consisting of more than one word, perhaps separated by spaces, punctuation, or other non-alphanumeric characters. END -- Section 3.4 -- In order to accomodate the widest range of username constructs in applications, this document defines two username profiles: UsernameCaseMapped and UsernameCasePreserved. It's a tiny point, and I'm OK if the WG doesn't want to do this, but I think it would be useful to add the following to this paragraph, to eliminate any question: NEW (append) These two profiles differ only in the Case Mapping Rule, and are otherwise identical. END -- Section 3.6 -- Nit: I believe that "eszett" (one "s") is the more customary spelling. -- Barry, Applications AD From nobody Tue Apr 14 02:46:43 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A177A1A6EF4 for ; Tue, 14 Apr 2015 02:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.898 X-Spam-Level: * X-Spam-Status: No, score=1.898 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_46=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThODjlXvNCKR for ; Tue, 14 Apr 2015 02:46:38 -0700 (PDT) Received: from mail.kmd.keio.ac.jp (mail.kmd.keio.ac.jp [IPv6:2001:200:167:2e90::164]) by ietfa.amsl.com (Postfix) with ESMTP id B2B221A6F32 for ; Tue, 14 Apr 2015 02:46:37 -0700 (PDT) Received: from [100.64.32.16] (unknown [133.2.56.33]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kmd.keio.ac.jp (Postfix) with ESMTPSA id 72D9E7FBD3; Tue, 14 Apr 2015 18:46:35 +0900 (JST) (envelope-from t.nemo10@kmd.keio.ac.jp) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Takahiro Nemoto In-Reply-To: Date: Tue, 14 Apr 2015 18:46:28 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <0E3747A2-81D7-4E60-835A-566CC8F6F060@kmd.keio.ac.jp> References: To: "Black, David" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "precis@ietf.org" Subject: Re: [precis] WGLC on draft-ietf-precis-mappings - David Black's comments X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 09:46:41 -0000 Hi David-san and Alexey-san Thank you very much for your review and your helpful suggestions. I=E2=80=99ll try to modify the mappings document accordingly and submit = it after WGLC. > 2015/04/11 6:26=E3=80=81Black, David = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=EF=BC=9A >=20 > The draft generally looks good - I have a few comments. >=20 > [1] (editorial) Clarifications to the discussion of string matching. >=20 > Section 1 >=20 > Further, the handling of mappings other > than case and width, such as delimiter, special, and local case, are > also important in order to increase the probability that strings > match as users expect. >=20 > "increase the probability that strings match" -> > "increase the probability that the resulting strings compare" >=20 > Section 2.3 >=20 > OLD > The purpose of local case mapping is to increase the probability of = a > matching result from the comparison between uppercase and lowercase > characters, targeting characters which mapping depends on locale or > locale and context. > NEW > The purpose of local case mapping is to increase the probability of > results that users expect when character case is changed (e.g., map > uppercase to lowercase) between input and use in a protocol. Local > case mapping selectively affects characters whose case mapping = depends > on locale or context. > END I=E2=80=99ll reflect these comments in the next version. However I=E2=80=99ll modify the last words from "locale or context=E2=80=9D= to "locale and/or context=E2=80=9D. >=20 > OLD > If an application > supports users' locale and/or context , local case mapping can > increase the probability of getting matching-results from the > comparison between strings. > NEW > When an application > supports users' locale and/or context, use of local case mapping can > increase the probability that string comparisons yield the results = that > users expect. > END I=E2=80=99ll reflect this comment. >=20 > [2] (technical) The use of mappings from SpecialCasing.txt is = selective, > based on locale and context. >=20 > Section 1 >=20 > OLD > whereas the "local case mapping" rule provides an alternative to the > case mapping rule specified in the PRECIS framework since it handles > some locale-dependent and context-dependent mappings. > NEW > whereas the "local case mapping" rule provides locale-dependent > and context-dependent alternative case mappings for specific target > characters. I=E2=80=99ll reflect this comment. >=20 > Section 2.3 >=20 > OLD > The target characters of local case > mapping are characters defined in the SpecialCasing.txt > [Specialcasing] file in section 3.13 of the Unicode Standard > [Unicode]. > NEW > The complete set of possible target characters for local case > mapping are the characters specified in the SpecialCasing.txt > [Specialcasing] file in section 3.13 of the Unicode Standard > [Unicode], but the specific set of target characters selected > for local case mapping depends on locale and/or context, as > further explained in the SpeicalCasing.txt file. I=E2=80=99ll reflect this comment. >=20 > OLD > The case folding method for a target character is to map into lower > case as defined in SpecialCasing.txt. > NEW > The case folding method for a selected target character is to map > into lower case as defined in SpecialCasing.txt. > END I=E2=80=99ll reflect this comment. >=20 > [3] (editorial) Incomplete explanation in Appendix B >=20 > Appendix B only states the result of Unicode default case folding of > U+00DF; it needs to also state the result of Special Casing case > folding. I=E2=80=99ll add a sentence to explain that U+00DF doesn=E2=80=99t = becomes a different codepoint by performing the case mapping in SpecialCasing.txt. >=20 > [4] (technical) Clarify Appendix C >=20 > OLD > As described in section Section 2.3, target characters of local case > mapping are characters defined in SpecialCasing.txt. The Unicode > Standard (at least, up to version 7.0.0) does not define mappings > between "GREEK SMALL LETTER SIGMA" (U+03C3) (hereinafter referred to > as "small sigma") and "GREEK SMALL LETTER FINAL SIGMA" (U+03C2) > (hereinafter referred to as "final sigma") depend on context. Thus, > final sigma is always mapped to small sigma by local case mapping. > (Cf. Followings are comments in SpecialCasing.txt.) > NEW > As described in Section 2.3, the possible target characters of local > case mapping are specified in SpecialCasing.txt. The Unicode = Standard > (at least, up to version 7.0.0) does not define any = context-dependent > mappings between "GREEK SMALL LETTER SIGMA" (U+03C3) (hereinafter = referred > to as "small sigma") and "GREEK SMALL LETTER FINAL SIGMA" (U+03C2) > (hereinafter referred to as "final sigma"). Thus, local case = mapping > is not applicable to small sigma or final sigma, so case mapping in=20= > the PRECIS framework always maps final sigma to small sigma, = independent > of context, as specified by Unicode Default Case Folding. > (Note: Following comments are from SpecialCasing.txt.) > END I=E2=80=99ll reflect this comment. Regards, Nemo >=20 > Thanks, > --David >=20 >> -----Original Message----- >> From: precis [mailto:precis-bounces@ietf.org] On Behalf Of Marc = Blanchet >> Sent: Wednesday, April 08, 2015 8:49 AM >> To: precis@ietf.org >> Subject: [precis] WGLC on draft-ietf-precis-mappings >>=20 >> Hello, >> this is a 2 weeks working group last call (WGLC) on = draft-ietf-precis- >> mappings, starting today and closing on april 22nd 23:59 UTC. Please = send your >> comments and support to the list. >>=20 >> Regards, Marc&Alexey >> _______________________________________________ >> precis mailing list >> precis@ietf.org >> https://www.ietf.org/mailman/listinfo/precis >=20 > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis From nobody Tue Apr 14 10:58:36 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF5991A1B65 for ; Tue, 14 Apr 2015 10:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRCsGfTPteMA for ; Tue, 14 Apr 2015 10:58:31 -0700 (PDT) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5D191A1B8B for ; Tue, 14 Apr 2015 10:58:25 -0700 (PDT) Received: by igbyr2 with SMTP id yr2so45576149igb.0 for ; Tue, 14 Apr 2015 10:58:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xp0GUiQ/TbZy1Tt2VHsbf7QVubddyIr6AK4MM+f/8Gc=; b=kD82v2g5UsdeCmcgrh73OY2OodlvMovU2t/WTQkkVFPZgy/2J+dHMGHxECyl+xR4La yeyb/kT7pwa4S8CINDd01rlQbqOVXIgar1qs2DEL1urY1LRcWlNn34EmN65Lnyu1yeYM 1lrdlsrnEEvISic4xE+cNi8A5EwnGIiK78V/RgDp14Oa4D3b+1qE57as2LWgqqqykCn8 UK8EndGieZzTMBYkXfzUVMUagwF4fIb0S8zD0uyrqaFN04JqeDYcl02O1u/D1bWwCtug 7aaFRse4iIvqrfujoNMN9DUJXSXtOa5qWML9tNaeedjwvefNwb26QdG5qzLeV8pDI+3S lrpA== X-Gm-Message-State: ALoCoQnoH87xn96pEke6w7s0x6bLIAfaGWk+GF8T9Fg2AB9lmG76psPDKroaDd2jQxhUE0blj4xg X-Received: by 10.107.37.132 with SMTP id l126mr30353880iol.42.1429034305231; Tue, 14 Apr 2015 10:58:25 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id i184sm857309ioi.19.2015.04.14.10.58.24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Apr 2015 10:58:24 -0700 (PDT) Message-ID: <552D553F.7070908@andyet.net> Date: Tue, 14 Apr 2015 11:58:23 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Barry Leiba , Alexey Melnikov References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: precis@ietf.org Subject: Re: [precis] AD review of draft-ietf-precis-saslprepbis X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 17:58:34 -0000 On 4/13/15 8:13 PM, Barry Leiba wrote: > As with the other document, the items marked "DISCUSS" below are > things I think we need to resolve before I request last call. It'd be > nice to sort out the others before then too, but I won't hold things > up for them. > > -------- > DISCUSS > > -- Section 2 -- > > Many important terms used in this document are defined in > [I-D.ietf-precis-framework], [RFC5890], [RFC6365], and [Unicode]. > > I think this makes 5890 and 6365 normative references (you already > have this one in the queue). Agreed. > -- Section 3.5 -- > This says that identifiers can look like "Firstname Middlename > Lastname", "because the PRECIS IdentifierClass allows any ASCII7 > character, because spaces can be used to separate userpart instances". > > But when I look at the definition of IdentifierClass in > precis-framework, my reading says that spaces are not valid in the > IdentifierClass. And that's supported in example 8 in Table 2 > (Section 3.6). Correct. U+0020 is not allowed in IdentifierClass, but you can create "foo bar" as an application-layer construct if both "foo" and "bar" are separate instances of the IdentifierClass (or a profile thereof). Such a construct is not a PRECIS profile because you treat each instance separately and then place a space between the two instances. > Is my understanding of either Section 3.5 or the valid characters in > IdentifierClass incorrect? Section 3.5 is, perhaps, not as clear as it could be. I suggest: OLD Both the UsernameCaseMapped and UsernameCasePreserved profiles allow an application protocol, implementation, or deployment to create application-layer constructs such as "user@domain" or "Firstname Middlename Lastname". One example of the former is the Network Access Identifier specified in [I-D.ietf-radext-nai]. (Such constructs are possible because the PRECIS IdentifierClass allows any ASCII7 character, because spaces can be used to separate userpart instances, and because domain names as specified in [RFC5890] and [RFC5892] are a subset of the PRECIS IdentifierClass.) NEW Both the UsernameCaseMapped and UsernameCasePreserved profiles enable an application protocol, implementation, or deployment to create application-layer constructs such as a space-separated set of names like "Firstname Middlename Lastname". Although such a construct is not a PRECIS profile (since U+0020 SPACE is not allowed in the IdentifierClass), it can be created at the application layer because U+0020 SPACE can be used as a separator between instances of the PRECIS IdentifierClass (or a profile thereof). > -- Section 4.3 -- > Example 16 in Table 4 seems wrong: non-ASCII spaces are allowed in > FreeformClass, and enforcement rule 2 maps them all to ASCII space. > It would seem that example 16 should be in Table 3, with a note > something like "maps to (using ASCII space)". Good catch. Yes, that would be better. > -------- > COMMENT > > In the Abstract it's unfortunate that you mention 3454 without being > able to say that it's been obsoleted by the precis framework doc. > Because precis framework is a normative reference from here, maybe > it's best to put in a placeholder for that, to be resolved at AUTH48. > I'm also concerned that non-native readers might be uncertain that > you're saying that SASLprep and Stringprep are "the previous approach" > (rather than the "more sustainable approach"), and some re-wording > could make that clearer. Maybe like this?: > > OLD > This document describes methods for handling Unicode strings > representing usernames and passwords. The methods specified in this > document provide a more sustainable approach to the handling of > internationalized usernames and passwords than the previous approach, > known as SASLprep (RFC 4013) and based on Stringprep (RFC 3454). > This document obsoletes RFC 4013. > NEW > This document describes new methods for handling Unicode strings > representing usernames and passwords. The previous approach was > known as SASLprep (RFC 4013) and was based on Stringprep (RFC 3454). > The methods specified in this document provide a more sustainable > approach to the handling of internationalized usernames and > passwords. The precis framework, RFC XXXX, obsoletes RFC 3454, and > this document obsoletes RFC 4013. > END +1. Nit: I'd change "new" to "updated" because eventually this document won't be so new anymore. :-) > ...and then add an RFC Editor note to the beginning of the > Introduction that asks them to replace "RFC XXXX" in the abstract with > the RFC number of the precis framework document. > > I wouldn't normally say we need to repeat what precis framework > already says, but you otherwise have a direct mention of Stringprep > and its RFC number in the abstract, without any indication that it's > now obsolete. Yep, that's all good. > In the Introduction (and elsewhere), httpauth-basicauth-update is in > the RFC Editor queue and is only waiting on this document. > httpauth-digest is also almost in the RFC Editor queue, and all these > documents will be published together. Because of that, I don't think > we should be citing RFC 2617 any more, and I think we should pull out > that reference. +1 > -- Section 2 -- > > As used here, the term "password" is not literally limited to a word; > i.e., a password could be a passphrase consisting of more than one > word, perhaps separated by spaces or other such characters. > > What "such" characters? Maybe this works?: > > NEW > As used here, the term "password" is not literally limited to a word. > A password could be a passphrase consisting of more than one word, > perhaps separated by spaces, punctuation, or other non-alphanumeric > characters. > END Works for me. > -- Section 3.4 -- > > In order to accomodate the widest range of username constructs in > applications, this document defines two username profiles: > UsernameCaseMapped and UsernameCasePreserved. > > It's a tiny point, and I'm OK if the WG doesn't want to do this, but I > think it would be useful to add the following to this paragraph, to > eliminate any question: > > NEW (append) > These two profiles differ only in the Case Mapping Rule, and are > otherwise identical. > END That seems good to me. > -- Section 3.6 -- > Nit: I believe that "eszett" (one "s") is the more customary spelling. Right you are! Thanks for the thorough review. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Tue Apr 14 11:09:54 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD271A700A; Tue, 14 Apr 2015 11:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arJJFKwHZtlv; Tue, 14 Apr 2015 11:09:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C30B1A6EED; Tue, 14 Apr 2015 11:09:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150414180940.32028.48227.idtracker@ietfa.amsl.com> Date: Tue, 14 Apr 2015 11:09:40 -0700 Archived-At: Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-saslprepbis-15.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 18:09:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Preparation and Comparison of Internationalized Strings Working Group of the IETF. Title : Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords Authors : Peter Saint-Andre Alexey Melnikov Filename : draft-ietf-precis-saslprepbis-15.txt Pages : 23 Date : 2015-04-14 Abstract: This document describes updated methods for handling Unicode strings representing usernames and passwords. The previous approach was known as SASLprep (RFC 4013) and was based on Stringprep (RFC 3454). The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords. The PRECIS framework, RFC YYYY, obsoletes RFC 3454, and this document obsoletes RFC 4013. [[ NOTE TO RFC EDITOR: please replace "YYYY" in the previous paragraph with the RFC number assigned to draft-ietf-precis- framework. ]] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-saslprepbis-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 14 11:09:55 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0271A6EF0; Tue, 14 Apr 2015 11:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giG-a3tmJpO8; Tue, 14 Apr 2015 11:09:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AD06C1A6F7A; Tue, 14 Apr 2015 11:09:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150414180940.32028.56154.idtracker@ietfa.amsl.com> Date: Tue, 14 Apr 2015 11:09:40 -0700 Archived-At: Subject: [precis] New Version Notification - draft-ietf-precis-saslprepbis-15.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 18:09:53 -0000 A new version (-15) has been submitted for draft-ietf-precis-saslprepbis: http://www.ietf.org/internet-drafts/draft-ietf-precis-saslprepbis-15.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-saslprepbis-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Tue Apr 14 11:43:50 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B621AC3E3 for ; Tue, 14 Apr 2015 11:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Po_guZzdfEU7 for ; Tue, 14 Apr 2015 11:43:47 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EED821AC3F1 for ; Tue, 14 Apr 2015 11:43:46 -0700 (PDT) Received: by igbpi8 with SMTP id pi8so52680993igb.0 for ; Tue, 14 Apr 2015 11:43:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=MTrIN0NwSP50t1JSlGRdwL2QMxOPVBpbdFML0P4rbdw=; b=lrEgzxRCT3uIoTBxPn3Wn82wN3vAzdUxF/fLQEYar1S63dDX+KhIQ4mgPFfxrvvcgF 4t8YlSLwOng4vzCB/uB21twFVQjhh6vKW2SUxBoGSRE/tY9WdxQiw5RkT3ZsOhHPTRE2 x6XKeLPWY4dngberW9vZaFwz7wS1pZcSMLuqabANT5Nu2FBLVP+9C7kGLPdqYp/GFThF kXa5TcQZU7C+htLil2U+5vWRvwdaZbpJq//Cu6M8dNdJKrQkFrVGpnId5dSCGmyQlDqb rq2GMa+AUs4LXXYEJR5eaSN/V1bK6FEbjtqPfVTxwFIvaPigvp/451+//H9dlENgL5O0 /PWQ== MIME-Version: 1.0 X-Received: by 10.50.8.6 with SMTP id n6mr26173509iga.12.1429037026441; Tue, 14 Apr 2015 11:43:46 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.7.130 with HTTP; Tue, 14 Apr 2015 11:43:46 -0700 (PDT) In-Reply-To: <552D553F.7070908@andyet.net> References: <552D553F.7070908@andyet.net> Date: Tue, 14 Apr 2015 14:43:46 -0400 X-Google-Sender-Auth: wZyDWAqC_pD9W5xPJcC9pcYVANw Message-ID: From: Barry Leiba To: "Peter Saint-Andre - &yet" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: precis@ietf.org Subject: Re: [precis] AD review of draft-ietf-precis-saslprepbis X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 18:43:48 -0000 Another set of perfect responses, and I see the revised I-D. Off to request last call now. Barry From nobody Tue Apr 14 12:00:44 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8F31ACEBA; Tue, 14 Apr 2015 12:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbTQNsDdOFte; Tue, 14 Apr 2015 12:00:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED70A1ACDC4; Tue, 14 Apr 2015 11:59:58 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150414185958.28998.26232.idtracker@ietfa.amsl.com> Date: Tue, 14 Apr 2015 11:59:58 -0700 Archived-At: Cc: precis@ietf.org Subject: [precis] Last Call: (Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords) to Proposed Standard X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 19:00:37 -0000 The IESG has received a request from the Preparation and Comparison of Internationalized Strings WG (precis) to consider the following document: - 'Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-04-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes updated methods for handling Unicode strings representing usernames and passwords. The previous approach was known as SASLprep (RFC 4013) and was based on Stringprep (RFC 3454). The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords. The PRECIS framework, RFC YYYY, obsoletes RFC 3454, and this document obsoletes RFC 4013. [[ NOTE TO RFC EDITOR: please replace "YYYY" in the previous paragraph with the RFC number assigned to draft-ietf-precis- framework. ]] The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Apr 21 13:21:20 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 692C81A876C; Tue, 21 Apr 2015 13:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRbvl4lZfcie; Tue, 21 Apr 2015 13:21:14 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D21E1A8758; Tue, 21 Apr 2015 13:21:11 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t3LKL9J1078824 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Apr 2015 15:21:09 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local Message-ID: <5536B130.7000707@nostrum.com> Date: Tue, 21 Apr 2015 15:21:04 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: General Area Review Team , "ietf@ietf.org" , draft-ietf-precis-saslprepbis@ietf.org, precis@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [precis] Gen-art LC review: draft-ietf-precis-saslprepbis-15 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 20:21:15 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-precis-saslprepbis-15 Reviewer: Robert Sparks Review Date: 21Apr2015 IETF LC End Date: 28Apr2015 IESG Telechat date: Not scheduled Summary: Ready for publication as Proposed Standard with one minor nit This is a very easy to read document for such a detail-rich protocol. Nit: The introduction calls out email addresses as an example of the kinds of strings these methods are not intended for use in preparing (along with LDAP distinguished names). But in the body of the document, email addresses (or strings that look just like them) are discussed as valid examples of usernames. From nobody Tue Apr 21 16:44:19 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C231B2EBF for ; Tue, 21 Apr 2015 16:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLi4gtbzHui2 for ; Tue, 21 Apr 2015 16:44:17 -0700 (PDT) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B13061B2EC5 for ; Tue, 21 Apr 2015 16:44:16 -0700 (PDT) Received: by iedfl3 with SMTP id fl3so29084776ied.1 for ; Tue, 21 Apr 2015 16:44:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=A9Ew3r9abS3MaUILCWhgg6tjE3l1fl+MACrn84BpI6g=; b=fst5aeFSTUmbbH4Ja4YXr1xXkAYg2njv0/9Qb7Xi7x8O+Ff32bab2D/I4DOjiYM173 iis8xMgY+yf3JjfmyMD+Z8jpQocQ5CQswVhxm2QVORxpPfOoK69xHBlTaBipxH4asN/x byoEqWn3iTZ/shsc2CIEF+n8tLRAihboBVT0LJ5ciC53RbK3t71zqtCG+7HVXxEEVHa+ 5NANcTWOERzeGcido/jF+YH/LFkzbOx3Qrk8RF9UMV2HC6wbUPEh/kmfVhsFRdEI15k0 lrDYFS5lq8yxGF8VT/EaPFi2RPoHgq8Lw47QUK8tt6gP8H5epXZKwOwikPBpgrEo+LNM LUuQ== X-Gm-Message-State: ALoCoQnYMzN18y/rOOIjCYaleD/zGUQGqgqv52bNgIXo5clxNp4Bdi9+acmE+VhN7W1gzm5T94TY X-Received: by 10.107.46.39 with SMTP id i39mr24673917ioo.8.1429659855158; Tue, 21 Apr 2015 16:44:15 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id q11sm2234873igr.3.2015.04.21.16.44.13 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Apr 2015 16:44:14 -0700 (PDT) Message-ID: <5536E0CD.7010005@andyet.net> Date: Tue, 21 Apr 2015 17:44:13 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Robert Sparks , General Area Review Team , "ietf@ietf.org" , draft-ietf-precis-saslprepbis@ietf.org, precis@ietf.org References: <5536B130.7000707@nostrum.com> In-Reply-To: <5536B130.7000707@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [precis] Gen-art LC review: draft-ietf-precis-saslprepbis-15 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 23:44:18 -0000 On 4/21/15 2:21 PM, Robert Sparks wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > . > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-precis-saslprepbis-15 > Reviewer: Robert Sparks > Review Date: 21Apr2015 > IETF LC End Date: 28Apr2015 > IESG Telechat date: Not scheduled > > Summary: Ready for publication as Proposed Standard with one minor nit > > This is a very easy to read document for such a detail-rich protocol. Thanks. > Nit: > > The introduction calls out email addresses as an example of the kinds of > strings these methods are not intended for use in preparing (along with > LDAP distinguished names). But in the body of the document, email > addresses (or strings that look just like them) are discussed as valid > examples of usernames. Long answer: At some point, we modified the definition of the UsernameCaseMapped and UsernameCasePreserved profiles so that they could be used directly in HTTP authentication (see Section 2.1 of draft-ietf-httpauth-basicauth-update) and thus so that we could avoid having multiple profiles for username-like identifiers. That necessitated adding the '@' character to the username profiles, but we never updated the text in the introduction to reflect that fact. Short answer: s/email addresses// Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed Apr 22 03:51:45 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB3E1A9126; Wed, 22 Apr 2015 03:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiBka3hmuX9m; Wed, 22 Apr 2015 03:51:38 -0700 (PDT) Received: from statler.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCC41B3407; Wed, 22 Apr 2015 03:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1429699892; d=isode.com; s=selector; i=@isode.com; bh=/cLZ3LjLEjlqzmOYyzFmBArXXOOxAt9hgoWFdLKykZY=; 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=ZtkLOKGAk7TFIsg4oEgMJ+i4ZXQKpz7YfnURWvWfG8TynLe0PL+ExOUqjzzM8jmvvw/RUm 2X5unjOQKUx9eY3GcOn866Sk6pBCK9xiweozzicdu6cN2+MjWx60nqjIrFsh/5GFhABXfh FdVGuPaX1YTt23A2+SZS5vlBOKeoHSE=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 22 Apr 2015 11:51:31 +0100 Message-ID: <55377D03.4040904@isode.com> Date: Wed, 22 Apr 2015 11:50:43 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 To: Robert Sparks , General Area Review Team , "ietf@ietf.org" , draft-ietf-precis-saslprepbis@ietf.org, precis@ietf.org References: <5536B130.7000707@nostrum.com> In-Reply-To: <5536B130.7000707@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [precis] [Gen-art] Gen-art LC review: draft-ietf-precis-saslprepbis-15 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 10:51:39 -0000 Hi Robert, On 21/04/2015 21:21, Robert Sparks wrote: > Nit: > > The introduction calls out email addresses as an example of the kinds > of strings these methods are not intended for use in preparing (along > with LDAP distinguished names). But in the body of the document, email > addresses (or strings that look just like them) are discussed as valid > examples of usernames. Email address like things are commonly used as usernames, but strictly speaking they are 2 different types of objects. How do you think we can make this clearer? From nobody Wed Apr 22 06:03:40 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA1A1B3652; Wed, 22 Apr 2015 06:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DW1DTbacadDA; Wed, 22 Apr 2015 06:03:36 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A2A91B3651; Wed, 22 Apr 2015 06:03:36 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t3MD3Zg7081084 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 22 Apr 2015 08:03:35 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local Message-ID: <55379C22.2030708@nostrum.com> Date: Wed, 22 Apr 2015 08:03:30 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Alexey Melnikov , General Area Review Team , "ietf@ietf.org" , draft-ietf-precis-saslprepbis@ietf.org, precis@ietf.org References: <5536B130.7000707@nostrum.com> <55377D03.4040904@isode.com> In-Reply-To: <55377D03.4040904@isode.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [precis] [Gen-art] Gen-art LC review: draft-ietf-precis-saslprepbis-15 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 13:03:38 -0000 On 4/22/15 5:50 AM, Alexey Melnikov wrote: > Hi Robert, > > On 21/04/2015 21:21, Robert Sparks wrote: >> Nit: >> >> The introduction calls out email addresses as an example of the kinds >> of strings these methods are not intended for use in preparing (along >> with LDAP distinguished names). But in the body of the document, >> email addresses (or strings that look just like them) are discussed >> as valid examples of usernames. > Email address like things are commonly used as usernames, but strictly > speaking they are 2 different types of objects. How do you think we > can make this clearer? I don't think drawing the distinction helps the document. Peter's suggestion wfm. From nobody Fri Apr 24 04:41:50 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD6C1A8BB0; Fri, 24 Apr 2015 04:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7KP_B9PSVst; Fri, 24 Apr 2015 04:41:45 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 203341A8BAF; Fri, 24 Apr 2015 04:41:44 -0700 (PDT) Received: from latte.josefsson.org ([IPv6:2001:16d8:cca1:0:e808:884f:5720:1224]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t3OBfe2P003477 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 24 Apr 2015 13:41:42 +0200 From: Simon Josefsson To: ietf@ietf.org, precis@ietf.org References: <20150414185958.28998.26232.idtracker@ietfa.amsl.com> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150424:precis@ietf.org::HAUZQz8SBF3Tyj72:7yYR X-Hashcash: 1:22:150424:ietf@ietf.org::z/WspwsX/Vj4TG6L:ClvN X-Hashcash: 1:22:150424:ietf-announce@ietf.org::RT7zz3o1blUSQ45b:9CQk X-Hashcash: 1:22:150424:iesg-secretary@ietf.org::qQsACRjmZ8VqFzHz:Rc0s Date: Fri, 24 Apr 2015 13:41:39 +0200 In-Reply-To: <20150414185958.28998.26232.idtracker@ietfa.amsl.com> (The IESG's message of "Tue, 14 Apr 2015 11:59:58 -0700") Message-ID: <87oamdsqh8.fsf@latte.josefsson.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.6 at duva.sjd.se X-Virus-Status: Clean Archived-At: Subject: Re: [precis] Last Call: (Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords) to Proposed Standard X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 11:41:47 -0000 --=-=-= Content-Type: text/plain Hi. I would appreciate if this document contained a discussion of the implications for RFCs that currently normatively reference RFC 4013. This is warranted since the new document intends to obsolete RFC 4013. SASLprep and the several profiles defined by this document give different outputs for some inputs. This new protocol can also give different outputs depending on which Unicode version the implementation uses. Further, it is not clear how to map different uses of SASLprep into the different profiles described in this document. Combined, these aspects may lead to interoperability and security issues if migration is not coordinated among protocols and implementations. Essentially, what does it mean for this document to obsolete RFC 4013 for an implementation implements a protocol that normatively reference RFC 4013? When are implementations supposed to be updated to use this document? Now, or when the respective RFC is updated to point towards this new document? I have read section 6 on migration. It is helpful, but does not really address the question above. If my assumption that other RFCs needs to be updated before implementations should be updated, please consider clarifying this in the document by adding a paragraph like this to section 6. Feel free to reword or rewrite this as you want. While this section describes migration, this document does not have any direct implication for implementations that implement RFCs that uses SASLprep today. These RFCs will each need to be updated before implementation should migrate to using the techniques described in this document. Non-coordinated updates of protocol implementations can affect interoperability and security and is therefor discouraged. Thanks, /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVOiv0AAoJEIYLf7sy+BGdALEH+QFhxX1VGV0eDHSVQJOGE8/k Jto6EPMOOViYowdcSQObhGd3p/KKADxBmMA/YWfTxsKWS+dDMjlLCPj/BHcOK8NL Q6zIgIGC+J6o6FQDlEjEyFSNFNn6SXdKlIGpQQ80kkasy37V0UVUA6sgxhSrACFN U4Cs4Iq2m0Mkx4htyQ1JfRlPxupIPs8x9dBCmq4faElTG+bSmGMIPHjqOz30jGwD TujVeoepAQuJ4EywbrnN55GEUiSREHuQFmYE7BjDxEvPTYCBn83VV5pZylO4F71f 3RHOIJsQSVOM9gmIFhy4mIFC5R8SYzwsWYYswEoaSN90zk7mIlFf4IRxg40xUiU= =jeh2 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Apr 27 19:00:09 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696FD1ACE13 for ; Mon, 27 Apr 2015 19:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euFNdy15aSLM for ; Mon, 27 Apr 2015 19:00:05 -0700 (PDT) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF5101ACE20 for ; Mon, 27 Apr 2015 19:00:03 -0700 (PDT) Received: by iebrs15 with SMTP id rs15so8145421ieb.3 for ; Mon, 27 Apr 2015 19:00:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2hI+XfuutjsL35nSh43K56vk4GdSVKWddLhohNx56VE=; b=jR3G4j7D2WGOHizFTRoA9lvHDeaFmD7/oYQDflLChFKZPA2Qlr6s5LHXY1QbFFAxSa C0jVEFyX6kx1y72iL2aRjc6evAlOb8ApNCtYEF7P4B7jNVKXQdyrmYioKcxwofPE58LU yPs8yo4VFhDpzKztPmF9yz+VTwCxmhuO9C/ioQB3fZzyKY6ESa2IONQS0z/lO9Wu3Z3i Zn8pW3OGOQvGPeQMx/R6LvwJRx1lUOZkndJfLnTO0L7O03lEOcZ+vYeZ8+mzbI5s7p4V 74ZQmdSvfFzNRDCgOsxxTzcJ9xSIh5gLi7AvlabQKAXcB3cqVeLVSA1swthcfIgp1dKO IjHw== X-Gm-Message-State: ALoCoQkqrHPaRLraEqMnTIp3xmD1nR2ZSVjHO6jspXjpKgK9AdH7MlQNL01fdNGy/WYN82nk3pDB X-Received: by 10.50.29.40 with SMTP id g8mr2562125igh.41.1430186403236; Mon, 27 Apr 2015 19:00:03 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id lp7sm6341846igb.20.2015.04.27.19.00.01 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2015 19:00:02 -0700 (PDT) Message-ID: <553EE9A1.10406@andyet.net> Date: Mon, 27 Apr 2015 20:00:01 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Simon Josefsson , ietf@ietf.org, precis@ietf.org References: <20150414185958.28998.26232.idtracker@ietfa.amsl.com> <87oamdsqh8.fsf@latte.josefsson.org> In-Reply-To: <87oamdsqh8.fsf@latte.josefsson.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [precis] Last Call: (Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords) to Proposed Standard X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 02:00:07 -0000 On 4/24/15 5:41 AM, Simon Josefsson wrote: > Hi. I would appreciate if this document contained a discussion of the > implications for RFCs that currently normatively reference RFC 4013. > This is warranted since the new document intends to obsolete RFC 4013. Good point. > SASLprep and the several profiles defined by this document give > different outputs for some inputs. This new protocol can also give > different outputs depending on which Unicode version the implementation > uses. Do you think that more text is needed on those points? > Further, it is not clear how to map different uses of SASLprep > into the different profiles described in this document. As I see it, that "mapping" task is a job for those who update definitions for existing uses of SASLprep. See below. > Combined, these > aspects may lead to interoperability and security issues if migration is > not coordinated among protocols and implementations. I am not sure if migration needs to be coordinated across protocols (e.g., does XMPP need to be in sync with STUN?). I do think that some rough coordination across implementations of a given protocol is desirable, and those implementation communities would do well to pursue such coordination through the normal standards processes. See below. > Essentially, what does it mean for this document to obsolete RFC 4013 > for an implementation implements a protocol that normatively reference > RFC 4013? When are implementations supposed to be updated to use this > document? Now, or when the respective RFC is updated to point towards > this new document? The latter. I see this as similar to, say, RFC 6125 on server identity checking or draft-ietf-uta-tls-bcp on TLS usage. If an existing application protocol uses SASLprep as defined in RFC 4013, then that protocol can and should continue to use SASLprep until and unless the relevant RFC is updated or obsoleted. To choose an example at random, Dynamic Symmetric Key Provisioning Protocol (DSKPP) as defined in RFC 6063 uses SASLprep to normalize user input. Unless someone publishes 6063bis to obsolete that usage, DSKPP would continue to use SASLprep until the end of time. If the community of people who implement and deploy DSKPP care about these issues and experience the pain of being locked into Unicode 3.2 forever (etc.) through Stringprep, then they will take the initiative to update or obsolete RFC 6063. If they added that text about using SASLprep only to please some IESG member who mentioned internationalization, then the DSKPP community might never modernize their specifications. But this is not significantly different from things like server identity checking or applying TLS best practices. > I have read section 6 on migration. It is helpful, but does not really > address the question above. > > If my assumption that other RFCs needs to be updated before > implementations should be updated, please consider clarifying this in > the document by adding a paragraph like this to section 6. Feel free to > reword or rewrite this as you want. > > While this section describes migration, this document does not have > any direct implication for implementations that implement RFCs that > uses SASLprep today. These RFCs will each need to be updated before > implementation should migrate to using the techniques described in > this document. Non-coordinated updates of protocol implementations > can affect interoperability and security and is therefor discouraged. Yes, something like that would be very helpful; thanks for the proposed text. We might also borrow some text or concepts from existing documents, such as Section 1.4 of RFC 6125, Section 1 of RFC 6648, and Section 5 of draft-ietf-uta-tls-bcp. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Mon Apr 27 19:19:22 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9C51ACE1F for ; Mon, 27 Apr 2015 19:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hq9unx6uF1Q for ; Mon, 27 Apr 2015 19:19:18 -0700 (PDT) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C25FA1ACDF8 for ; Mon, 27 Apr 2015 19:19:18 -0700 (PDT) Received: by igbhj9 with SMTP id hj9so9772508igb.1 for ; Mon, 27 Apr 2015 19:19:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=sXpNmMbutVLfcOdUE7mNlrXpTnTE58AJ7cTf43qBsvw=; b=TZ+ocLuSqKJmQWhmGNaDU9UCA18EyyrA7HWbVq/4JPIWv6Yww+EDqARZdScEeLkOIw lRL3hzgAyxXGUG9ORpm5qL/QrWR6S+eAbBYt2cQrQvFCrWXsKWJw47M+VzJTVSnZFWMR Q3ZfIzfC+Jax/EmeHbIQKYgV1prgLdGrrcjZ1nAWwP1leixRaBTMehNKEZdpPIxAHpXy zlLSu7k0Tvjleoy6kMyNJVhn9htf000J/eMrZ8gdLtd3kzQu0GA2Peyvqhf4bJuIcE8E bvSqvt+wC/YQelZxa2RstrTZKklkUhjo1ureuQUctY4QYfXZbsWUIxzg3+fmfrNJ7gng 69CA== X-Gm-Message-State: ALoCoQlhbdd87Sb0hi7wiPXwvtq6WwvjRoKrPkibZkoMwqA7JzeTp+ymAd67aecnqj3XbW454DF3 X-Received: by 10.50.43.136 with SMTP id w8mr17195496igl.26.1430187558208; Mon, 27 Apr 2015 19:19:18 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id q29sm13923993ioi.9.2015.04.27.19.19.17 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2015 19:19:17 -0700 (PDT) Message-ID: <553EEE24.6000905@andyet.net> Date: Mon, 27 Apr 2015 20:19:16 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Simon Josefsson , ietf@ietf.org, precis@ietf.org References: <20150414185958.28998.26232.idtracker@ietfa.amsl.com> <87oamdsqh8.fsf@latte.josefsson.org> <553EE9A1.10406@andyet.net> In-Reply-To: <553EE9A1.10406@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [precis] Last Call: (Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords) to Proposed Standard X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 02:19:20 -0000 On 4/27/15 8:00 PM, Peter Saint-Andre - &yet wrote: > On 4/24/15 5:41 AM, Simon Josefsson wrote: >> Hi. I would appreciate if this document contained a discussion of the >> implications for RFCs that currently normatively reference RFC 4013. >> This is warranted since the new document intends to obsolete RFC 4013. > > Good point. > >> SASLprep and the several profiles defined by this document give >> different outputs for some inputs. This new protocol can also give >> different outputs depending on which Unicode version the implementation >> uses. > > Do you think that more text is needed on those points? > >> Further, it is not clear how to map different uses of SASLprep >> into the different profiles described in this document. > > As I see it, that "mapping" task is a job for those who update > definitions for existing uses of SASLprep. See below. > >> Combined, these >> aspects may lead to interoperability and security issues if migration is >> not coordinated among protocols and implementations. > > I am not sure if migration needs to be coordinated across protocols > (e.g., does XMPP need to be in sync with STUN?). > > I do think that some rough coordination across implementations of a > given protocol is desirable, and those implementation communities would > do well to pursue such coordination through the normal standards > processes. See below. > >> Essentially, what does it mean for this document to obsolete RFC 4013 >> for an implementation implements a protocol that normatively reference >> RFC 4013? When are implementations supposed to be updated to use this >> document? Now, or when the respective RFC is updated to point towards >> this new document? > > The latter. > > I see this as similar to, say, RFC 6125 on server identity checking or > draft-ietf-uta-tls-bcp on TLS usage. If an existing application protocol > uses SASLprep as defined in RFC 4013, then that protocol can and should > continue to use SASLprep until and unless the relevant RFC is updated or > obsoleted. To choose an example at random, Dynamic Symmetric Key > Provisioning Protocol (DSKPP) as defined in RFC 6063 uses SASLprep to > normalize user input. Unless someone publishes 6063bis to obsolete that > usage, DSKPP would continue to use SASLprep until the end of time. If > the community of people who implement and deploy DSKPP care about these > issues and experience the pain of being locked into Unicode 3.2 forever > (etc.) through Stringprep, then they will take the initiative to update > or obsolete RFC 6063. If they added that text about using SASLprep only > to please some IESG member who mentioned internationalization, then the > DSKPP community might never modernize their specifications. But this is > not significantly different from things like server identity checking or > applying TLS best practices. > >> I have read section 6 on migration. It is helpful, but does not really >> address the question above. >> >> If my assumption that other RFCs needs to be updated before >> implementations should be updated, please consider clarifying this in >> the document by adding a paragraph like this to section 6. Feel free to >> reword or rewrite this as you want. >> >> While this section describes migration, this document does not have >> any direct implication for implementations that implement RFCs that >> uses SASLprep today. These RFCs will each need to be updated before >> implementation should migrate to using the techniques described in >> this document. Non-coordinated updates of protocol implementations >> can affect interoperability and security and is therefor discouraged. > > Yes, something like that would be very helpful; thanks for the proposed > text. We might also borrow some text or concepts from existing > documents, such as Section 1.4 of RFC 6125, Section 1 of RFC 6648, and > Section 5 of draft-ietf-uta-tls-bcp. Here is further proposed text: This document does not modify the handling of internationalized strings in usernames and passwords as prescribed by existing application protocols that use SASLprep. If the community that uses such an application protocol wishes to modernize its handling of internationalized strings to use PRECIS instead of stringprep, it needs to explicitly update the existing application protocol definition (one example is [I-D.ietf-xmpp-6122bis], which obsoletes [RFC6122]). Non-coordinated updates to protocol implementations are discouraged because they can have a negative impact on interoperability and security. Does that address your concern? Peter -- Peter Saint-Andre https://andyet.com/ From nobody Tue Apr 28 03:43:08 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E5D1A874A; Tue, 28 Apr 2015 03:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdTcooh7OXOi; Tue, 28 Apr 2015 03:43:02 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 473C31A8734; Tue, 28 Apr 2015 03:43:02 -0700 (PDT) Received: from latte.josefsson.org (c-def5e555.014-1001-73746f1.cust.bredbandsbolaget.se [85.229.245.222]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t3SAguJ4028185 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 28 Apr 2015 12:42:58 +0200 From: Simon Josefsson To: Peter Saint-Andre - &yet References: <20150414185958.28998.26232.idtracker@ietfa.amsl.com> <87oamdsqh8.fsf@latte.josefsson.org> <553EE9A1.10406@andyet.net> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150428:precis@ietf.org::aAaXEsCRmL0pZEEY:QJo X-Hashcash: 1:22:150428:ietf@ietf.org::03PA/XsoDrxncYFT:3pdn X-Hashcash: 1:22:150428:peter@andyet.net::+c/HKktxJ/phMq7u:Pm8Y Date: Tue, 28 Apr 2015 12:42:55 +0200 In-Reply-To: <553EE9A1.10406@andyet.net> (Peter Saint-Andre's message of "Mon, 27 Apr 2015 20:00:01 -0600") Message-ID: <87tww0ttxs.fsf@latte.josefsson.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.6 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: ietf@ietf.org, precis@ietf.org Subject: Re: [precis] Last Call: (Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords) to Proposed Standard X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 10:43:07 -0000 --=-=-= Content-Type: text/plain Peter Saint-Andre - &yet writes: >> SASLprep and the several profiles defined by this document give >> different outputs for some inputs. This new protocol can also give >> different outputs depending on which Unicode version the implementation >> uses. > > Do you think that more text is needed on those points? I don't think text will help. I believe this design property will lead to slow migration and frustration from implementers. Compare the state of IDNA2008. So, I don't see how more text would make a difference. >> Combined, these >> aspects may lead to interoperability and security issues if migration is >> not coordinated among protocols and implementations. > > I am not sure if migration needs to be coordinated across protocols > (e.g., does XMPP need to be in sync with STUN?). Agreed. I didn't intend that and agree my wording could be interpreted the wrong way. I meant coordination among implementation of a particular protocol. It would be bad if, for two implementations of one protocol, for one of the implementations to migrate from SASLprep to SASLprepbis on its own. > I do think that some rough coordination across implementations of a > given protocol is desirable, and those implementation communities > would do well to pursue such coordination through the normal standards > processes. See below. Agreed. >> Essentially, what does it mean for this document to obsolete RFC 4013 >> for an implementation implements a protocol that normatively reference >> RFC 4013? When are implementations supposed to be updated to use this >> document? Now, or when the respective RFC is updated to point towards >> this new document? > > The latter. Good! I wasn't confident in this interpretation. > Here is further proposed text: > > This document does not modify the handling of internationalized > strings in usernames and passwords as prescribed by existing > application protocols that use SASLprep. If the community that uses > such an application protocol wishes to modernize its handling of > internationalized strings to use PRECIS instead of stringprep, it > needs to explicitly update the existing application protocol > definition (one example is [I-D.ietf-xmpp-6122bis], which obsoletes > [RFC6122]). Non-coordinated updates to protocol implementations are > discouraged because they can have a negative impact on > interoperability and security. > > Does that address your concern? Awesome, thank you! /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVP2QvAAoJEIYLf7sy+BGdwX0IALjIgPfhhHfHqeB4qZiEmq9q K95tFaSkOHKj/qPfP9l2q00SbIIsYEFXfk12GAsygFXgoNlvVkptubnSHComB/t7 WdneNfHpULaIEBvQ8S2y1GeSBIadChhoGI3yptmFj2YtkQXDDjjqVcnLUnv5F3NC bX6n1W5dpJJnDDdtib9Bs8bJ+NQjlb9enUU0lc8CDLIQwZN6FVBNGO51tN96ZyB0 fcI1MRu8H5PVmplXzlwNUKc4iyYG/SIoPJG0IFnPlYNNiE/VEJHOEioVnw+sNT22 DTnJRh4RxIk8RsfvAB5TuFVNPD7h0faoOk/TGfFmFGMk/7yL6/3gSnSqd8W1ews= =WHn3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Apr 28 06:15:51 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0941A9127; Tue, 28 Apr 2015 06:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qg2VSQTk-dwd; Tue, 28 Apr 2015 06:15:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B27331A912C; Tue, 28 Apr 2015 06:15:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150428131545.6559.26967.idtracker@ietfa.amsl.com> Date: Tue, 28 Apr 2015 06:15:45 -0700 Archived-At: Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-saslprepbis-16.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 13:15:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Preparation and Comparison of Internationalized Strings Working Group of the IETF. Title : Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords Authors : Peter Saint-Andre Alexey Melnikov Filename : draft-ietf-precis-saslprepbis-16.txt Pages : 23 Date : 2015-04-28 Abstract: This document describes updated methods for handling Unicode strings representing usernames and passwords. The previous approach was known as SASLprep (RFC 4013) and was based on Stringprep (RFC 3454). The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords. The PRECIS framework, RFC YYYY, obsoletes RFC 3454, and this document obsoletes RFC 4013. [[ NOTE TO RFC EDITOR: please replace "YYYY" in the previous paragraph with the RFC number assigned to draft-ietf-precis- framework. ]] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-precis-saslprepbis-16 A diff from the previous version is available at: https:https://www.ietf.org/rfcdiff?url2=draft-ietf-precis-saslprepbis-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 28 06:17:11 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6F91A9144 for ; Tue, 28 Apr 2015 06:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-MASlte4Kma for ; Tue, 28 Apr 2015 06:17:09 -0700 (PDT) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40E931A913A for ; Tue, 28 Apr 2015 06:17:03 -0700 (PDT) Received: by igbhj9 with SMTP id hj9so20228641igb.1 for ; Tue, 28 Apr 2015 06:17:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Z0wfCWSxBEnBd7vUOe+oKe1tk/+0569JupA82jWFwnk=; b=f2NJJYjovzBq7C2tC6bi1OZWzItoTubmj6Td+3dHiK4Niz7ft5IUK1tO0fcNJL69v5 vPFtyjE3btmcBivhpHqpEbXZHFECgW6xSXke8ETLghSDO66Dc0ypezFOK4BF26J6cGPG O/qe47/CT/FvKIIQ/DY/yYpK0HjJ7VIPpjyNsj325CV5OFiD89gNmZYKlf+OF7UMDYed GRBE5bGkphuVOFPlhFfF/iRAg5pQ2JwusPXfr8ib0Tgd1SWaNgASBDCHKqyL/bH3XdTk /GAnpIgOAHiqw1OIcPUn+rOzNjRt/oYFo13ufto06sMNkhiUxFHXJ2JupEmR2bTinoRt ydqg== X-Gm-Message-State: ALoCoQkvvmkZPTjKewnj09hJygwaAG88aLYsPgTdytpS6mObsfCJCIVCuu3KFTUfW7HKSSLJPfPI X-Received: by 10.43.173.70 with SMTP id ob6mr18204840icc.45.1430227022657; Tue, 28 Apr 2015 06:17:02 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id 69sm14740100ioz.10.2015.04.28.06.17.01 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Apr 2015 06:17:01 -0700 (PDT) Message-ID: <553F884C.2020504@andyet.net> Date: Tue, 28 Apr 2015 07:17:00 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: precis@ietf.org References: <20150428131545.6559.26967.idtracker@ietfa.amsl.com> In-Reply-To: <20150428131545.6559.26967.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [precis] I-D Action: draft-ietf-precis-saslprepbis-16.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 13:17:10 -0000 On 4/28/15 7:15 AM, internet-drafts@ietf.org wrote: > A diff from the previous version is available at: > https:https://www.ietf.org/rfcdiff?url2=draft-ietf-precis-saslprepbis-16 This version addresses IETF Last Call feedback. Peter -- Peter Saint-Andre https://andyet.com/