From nobody Tue Mar 4 06:24:58 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A181A0176 for ; Tue, 4 Mar 2014 06:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 1Sr3WpgNiTBM for ; Tue, 4 Mar 2014 06:24:56 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 26EB61A0128 for ; Tue, 4 Mar 2014 06:24:56 -0800 (PST) Received: from [IPv6:2620:0:230:2001::1001] (unknown [IPv6:2620:0:230:2001::1001]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5B4FE403DC for ; Tue, 4 Mar 2014 09:24:52 -0500 (EST) From: Marc Blanchet Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <189E55B1-7318-4FAD-B5D7-239332FB0259@viagenie.ca> Date: Tue, 4 Mar 2014 14:24:50 +0000 To: precis@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/precis/PjiaqJT2jilHYY28o7Mlmmdq_d4 Subject: [precis] ietf89 wg 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: Tue, 04 Mar 2014 14:24:58 -0000 Minutes of our meeting are posted at: = http://www.ietf.org/proceedings/89/minutes/minutes-89-precis. Thanks to Matt Miller for great scribing. Please send mods to precis-chairs@tools.ietf.org Regards, Marc&Yoshiro= From nobody Thu Mar 6 09:50:58 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5091A0040 for ; Thu, 6 Mar 2014 09:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, 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 dQzh73v6DiuZ for ; Thu, 6 Mar 2014 09:50:55 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0D51A00A6 for ; Thu, 6 Mar 2014 09:50:54 -0800 (PST) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s26HomjR008458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Mar 2014 12:50:49 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s26HomjR008458 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1394128249; bh=uQOm94c/iFpaIn+aSk6+ZMzhZSg=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=ciUC4XBPq/NCP7Oy2aUmGv0ZrGZlKaLIA7nI3J9u/xpsfd6kCXUKL7hmJR2c7jzNP 0uOIcLLy0fI4kOAYGjQF/46zFHe7yrGqxBE9/vlH/voW9k0xyUQxeOZiNB54l15Mex sYmW8utXHIPY3SsArZcCL31mAo63Owc7qm4yyjV0= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s26HomjR008458 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd06.lss.emc.com (RSA Interceptor); Thu, 6 Mar 2014 09:50:41 -0800 Received: from mxhub11.corp.emc.com (mxhub11.corp.emc.com [10.254.92.106]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s26HofMm023737 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Mar 2014 12:50:41 -0500 Received: from mx15a.corp.emc.com ([169.254.1.223]) by mxhub11.corp.emc.com ([10.254.92.106]) with mapi; Thu, 6 Mar 2014 12:50:41 -0500 From: "Black, David" To: Andrew Sullivan , "precis@ietf.org" Date: Thu, 6 Mar 2014 12:50:39 -0500 Thread-Topic: [precis] RFC 2277bis Thread-Index: Ac8zPCIqmwcNlvzkQxC/qxFxhuUeUwGKF3Dg Message-ID: <8D3D17ACE214DC429325B2B98F3AE71206CF4390CE@MX15A.corp.emc.com> References: <20140226214534.GC781@mx1.yitter.info> In-Reply-To: <20140226214534.GC781@mx1.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/precis/b15MG7z9TQF79buf1g9rq52if2g Subject: Re: [precis] RFC 2277bis 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, 06 Mar 2014 17:50:57 -0000 Andrew - could you summarize the changes from RFC 2777, preferably in a sec= tion in a -01 version of the draft? Thanks, --David > -----Original Message----- > From: precis [mailto:precis-bounces@ietf.org] On Behalf Of Andrew Sulliva= n > Sent: Wednesday, February 26, 2014 4:46 PM > To: precis@ietf.org > Subject: [precis] RFC 2277bis >=20 > Dear colleagues, >=20 > For some time the IAB's internationalization program has intended to > propose updates to RFC 2277. We have a first pass at that. It's at > http://tools.ietf.org/html/draft-sullivan-rfc2277-bis-00. I eagerly > solicit comments. As you can imagine since it's a -00, there are > plenty of rough patches. You can blame me for the rough bits and my > co-authors for the reasonable parts. >=20 > Best regards, >=20 > A >=20 > -- > Andrew Sullivan > ajs@anvilwalrusden.com >=20 > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis From nobody Sat Mar 8 06:49:33 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB7C1A0267 for ; Sat, 8 Mar 2014 06:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, J_CHICKENPOX_37=0.6, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-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 a1HqFeh4FvNA for ; Sat, 8 Mar 2014 06:49:31 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 557A81A01F6 for ; Sat, 8 Mar 2014 06:49:31 -0800 (PST) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C26EA4045D; Sat, 8 Mar 2014 07:49:25 -0700 (MST) Message-ID: <531A09C7.7070904@stpeter.im> Date: Fri, 07 Mar 2014 11:02:47 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "precis@ietf.org" Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/WInvV_aK0b2eG6sMGcNqMoZpBLo Subject: [precis] usernames in PRECIS and http-auth X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 14:49:32 -0000 As promised at IETF 89, I have compared the username definitions from draft-oiwa-precis-httpauthprep-00 and draft-ietf-precis-saslprepbis-06, with the purpose of perhaps harmonizing the two approaches so that we can avoid multiplying PRECIS profiles beyond necessity. (I am writing this email on the flight home, and I neglected to load up the meeting minutes before leaving, so I might not address all of the relevant points in this message.) First, let's look at the syntax definitions. draft-ietf-precis-saslprepbis-06 states that a username can (a) consist of one of more userparts, or (b) can be of the form userpart@domainpart. The ABNF definition is: username = userpart [1*(1*SP userpart)] / userpart ’@’ domainpart userpart = 1*(idpoint) domainpart = IP-literal / IPv4address / ifqdn ifqdn = 1*1023(domainpoint) Where: * an "idpoint" is a UTF-8 encoded Unicode code point that conforms to the PRECIS "IdentifierClass" * an "IPv4address" is as defined in RFC 3986 * an "IP-literal" is as defined in RFC 3986 * a "domainpoint" is a UTF-8 encoded Unicode code point that conforms to RFC 5890 By contrast, draft-oiwa-precis-httpauthprep states that a username consists of one or more UTF-8 encoded Unicode code points that conform to the PRECIS "IdentifierClass". The ABNF definition is: userpart = 1*(idpoint) We quickly see that an http-auth username is a legal PRECIS username, since 1*(idpoint) is simply a userpart as defined in draft-ietf-precis-saslprepbis-06, and a PRECIS username can consist of only one userpart. Therefore, in this respect, I think the httpauthprep text (whether it appears in a standalone document or elsewhere) can simply state that for purposes of HTTP authentication a username is a userpart as defined in draft-ietf-precis-saslprepbis. Second, let's look at the string preparation method. Here, too, draft-oiwa-precis-httpauthprep-00 is a subset of draft-ietf-precis-saslprepbis-06. The preparation method in draft-ietf-precis-saslprepbis-06 is: 1. The base string class is the "IdentifierClass" specified in [I-D.ietf-precis-framework]. 2. Fullwidth and halfwidth characters MUST be mapped to their decomposition equivalents. 3. So-called additional mappings MAY be applied, such as those defined in [I-D.ietf-precis-mappings]. 4. Uppercase and titlecase characters might be mapped to their lowercase equivalents (see Section 4.2.1 below). 5. Unicode Normalization Form C (NFC) MUST be applied to all characters. By contrast, the preparation method in draft-oiwa-precis-httpauthprep-00 is: 1. Fullwidth and halfwidth characters MUST be mapped to their decomposition equivalents. 2. Additional mappings SHOULD NOT be applied, such as those defined in [I-D.ietf-precis-mappings], unless there are implementation- dependent reasons to do so, or these are exceptionally required by specific authentication schemes. 3. Case mapping is not applied. 4. Unicode Normalization Form C (NFC) MUST be applied to all characters.o These two defnitions agree on the width mapping and normalization rules described in the PRECIS framework. They appear to differ slightly with regard to the additional mapping and case mapping rules. However, draft-oiwa-precis-httpauthprep-00 is merely a bit more restrictive with regard to matters that are purely optional according to draft-ietf-precis-saslprepbis-06. For example, the option of saying that "case mapping is not applied" is allowed by the text "uppercase and titlecase characters might be mapped to their lowercase equivalents". To make this clearer, I suggest that we modify the advice in draft-oiwa-precis-httpauthprep-00 so that it no longer defines its own PRECIS profile. Instead, I suggest that we phrase the httpauthprep text in terms of the username profile in draft-ietf-precis-saslprepbis-06. To my mind, something like this would work: ### For the purposes of HTTP authentication, a username conforms to the syntax definition and preparation methods specified in [I.D-draft-ietf-precis-saslprepbis], with the following limitations: * a username conforms to the "userpart" construction from [I-D.draft-ietf-precis-saslprepbis] * case mapping is not applied * delimiter mappings, special mappings, and other so-called additional mappings [I-D.draft-ietf-precis-mappings] are not applied ### As far as I can see, this simplifies the httpautheprep text quite a bit. (By the way, draft-oiwa-precis-httpauthprep-00 also seems to copy the password profile verbatim from draft-ietf-precis-saslprepbis. I think this text can be removed entirely, so that the httpauthprep text can simply reference draft-ietf-precis-saslprepbis.) Yutaka and Alexey (and others), let me know what you think about what I have written here. Thanks, Peter From nobody Sat Mar 8 10:34:23 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E031A02DD for ; Sat, 8 Mar 2014 10:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQx4HgBIRG_4 for ; Sat, 8 Mar 2014 10:34:19 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0066F1A024B for ; Sat, 8 Mar 2014 10:34:17 -0800 (PST) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C94CA404AF; Sat, 8 Mar 2014 11:34:11 -0700 (MST) Message-ID: <531B62A3.3030608@stpeter.im> Date: Sat, 08 Mar 2014 11:34:11 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Marc Blanchet , precis@ietf.org References: <189E55B1-7318-4FAD-B5D7-239332FB0259@viagenie.ca> In-Reply-To: <189E55B1-7318-4FAD-B5D7-239332FB0259@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/GL93F1DI8ZjoMRF95ofNfuTbnOg Subject: Re: [precis] ietf89 wg 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: Sat, 08 Mar 2014 18:34:21 -0000 On 3/4/14, 7:24 AM, Marc Blanchet wrote: > Minutes of our meeting are posted at: http://www.ietf.org/proceedings/89/minutes/minutes-89-precis. > Thanks to Matt Miller for great scribing. Indeed! > Please send mods to precis-chairs@tools.ietf.org Will do. Peter From nobody Sat Mar 8 10:46:43 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01B31A026F for ; Sat, 8 Mar 2014 10:46:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhE4HUD2LBpp for ; Sat, 8 Mar 2014 10:46:41 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 460EC1A0030 for ; Sat, 8 Mar 2014 10:46:41 -0800 (PST) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 93498404AF; Sat, 8 Mar 2014 11:46:36 -0700 (MST) Message-ID: <531B658C.4090801@stpeter.im> Date: Sat, 08 Mar 2014 11:46:36 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Marc Blanchet , precis@ietf.org References: <189E55B1-7318-4FAD-B5D7-239332FB0259@viagenie.ca> <531B62A3.3030608@stpeter.im> In-Reply-To: <531B62A3.3030608@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/vQ_xN4R0ssffZUY5eq3DnXuv0ZM Subject: Re: [precis] ietf89 wg 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: Sat, 08 Mar 2014 18:46:42 -0000 On 3/8/14, 11:34 AM, Peter Saint-Andre wrote: > On 3/4/14, 7:24 AM, Marc Blanchet wrote: >> Minutes of our meeting are posted at: >> http://www.ietf.org/proceedings/89/minutes/minutes-89-precis. >> Thanks to Matt Miller for great scribing. > > Indeed! > >> Please send mods to precis-chairs@tools.ietf.org > > Will do. Typo alert: "substative" => "substantive" This sentence is incomplete... "OY: I was wondering if we" John is quoted as saying "a number of Eastern European countries", although IIRC he said something like "a number of countries in the part of the world that used to be called Central Asia" Note that Yutaka Oiwa and I had a bit of a conversation about http-auth usernames in the chatroom: http://www.ietf.org/jabber/logs/precis/2014-03-04.txt Personally, I feel that I will need to listen to the recording in order to make sure that I understand everything that we discussed in the session. Peter From nobody Sat Mar 8 11:08:55 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA26F1A022C for ; Sat, 8 Mar 2014 11:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7_66D0wzu1cP for ; Sat, 8 Mar 2014 11:08:52 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7C08B1A0143 for ; Sat, 8 Mar 2014 11:08:52 -0800 (PST) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 40BBF404AF; Sat, 8 Mar 2014 12:08:46 -0700 (MST) Message-ID: <531B6ABE.70109@stpeter.im> Date: Sat, 08 Mar 2014 12:08:46 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "precis@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/HDPzvfsKtwUbLs9zUHHhm2OuZ6g Subject: [precis] generic username profile X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 19:08:54 -0000 During the session in London, David Black said something like this: DB: I care the most about iSCSI names, and I will pick something out of the framework and do something special. We do have a notion of a username, so if you came up with a profile for username we could probably use that. I did start working on draft-saintandre-username-interop last year, with the intent of defining a username profile that new protocols could use (basically it is a "safe subset" that avoids all ASCII-7 characters that happen to be used in email, SIP, XMPP, etc.). Feedback would be welcome: https://datatracker.ietf.org/doc/draft-saintandre-username-interop/ Peter From nobody Sat Mar 8 14:18:03 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C63C1A02DB for ; Sat, 8 Mar 2014 14:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] 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 kld7ztU1TtOi for ; Sat, 8 Mar 2014 14:17:58 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id DDFD11A02BE for ; Sat, 8 Mar 2014 14:17:57 -0800 (PST) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1WMPYz-000Ee7-PZ; Sat, 08 Mar 2014 17:17:50 -0500 Date: Sat, 08 Mar 2014 17:17:48 -0500 From: John C Klensin To: Peter Saint-Andre , precis@ietf.org Message-ID: <5335180FF472DFD6C0D0F6D7@JCK-EEE10> In-Reply-To: <531A09C7.7070904@stpeter.im> References: <531A09C7.7070904@stpeter.im> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Archived-At: http://mailarchive.ietf.org/arch/msg/precis/RYOVdTZXOq7owLIRjhjQMb9fBQE Subject: Re: [precis] usernames in PRECIS and http-auth X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 22:18:00 -0000 FWIW, this seems about right to me. john --On Friday, 07 March, 2014 11:02 -0700 Peter Saint-Andre wrote: > As promised at IETF 89, I have compared the username > definitions from draft-oiwa-precis-httpauthprep-00 and > draft-ietf-precis-saslprepbis-06, with the purpose of perhaps > harmonizing the two approaches so that we can avoid > multiplying PRECIS profiles beyond necessity. > > (I am writing this email on the flight home, and I neglected > to load up the meeting minutes before leaving, so I might not > address all of the relevant points in this message.) > > First, let's look at the syntax definitions. > > draft-ietf-precis-saslprepbis-06 states that a username can > (a) consist of one of more userparts, or (b) can be of the > form userpart@domainpart. The ABNF definition is: > > username = userpart [1*(1*SP userpart)] > / userpart '@' domainpart > > userpart = 1*(idpoint) > > domainpart = IP-literal / IPv4address / ifqdn > > ifqdn = 1*1023(domainpoint) > > Where: > > * an "idpoint" is a UTF-8 encoded Unicode code point that > conforms to the PRECIS "IdentifierClass" > * an "IPv4address" is as defined in RFC 3986 > * an "IP-literal" is as defined in RFC 3986 > * a "domainpoint" is a UTF-8 encoded Unicode code point that > conforms to RFC 5890 > > By contrast, draft-oiwa-precis-httpauthprep states that a > username consists of one or more UTF-8 encoded Unicode code > points that conform to the PRECIS "IdentifierClass". The ABNF > definition is: > > userpart = 1*(idpoint) > > We quickly see that an http-auth username is a legal PRECIS > username, since 1*(idpoint) is simply a userpart as defined in > draft-ietf-precis-saslprepbis-06, and a PRECIS username can > consist of only one userpart. Therefore, in this respect, I > think the httpauthprep text (whether it appears in a > standalone document or elsewhere) can simply state that for > purposes of HTTP authentication a username is a userpart as > defined in draft-ietf-precis-saslprepbis. > > Second, let's look at the string preparation method. > > Here, too, draft-oiwa-precis-httpauthprep-00 is a subset of > draft-ietf-precis-saslprepbis-06. The preparation method in > draft-ietf-precis-saslprepbis-06 is: > > 1. The base string class is the "IdentifierClass" > specified in > [I-D.ietf-precis-framework]. > 2. Fullwidth and halfwidth characters MUST be mapped to > their > decomposition equivalents. > 3. So-called additional mappings MAY be applied, such as > those > defined in [I-D.ietf-precis-mappings]. > 4. Uppercase and titlecase characters might be mapped to > their > lowercase equivalents (see Section 4.2.1 below). > 5. Unicode Normalization Form C (NFC) MUST be applied to > all > characters. > > By contrast, the preparation method in > draft-oiwa-precis-httpauthprep-00 is: > > 1. Fullwidth and halfwidth characters MUST be mapped to > their > decomposition equivalents. > 2. Additional mappings SHOULD NOT be applied, such as > those defined > in [I-D.ietf-precis-mappings], unless there are > implementation- > dependent reasons to do so, or these are exceptionally > required > by specific authentication schemes. > 3. Case mapping is not applied. > 4. Unicode Normalization Form C (NFC) MUST be applied to > all > characters.o > > These two defnitions agree on the width mapping and > normalization rules described in the PRECIS framework. They > appear to differ slightly with regard to the additional > mapping and case mapping rules. However, > draft-oiwa-precis-httpauthprep-00 is merely a bit more > restrictive with regard to matters that are purely optional > according to draft-ietf-precis-saslprepbis-06. For example, > the option of saying that "case mapping is not applied" is > allowed by the text "uppercase and titlecase characters might > be mapped to their lowercase equivalents". > > To make this clearer, I suggest that we modify the advice in > draft-oiwa-precis-httpauthprep-00 so that it no longer defines > its own PRECIS profile. Instead, I suggest that we phrase the > httpauthprep text in terms of the username profile in > draft-ietf-precis-saslprepbis-06. To my mind, something like > this would work: > >### > > For the purposes of HTTP authentication, a username conforms > to the syntax definition and preparation methods specified in > [I.D-draft-ietf-precis-saslprepbis], with the following > limitations: > > * a username conforms to the "userpart" construction from > [I-D.draft-ietf-precis-saslprepbis] > * case mapping is not applied > * delimiter mappings, special mappings, and other so-called > additional mappings [I-D.draft-ietf-precis-mappings] are not > applied > >### > > As far as I can see, this simplifies the httpautheprep text > quite a bit. > > (By the way, draft-oiwa-precis-httpauthprep-00 also seems to > copy the password profile verbatim from > draft-ietf-precis-saslprepbis. I think this text can be > removed entirely, so that the httpauthprep text can simply > reference draft-ietf-precis-saslprepbis.) > > Yutaka and Alexey (and others), let me know what you think > about what I have written here. > > Thanks, > > Peter > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis From nobody Sat Mar 8 14:27:44 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD16A1A0257 for ; Sat, 8 Mar 2014 14:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] 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 cKPaLFgCExQB for ; Sat, 8 Mar 2014 14:27:39 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 078881A01EE for ; Sat, 8 Mar 2014 14:27:39 -0800 (PST) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1WMPiP-000Eex-1X; Sat, 08 Mar 2014 17:27:33 -0500 Date: Sat, 08 Mar 2014 17:27:31 -0500 From: John C Klensin To: Peter Saint-Andre , Marc Blanchet , precis@ietf.org Message-ID: <95604C7233E5C9AB80CD4F10@JCK-EEE10> In-Reply-To: <531B658C.4090801@stpeter.im> References: <189E55B1-7318-4FAD-B5D7-239332FB0259@viagenie.ca> <531B62A3.3030608@stpeter.im> <531B658C.4090801@stpeter.im> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Archived-At: http://mailarchive.ietf.org/arch/msg/precis/PQd0R3LlBl-45jabNHhuNhGVAQs Subject: Re: [precis] ietf89 wg 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: Sat, 08 Mar 2014 22:27:41 -0000 --On Saturday, 08 March, 2014 11:46 -0700 Peter Saint-Andre wrote: >... > John is quoted as saying "a number of Eastern European > countries", although IIRC he said something like "a number of > countries in the part of the world that used to be called > Central Asia" The latter is correct. There are a few Eastern European countries (including, of course, part of Turkey) where Turkic languages are used, but the one I had in mind, and the ones where writing systems moved in the 20th century from those based on Arabic script, to Turkic-variation Latin script, to Cyrillic and that are now, in some areas, moving again to Latin script although sometimes not with the same conventions about that script used earlier. For those who are interested and/or care, it is apparently possible to find villages today in which any of the four scripts are in use on a per-village or even per-household basis. The context of all of this for those who were not in the meeting is that "we" have a tendency to dismiss the "dotless i" issue as being strictly connected to the Turkish language and/or a Turkish national locale, presumably making the issues simple of one only knows where that language is in use (e.g., configured into an operating system or locale information). That isn't true and, as the Internet expands to more areas, could turn out to be a very poor and highly discriminatory assumption. >... best, john From nobody Mon Mar 10 17:30:20 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 123931A064C for ; Mon, 10 Mar 2014 17:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dLIMgLkL8CY for ; Mon, 10 Mar 2014 17:30:17 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8FC1A050E for ; Mon, 10 Mar 2014 17:30:17 -0700 (PDT) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D4636404DF; Mon, 10 Mar 2014 18:30:11 -0600 (MDT) Message-ID: <531E5913.5020203@stpeter.im> Date: Mon, 10 Mar 2014 18:30:11 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "precis@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/x_2WYzsqChvHEr_MCzTORJlC6t8 Subject: [precis] case mapping text in framework 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, 11 Mar 2014 00:30:19 -0000 In London, we talked about clarifying the text about case mapping in the framework document. I propose the following modifications... Section 4.1.3 OLD Another option is to use the "local case mapping" method specified in [I-D.ietf-precis-mappings]. Note: because that method applies normal case mapping to Unicode characters that do not have special rules for locale-dependent or context-dependent mapping, if case mapping is desired then a profile needs to specify either the "local case mapping" method from [I-D.ietf-precis-mappings] or another method such as Unicode Default Case Folding. NEW Note: Unicode Default Case Folding does not take into account localization issues (such as "dotless i" in several Turkic languages). The PRECIS mappings document [I-D.ietf-precis-mappings] describes these issues in greater detail and defines a "local case mapping" method that handles some locale-dependent and context- dependent mappings. Section 5 OLD 3. Case mapping as described under Section 4.1.3 of this document (typically either the "local case mapping" method from [I-D.ietf-precis-mappings] or Unicode Default Case Folding) NEW 3. Case mapping as described under Section 4.1.3 of this document. Once we have made these changes, I think we can change the mappings document from a normative reference to an informative reference in the framework document. Peter From nobody Wed Mar 12 10:45:23 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC641A048A for ; Wed, 12 Mar 2014 10:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_37=0.6, RP_MATCHES_RCVD=-0.547, 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 4Jacq9qb-E01 for ; Wed, 12 Mar 2014 10:45:15 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3501A074E for ; Wed, 12 Mar 2014 10:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1394646276; d=isode.com; s=selector; i=@isode.com; bh=L2qApahyTlp/lsMb2cQ5wWhar5o+B7s8Jke46OOOZzU=; 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=n8QVju2kErroi07QYoYlKYYUJYhvVmz3ecUNBwSHhRfUC9UCj5zNjix+qoHFtNeM+YJ5Am EdK9O14lIg3XzO5Rf9NvbO15sjf8JCO2F99gBOzGkaWEdBsiN/KeMYQUMpSsaBtkmJte8B t1n4edSqmdHMQwRvAfn7xvJUhMO6hA8=; Received: from [172.17.128.46] (richard.isode.com [62.3.217.249]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 12 Mar 2014 17:44:35 +0000 Message-ID: <53209D30.4020107@isode.com> Date: Wed, 12 Mar 2014 17:45:20 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 To: Peter Saint-Andre , "precis@ietf.org" References: <531A09C7.7070904@stpeter.im> In-Reply-To: <531A09C7.7070904@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/precis/jeuHNFzJt-xmrw85s-XPQ2Un3o0 Subject: Re: [precis] usernames in PRECIS and http-auth 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, 12 Mar 2014 17:45:21 -0000 Hi Peter, On 07/03/2014 18:02, Peter Saint-Andre wrote: > As promised at IETF 89, I have compared the username definitions from=20 > draft-oiwa-precis-httpauthprep-00 and=20 > draft-ietf-precis-saslprepbis-06, with the purpose of perhaps=20 > harmonizing the two approaches so that we can avoid multiplying PRECIS=20 > profiles beyond necessity. > > (I am writing this email on the flight home, and I neglected to load=20 > up the meeting minutes before leaving, so I might not address all of=20 > the relevant points in this message.) > > First, let's look at the syntax definitions. > > draft-ietf-precis-saslprepbis-06 states that a username can (a)=20 > consist of one of more userparts, or (b) can be of the form=20 > userpart@domainpart. The ABNF definition is: > > username =3D userpart [1*(1*SP userpart)] > / userpart =92@=92 domainpart > > userpart =3D 1*(idpoint) > > domainpart =3D IP-literal / IPv4address / ifqdn > > ifqdn =3D 1*1023(domainpoint) > > Where: > > * an "idpoint" is a UTF-8 encoded Unicode code point that conforms to=20 > the PRECIS "IdentifierClass" > * an "IPv4address" is as defined in RFC 3986 > * an "IP-literal" is as defined in RFC 3986 > * a "domainpoint" is a UTF-8 encoded Unicode code point that conforms=20 > to RFC 5890 > > By contrast, draft-oiwa-precis-httpauthprep states that a username=20 > consists of one or more UTF-8 encoded Unicode code points that conform=20 > to the PRECIS "IdentifierClass". The ABNF definition is: > > userpart =3D 1*(idpoint) > > We quickly see that an http-auth username is a legal PRECIS username,=20 > since 1*(idpoint) is simply a userpart as defined in=20 > draft-ietf-precis-saslprepbis-06, and a PRECIS username can consist of=20 > only one userpart. Therefore, in this respect, I think the=20 > httpauthprep text (whether it appears in a standalone document or=20 > elsewhere) can simply state that for purposes of HTTP authentication a=20 > username is a userpart as defined in draft-ietf-precis-saslprepbis. Agreed. > Second, let's look at the string preparation method. > > Here, too, draft-oiwa-precis-httpauthprep-00 is a subset of=20 > draft-ietf-precis-saslprepbis-06. The preparation method in=20 > draft-ietf-precis-saslprepbis-06 is: > > 1. The base string class is the "IdentifierClass" specified in > [I-D.ietf-precis-framework]. > 2. Fullwidth and halfwidth characters MUST be mapped to their > decomposition equivalents. > 3. So-called additional mappings MAY be applied, such as those > defined in [I-D.ietf-precis-mappings]. > 4. Uppercase and titlecase characters might be mapped to their > lowercase equivalents (see Section 4.2.1 below). > 5. Unicode Normalization Form C (NFC) MUST be applied to all > characters. > > By contrast, the preparation method in=20 > draft-oiwa-precis-httpauthprep-00 is: > > 1. Fullwidth and halfwidth characters MUST be mapped to their > decomposition equivalents. > 2. Additional mappings SHOULD NOT be applied, such as those defined > in [I-D.ietf-precis-mappings], unless there are implementation- > dependent reasons to do so, or these are exceptionally required > by specific authentication schemes. > 3. Case mapping is not applied. > 4. Unicode Normalization Form C (NFC) MUST be applied to all > characters.o > > These two defnitions agree on the width mapping and normalization=20 > rules described in the PRECIS framework. They appear to differ=20 > slightly with regard to the additional mapping and case mapping rules.=20 > However, draft-oiwa-precis-httpauthprep-00 is merely a bit more=20 > restrictive with regard to matters that are purely optional according=20 > to draft-ietf-precis-saslprepbis-06. For example, the option of saying=20 > that "case mapping is not applied" is allowed by the text "uppercase=20 > and titlecase characters might be mapped to their lowercase equivalents". > > To make this clearer, I suggest that we modify the advice in=20 > draft-oiwa-precis-httpauthprep-00 so that it no longer defines its own=20 > PRECIS profile. Instead, I suggest that we phrase the httpauthprep=20 > text in terms of the username profile in=20 > draft-ietf-precis-saslprepbis-06. To my mind, something like this=20 > would work: > > ### > > For the purposes of HTTP authentication, a username conforms to the=20 > syntax definition and preparation methods specified in=20 > [I.D-draft-ietf-precis-saslprepbis], with the following limitations: > > * a username conforms to the "userpart" construction from=20 > [I-D.draft-ietf-precis-saslprepbis] > * case mapping is not applied > * delimiter mappings, special mappings, and other so-called additional=20 > mappings [I-D.draft-ietf-precis-mappings] are not applied > > ### I agree with your proposal. > As far as I can see, this simplifies the httpautheprep text quite a bit. > > (By the way, draft-oiwa-precis-httpauthprep-00 also seems to copy the=20 > password profile verbatim from draft-ietf-precis-saslprepbis. I think=20 > this text can be removed entirely, so that the httpauthprep text can=20 > simply reference draft-ietf-precis-saslprepbis.) I agree. I don't see there is a reason to have a separate profile for=20 HTTP passwords. > Yutaka and Alexey (and others), let me know what you think about what=20 > I have written here. From nobody Wed Mar 12 17:54:43 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E5A1A07CC for ; Wed, 12 Mar 2014 17:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.078 X-Spam-Level: X-Spam-Status: No, score=-3.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 IbQVGnuv-UoH for ; Wed, 12 Mar 2014 17:54:36 -0700 (PDT) Received: from na3sys010aog104.obsmtp.com (na3sys010aog104.obsmtp.com [74.125.245.76]) by ietfa.amsl.com (Postfix) with ESMTP id 707AD1A07C7 for ; Wed, 12 Mar 2014 17:54:36 -0700 (PDT) Received: from mail-ve0-f176.google.com ([209.85.128.176]) (using TLSv1) by na3sys010aob104.postini.com ([74.125.244.12]) with SMTP ID DSNKUyEBxiTkgrm5W9oX4/Axfh9WLXdmFF3g@postini.com; Wed, 12 Mar 2014 17:54:30 PDT Received: by mail-ve0-f176.google.com with SMTP id cz12so325731veb.21 for ; Wed, 12 Mar 2014 17:54:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vEaZa7pQI2xIAKsWX4o9Uq0FuQeTbS+MybIPdK6ql8E=; b=WNBPMBGQN2Zbye5nH55zhB/5cZVIgBPWfMElUUWV2s2nFqVExzzf91SpbQy7yAQtN3 Q9m/jq4PmyrxXUcTsGEugMj7XznvHnCmj7rdKHc3u1rQT731EdUGMZGL76i2LxCzx1jW 6PI0/BaYbsmTeRO8sDY2rfNtXfJakwWZnB9kI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vEaZa7pQI2xIAKsWX4o9Uq0FuQeTbS+MybIPdK6ql8E=; b=WprAL8J0Z8QBmxkMM5oKioXSz8osoyx8jqiBFYNDWnIaFbEhhsPKbrnbAV00ZuF3tY 9KNzr1CqmXo6e1TRsJBZ/cTJ98vspn8Z/uA4XhwCA6p1BGp5fjqYo4MaL6i7U6xr1tYW l4xptxZ+7mPBtvvLw5f43s8bKOomNAEs90RWT/0qkXk3g9zs4q5Ive2r9ynOxGA566is GsJySVrd1gdJiiynpOi7S8xFkn+tLK2TZlTcCQZ1R8r/A3mH32hV76NPcYmRXgcb/b0o RCR+yvFezY9Fg4DGd0bdLobKCKHr0FA6Aclk3pHPptdlUl69biyUPks/0kQiRuOM5REn yDzg== X-Gm-Message-State: ALoCoQlaWTbhsx0r39Q+tcJqPkY5+/0y+3qHcRjbQ7L3KvsPCFnwZixtj+NDJA49YpIPMfBaycdAODgVYwKOlXTiFJwUF+K9wBNXZ/KSSlRVfFM59+h+QeKuElFmCYcVN9Z2tLWcivjTk8Ig9xGsFrYR4SdQrcG0BA== X-Received: by 10.52.139.237 with SMTP id rb13mr228247vdb.33.1394672069779; Wed, 12 Mar 2014 17:54:29 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.52.139.237 with SMTP id rb13mr228243vdb.33.1394672069626; Wed, 12 Mar 2014 17:54:29 -0700 (PDT) Received: by 10.58.100.227 with HTTP; Wed, 12 Mar 2014 17:54:29 -0700 (PDT) Received: by 10.58.100.227 with HTTP; Wed, 12 Mar 2014 17:54:29 -0700 (PDT) In-Reply-To: <531A09C7.7070904@stpeter.im> References: <531A09C7.7070904@stpeter.im> Date: Thu, 13 Mar 2014 09:54:29 +0900 Message-ID: From: Yutaka OIWA To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=bcaec52c5ccd4a128604f47265b8 Archived-At: http://mailarchive.ietf.org/arch/msg/precis/Av3oGlqS05BzxzmOelnWIV2SpcQ Cc: precis@ietf.org Subject: Re: [precis] usernames in PRECIS and http-auth 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, 13 Mar 2014 00:54:41 -0000 --bcaec52c5ccd4a128604f47265b8 Content-Type: text/plain; charset=ISO-8859-1 Dear Peter, I feel that I'm bit confusing about the situation and possible mistake. As presented in a precis WG long before, and as talked with you with Julien, my intended set for username in HTTP is almost "every printable string", so "@yoiwa", "@@@@@", "Yutaka Oiwa", "Y O" must be all allowed, and my understanding is that saslprepbis does not allow most of these. In other words, http's name must be superset of sasl, and is never be a proper subset of that. Did I made some mistake on specification or interpretation of saslprepbis? -- Yutaka OIWA on mobile 2014/03/08 23:49 "Peter Saint-Andre" : > As promised at IETF 89, I have compared the username definitions from > draft-oiwa-precis-httpauthprep-00 and draft-ietf-precis-saslprepbis-06, > with the purpose of perhaps harmonizing the two approaches so that we can > avoid multiplying PRECIS profiles beyond necessity. > > (I am writing this email on the flight home, and I neglected to load up > the meeting minutes before leaving, so I might not address all of the > relevant points in this message.) > > First, let's look at the syntax definitions. > > draft-ietf-precis-saslprepbis-06 states that a username can (a) consist > of one of more userparts, or (b) can be of the form userpart@domainpart.The ABNF definition is: > > username = userpart [1*(1*SP userpart)] > / userpart '@' domainpart > > userpart = 1*(idpoint) > > domainpart = IP-literal / IPv4address / ifqdn > > ifqdn = 1*1023(domainpoint) > > Where: > > * an "idpoint" is a UTF-8 encoded Unicode code point that conforms to the > PRECIS "IdentifierClass" > * an "IPv4address" is as defined in RFC 3986 > * an "IP-literal" is as defined in RFC 3986 > * a "domainpoint" is a UTF-8 encoded Unicode code point that conforms to > RFC 5890 > > By contrast, draft-oiwa-precis-httpauthprep states that a username > consists of one or more UTF-8 encoded Unicode code points that conform to > the PRECIS "IdentifierClass". The ABNF definition is: > > userpart = 1*(idpoint) > > We quickly see that an http-auth username is a legal PRECIS username, > since 1*(idpoint) is simply a userpart as defined in > draft-ietf-precis-saslprepbis-06, and a PRECIS username can consist of > only one userpart. Therefore, in this respect, I think the httpauthprep > text (whether it appears in a standalone document or elsewhere) can simply > state that for purposes of HTTP authentication a username is a userpart as > defined in draft-ietf-precis-saslprepbis. > > Second, let's look at the string preparation method. > > Here, too, draft-oiwa-precis-httpauthprep-00 is a subset of > draft-ietf-precis-saslprepbis-06. The preparation method in > draft-ietf-precis-saslprepbis-06 is: > > 1. The base string class is the "IdentifierClass" specified in > [I-D.ietf-precis-framework]. > 2. Fullwidth and halfwidth characters MUST be mapped to their > decomposition equivalents. > 3. So-called additional mappings MAY be applied, such as those > defined in [I-D.ietf-precis-mappings]. > 4. Uppercase and titlecase characters might be mapped to their > lowercase equivalents (see Section 4.2.1 below). > 5. Unicode Normalization Form C (NFC) MUST be applied to all > characters. > > By contrast, the preparation method in draft-oiwa-precis-httpauthprep-00 > is: > > 1. Fullwidth and halfwidth characters MUST be mapped to their > decomposition equivalents. > 2. Additional mappings SHOULD NOT be applied, such as those defined > in [I-D.ietf-precis-mappings], unless there are implementation- > dependent reasons to do so, or these are exceptionally required > by specific authentication schemes. > 3. Case mapping is not applied. > 4. Unicode Normalization Form C (NFC) MUST be applied to all > characters.o > > These two defnitions agree on the width mapping and normalization rules > described in the PRECIS framework. They appear to differ slightly with > regard to the additional mapping and case mapping rules. However, > draft-oiwa-precis-httpauthprep-00 is merely a bit more restrictive with > regard to matters that are purely optional according to > draft-ietf-precis-saslprepbis-06. For example, the option of saying that > "case mapping is not applied" is allowed by the text "uppercase and > titlecase characters might be mapped to their lowercase equivalents". > > To make this clearer, I suggest that we modify the advice in > draft-oiwa-precis-httpauthprep-00 so that it no longer defines its own > PRECIS profile. Instead, I suggest that we phrase the httpauthprep text in > terms of the username profile in draft-ietf-precis-saslprepbis-06. To my > mind, something like this would work: > > ### > > For the purposes of HTTP authentication, a username conforms to the syntax > definition and preparation methods specified in [I.D-draft-ietf-precis-saslprepbis], > with the following limitations: > > * a username conforms to the "userpart" construction from > [I-D.draft-ietf-precis-saslprepbis] > * case mapping is not applied > * delimiter mappings, special mappings, and other so-called additional > mappings [I-D.draft-ietf-precis-mappings] are not applied > > ### > > As far as I can see, this simplifies the httpautheprep text quite a bit. > > (By the way, draft-oiwa-precis-httpauthprep-00 also seems to copy the > password profile verbatim from draft-ietf-precis-saslprepbis. I think this > text can be removed entirely, so that the httpauthprep text can simply > reference draft-ietf-precis-saslprepbis.) > > Yutaka and Alexey (and others), let me know what you think about what I > have written here. > > Thanks, > > Peter > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis > --bcaec52c5ccd4a128604f47265b8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Dear Peter,

I feel that I'm bit confusing about the situation and po= ssible mistake.

As presented in a precis WG long before, and as talked with = you with Julien,
my intended set for username in HTTP is almost "every printable string= ", so
"@yoiwa", "@@@@@", "Yutaka Oiwa",
"Y      O" must be all allowed, and
my understanding is that saslprepbis does not allow most of these.
In other words, http's name must be superset of sasl, and is never be a= proper subset of that.
Did I made some mistake on specification or interpretation of saslprepbis?<= br>

--
Yutaka OIWA <y.oiwa@aist.go.jp&= gt; on mobile

2014/03/08 23:49 "Peter Saint-Andre" &= lt;stpeter@stpeter.im>:
As promised at IETF 89, I have compared the username definitions from draft= -oiwa-precis-httpauthprep-00 and draft-ietf-precis-saslprepbis-06, with the purpose of perhaps harmonizing the two approaches so that we= can avoid multiplying PRECIS profiles beyond necessity.

(I am writing this email on the flight home, and I neglected to load up the= meeting minutes before leaving, so I might not address all of the relevant= points in this message.)

First, let's look at the syntax definitions.

draft-ietf-precis-saslprepbis-06 states that a username can (a) cons= ist of one of more userparts, or (b) can be of the form userpart@domainpart= . The ABNF definition is:

   username   =3D userpart [1*(1*SP userpart)]
              / userpart ’@’= domainpart

   userpart   =3D 1*(idpoint)

   domainpart =3D IP-literal / IPv4address / ifqdn

   ifqdn      =3D 1*1023(domainpoint)

Where:

* an "idpoint" is a UTF-8 encoded Unicode code point that conform= s to the PRECIS "IdentifierClass"
* an "IPv4address" is as defined in RFC 3986
* an "IP-literal" is as defined in RFC 3986
* a "domainpoint" is a UTF-8 encoded Unicode code point that conf= orms to RFC 5890

By contrast, draft-oiwa-precis-httpauthprep states that a username consists= of one or more UTF-8 encoded Unicode code points that conform to the PRECI= S "IdentifierClass". The ABNF definition is:

   userpart   =3D 1*(idpoint)

We quickly see that an http-auth username is a legal PRECIS username, since= 1*(idpoint) is simply a userpart as defined in draft-ietf-precis-saslprepb= is-06, and a PRECIS username can consist of only one userpart. There= fore, in this respect, I think the httpauthprep text (whether it appears in= a standalone document or elsewhere) can simply state that for purposes of = HTTP authentication a username is a userpart as defined in draft-ietf-preci= s-saslprepbis.

Second, let's look at the string preparation method.

Here, too, draft-oiwa-precis-httpauthprep-00 is a subset of draft-ie= tf-precis-saslprepbis-06. The preparation method in draft-ietf-preci= s-saslprepbis-06 is:

   1.  The base string class is the "IdentifierClass&qu= ot; specified in
       [I-D.ietf-precis-framework].
   2.  Fullwidth and halfwidth characters MUST be mapped to = their
       decomposition equivalents.
   3.  So-called additional mappings MAY be applied, such as= those
       defined in [I-D.ietf-precis-mappings].
   4.  Uppercase and titlecase characters might be mapped to= their
       lowercase equivalents (see Section 4.2.1 below).=
   5.  Unicode Normalization Form C (NFC) MUST be applied to= all
       characters.

By contrast, the preparation method in draft-oiwa-precis-httpauthpre= p-00 is:

   1.  Fullwidth and halfwidth characters MUST be mapped to = their
       decomposition equivalents.
   2.  Additional mappings SHOULD NOT be applied, such as th= ose defined
       in [I-D.ietf-precis-mappings], unless there are = implementation-
       dependent reasons to do so, or these are excepti= onally required
       by specific authentication schemes.
   3.  Case mapping is not applied.
   4.  Unicode Normalization Form C (NFC) MUST be applied to= all
       characters.o

These two defnitions agree on the width mapping and normalization rules des= cribed in the PRECIS framework. They appear to differ slightly with regard = to the additional mapping and case mapping rules. However, draft-oiwa-preci= s-httpauthprep-00 is merely a bit more restrictive with regard to ma= tters that are purely optional according to draft-ietf-precis-saslprepbis-<= u>06. For example, the option of saying that "case mapping is not = applied" is allowed by the text "uppercase and titlecase characte= rs might be mapped to their lowercase equivalents".

To make this clearer, I suggest that we modify the advice in draft-oiwa-pre= cis-httpauthprep-00 so that it no longer defines its own PRECIS prof= ile. Instead, I suggest that we phrase the httpauthprep text in terms of th= e username profile in draft-ietf-precis-saslprepbis-06. To my mind, = something like this would work:

###

For the purposes of HTTP authentication, a username conforms to the syntax = definition and preparation methods specified in [I.D-draft-ietf-precis-<= /u>saslprepbis], with the following limitations:

* a username conforms to the "userpart" construction from [I-D.dr= aft-ietf-precis-saslprepbis]
* case mapping is not applied
* delimiter mappings, special mappings, and other so-called additional mapp= ings [I-D.draft-ietf-precis-mappings] are not applied

###

As far as I can see, this simplifies the httpautheprep text quite a bit.
(By the way, draft-oiwa-precis-httpauthprep-00 also seems to copy th= e password profile verbatim from draft-ietf-precis-saslprepbis. I think thi= s text can be removed entirely, so that the httpauthprep text can simply re= ference draft-ietf-precis-saslprepbis.)

Yutaka and Alexey (and others), let me know what you think about what I hav= e written here.

Thanks,

Peter

_______________________________________________
precis mailing list
precis@ietf.org = https://www.ietf.org/mailman/listinfo/precis
--bcaec52c5ccd4a128604f47265b8-- From nobody Fri Mar 14 16:48:27 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 509D01A0215 for ; Fri, 14 Mar 2014 16:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sT8M-jND9_BE for ; Fri, 14 Mar 2014 16:48:23 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id EDD841A0212 for ; Fri, 14 Mar 2014 16:48:22 -0700 (PDT) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AB5B1404A1 for ; Fri, 14 Mar 2014 17:48:15 -0600 (MDT) Message-ID: <5323953F.2070805@stpeter.im> Date: Fri, 14 Mar 2014 17:48:15 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "precis@ietf.org" References: <531E5913.5020203@stpeter.im> In-Reply-To: <531E5913.5020203@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/eKfySOnEHFVMrqx-uaEmOh_knIg Subject: Re: [precis] case mapping text in framework 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, 14 Mar 2014 23:48:25 -0000 Seeing no objections, I'm going to submit a revised I-D now with these modifications and a few other small corrections. On 3/10/14, 6:30 PM, Peter Saint-Andre wrote: > In London, we talked about clarifying the text about case mapping in the > framework document. I propose the following modifications... > > Section 4.1.3 > > OLD > > Another option is to use the "local case mapping" method specified in > [I-D.ietf-precis-mappings]. Note: because that method applies normal > case mapping to Unicode characters that do not have special rules for > locale-dependent or context-dependent mapping, if case mapping is > desired then a profile needs to specify either the "local case > mapping" method from [I-D.ietf-precis-mappings] or another method > such as Unicode Default Case Folding. > > NEW > > Note: Unicode Default Case Folding does not take into account > localization issues (such as "dotless i" in several Turkic > languages). The PRECIS mappings document [I-D.ietf-precis-mappings] > describes these issues in greater detail and defines a "local case > mapping" method that handles some locale-dependent and context- > dependent mappings. > > Section 5 > > OLD > > 3. Case mapping as described under Section 4.1.3 of this document > (typically either the "local case mapping" method from > [I-D.ietf-precis-mappings] or Unicode Default Case Folding) > > NEW > > 3. Case mapping as described under Section 4.1.3 of this document. > > Once we have made these changes, I think we can change the mappings > document from a normative reference to an informative reference in the > framework document. > > Peter > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis From nobody Fri Mar 14 16:51:00 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A99D1A0212; Fri, 14 Mar 2014 16:50:55 -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 H5BQbfy6By1z; Fri, 14 Mar 2014 16:50:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7B01A021E; Fri, 14 Mar 2014 16:50:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.1.0p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140314235051.8974.87107.idtracker@ietfa.amsl.com> Date: Fri, 14 Mar 2014 16:50:51 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/precis/iokTa9Ty7hd_IUouahay4CNxvKk Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-framework-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: Fri, 14 Mar 2014 23:50:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Preparation and Comparison of Internationalized Strings Working Group of the IETF. Title : PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols Authors : Peter Saint-Andre Marc Blanchet Filename : draft-ietf-precis-framework-15.txt Pages : 64 Date : 2014-03-14 Abstract: Application protocols using Unicode characters in protocol strings need to properly prepare such strings in order to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode characters and thus is agile with respect to versions of Unicode. As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454). This document obsoletes RFC 3454. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-framework/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-precis-framework-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-framework-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Mar 14 18:55:48 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB421A0260 for ; Fri, 14 Mar 2014 18:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HrGM3I23YI8 for ; Fri, 14 Mar 2014 18:55:43 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFA81A0229 for ; Fri, 14 Mar 2014 18:55:43 -0700 (PDT) Received: from [192.168.1.4] (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BB63B4049A; Fri, 14 Mar 2014 19:55:35 -0600 (MDT) Message-ID: <5323B309.3070700@stpeter.im> Date: Fri, 14 Mar 2014 19:55:21 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Yutaka OIWA References: <531A09C7.7070904@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/KV3V355iMq90LuHl_W744zoZN54 Cc: precis@ietf.org Subject: Re: [precis] usernames in PRECIS and http-auth X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 01:55:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/12/2014 06:54 PM, Yutaka OIWA wrote: > Dear Peter, > > I feel that I'm bit confusing about the situation and possible > mistake. > > As presented in a precis WG long before, and as talked with you > with Julien, my intended set for username in HTTP is almost "every > printable string", so "@yoiwa", "@@@@@", "Yutaka Oiwa", "Y O" > must be all allowed, and my understanding is that saslprepbis does > not allow most of these. In other words, http's name must be > superset of sasl, and is never be a proper subset of that. Did I > made some mistake on specification or interpretation of > saslprepbis? What you describe is not consistent wtih the definition in your document, because your ABNF says that only characters from the IdentifierClass are allowed (note, for example, SPACE is disallowed in the IdentifierClass). When you say "every printable string", does that include all symbol characters, all punctuation characters, every kind of space character (not just ASCII space), etc.? What about characters that are disallowed even by the FreeformClass, such as Old Hangul Jamo characters, control characters, and the ignorable characters described in Section 7.13 of the PRECIS framework specification? I think you need to revisit your httpauthprep document and more clearly define the allowable characters for your use cases in terms of the PRECIS framework. If you really want to allow "Y O" (with six spaces between 'Y' and 'O') as an HTTP username then even draft-ietf-precis-nickname is too restrictive for you. A wider question: why do you think that the definition of an HTTP username needs to be so loose? Do you define things this way to be backward compatible with existing implementations, or do you really think that this is a best practice? I'm truly curious. (And I wonder if we even want to call this construct a "username"...) Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTI7MJAAoJEOoGpJErxa2pBu0P/3QCU4zx2i/smvPk5RJAlkYq 8b17rjXZfnS+K4zLS89FI7KtBsQjGglT7CTvoe4VJt9Xr62/xpMdgRIhfjOC8ZgA hAs0l7zbADArHgcA1AENBVUV0C/GGu5QPgJRgn/Mhnf51JxVgyu2ejG+iL0amr7I +eQ+0aEhefItYpXF3rhiB8c3hZK+YRrpj6yK4WUDeSzGUi6MPQyhq6WkfHX87gNj SsN0T26wIUq5asXKbTC7Yia1aABBYwp+DwMu4O46CkltRv3MYdX1sIAE4sljgzaE 837hQE10WTXgSJOQ/qyIHsIBddAItvwewzYNEqUjT1fo8de/hL2gMQ/KV+VTyBEi eq59I5wlvqBNlmGj8mOWtv1aVPk/0ANLHeOJVdgumppkYhRbvmSGfjZ5qsFLMDML hDxHeQdYb319KlNTrbRmcPLgBZnv5Mlk8T5p9/jUIkID4gk8lDEOVGHImI7ip/jK z0mgrCmbsWJtu12cKMHy34URtYVVN0pfdVGup/83/mK4Aq67Mb2iCnv6xWXsc61l 1OtGFh1KNY8fTkpabUPwFj5ZAMARI32EQNUbwF4A7kh4aktItqyq6IWhOq3qABlt Z6xl3gofvbOQ3LDrrqY/7XKxWNtz4WaGWa0b9SWe8zgopXxQ5W/QncmtMqkCnrG+ aWDhAUslrrTuqHqw15mp =aaQD -----END PGP SIGNATURE----- From nobody Fri Mar 14 19:49:00 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0C91A0236 for ; Fri, 14 Mar 2014 19:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, 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 cKay9DVU2FAG for ; Fri, 14 Mar 2014 19:48:54 -0700 (PDT) Received: from na3sys010aog111.obsmtp.com (na3sys010aog111.obsmtp.com [74.125.245.90]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDD91A0230 for ; Fri, 14 Mar 2014 19:48:54 -0700 (PDT) Received: from mail-vc0-f178.google.com ([209.85.220.178]) (using TLSv1) by na3sys010aob111.postini.com ([74.125.244.12]) with SMTP ID DSNKUyO/j0wMIkn5ufKwB3xWoi8oltVaqbSh@postini.com; Fri, 14 Mar 2014 19:48:47 PDT Received: by mail-vc0-f178.google.com with SMTP id im17so3748724vcb.9 for ; Fri, 14 Mar 2014 19:48:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jM9LMreODZywIjVddwLgf05SWICG90MEeyEV71YHu1A=; b=mgOJkgBWqCtoBY7SuyPU87pK4m4Xn9I349gbr3FEsVhRL442SWtDEHNND39HaQLw5K wIm5H+9tTd2kYiT2GW4ctRax+KkQEVwKa3S8tQgytrCiX6vyqFhs/uKqtWKxsQP3cC2E eNNu0prptRHcgB1tSzKWOekUwAizLzGX/NFpg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=jM9LMreODZywIjVddwLgf05SWICG90MEeyEV71YHu1A=; b=nJ8OEUZh3nvDARUnbYVDagu1XlYYZhm1k9zNT4HeinL4LWTBsh2XHOC0nQQ6XQ7eii cNZKr/zVopctlOU4yVzpsXOqVeUqWo1J98/T7gBdKk1eEveNWmp34+3QZ2A8AVjIT5aX YRytwLcWHS09u21XTSphUa58lwONOWhTzyUrkJKrik2i//DjoRXiH5mNNnpRkMEJdAsJ lRQAxiOCFb0+XAsHzIwf0NoTXknvISVJZjtR2cxBoiuwiItQkc4h2SV9QGU1DadU8G99 IWvaigss9uW40owTXuDX599PvSuqs7nJUDAhFaZN1n6igWYLSMIWuRR0X8W6Zfs+nwQt 7qLQ== X-Gm-Message-State: ALoCoQnduXs+qpkYd51Z7Ew+SzTXlp6mscVHeWbR/mBp9h97HHnql4+/ANufio4iGs7Yb92DzbfNNUz4FfCxfFa6Q4ACQ6KMnDN+njijr7oKPjCTsFd0j7eNimx2Xm3tvmR2e8CusjC8bE3FfvgYivEIasTuQcIgsg== X-Received: by 10.52.139.237 with SMTP id rb13mr25558vdb.33.1394851726799; Fri, 14 Mar 2014 19:48:46 -0700 (PDT) X-Received: by 10.52.139.237 with SMTP id rb13mr25555vdb.33.1394851726666; Fri, 14 Mar 2014 19:48:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.100.227 with HTTP; Fri, 14 Mar 2014 19:48:26 -0700 (PDT) In-Reply-To: <5323B309.3070700@stpeter.im> References: <531A09C7.7070904@stpeter.im> <5323B309.3070700@stpeter.im> From: Yutaka OIWA Date: Sat, 15 Mar 2014 11:48:26 +0900 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/precis/6P5IvrL7xsLF0pR_JyVuOK7YhX0 Cc: precis@ietf.org Subject: Re: [precis] usernames in PRECIS and http-auth X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 02:48:57 -0000 Dear Peter and all PRECIS related members, Thank you very much, and I'm really sorry that our definition had a serious mistake which have confused many of you. I'll talk with co-authors (especially, Nemoto-san) again and revise the document as soon as possible, to restart the next steps as fast as possible. # That's why our specification has mentioned about # the mapping for spaces, which are not included by current definition. When I talked with Peter and Julian, we mentioned about another character classes during the talk, and at that time I should be noticed that I possibly referred the incorrect class. > A wider question: why do you think that the definition of an HTTP > username needs to be so loose? Do you define things this way to be > backward compatible with existing implementations, or do you really > think that this is a best practice? I'm truly curious. (And I wonder > if we even want to call this construct a "username"...) I think the reasons are both. 1: For backward compatibility, we need to keep all ASCII "printable" (U+0020 - U+007E, including SP) characters as is, as well as Latin-1 printable (U+00A1 - U+00FF, except SHY) be independent. 2: For more semantic reasons, HTTP authentication will be a vehicle for many different kinds of existing application frameworks, including IMs, Web mails, social network, and others. It should be able to accept all kinds of "user name" formats, for example a simple "user ID" (yoiwa), user "Name" (Yutaka OIWA), a mail address (y.oiwa@example.com), Social ID formats (@yoiwa or =yoiwa), and many others. Unlike SASL or XMPP which have its own semantics in framework, the authentication names in HTTP must be semanticless, unstructured strings, which can later be added a meaningful semantics for each application which uses Web/HTTP. We are not likely to correct all possible use cases of IDs which are to be used with HTTP (including future uses) and then take a union set of these, so instead we're defining a "grand-father" ID notations, expecting that all ID string use-cases are likely to be subsets of it. At the same time, defining it just a "UTF-8" makes users' confusion and inter-operability mess about possible "visiblly-same" strings, so we must care about that side of string preparation with PRECIS. For example, NBSP and other spaces should be replaced. 2014-03-15 10:55 GMT+09:00 Peter Saint-Andre : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 03/12/2014 06:54 PM, Yutaka OIWA wrote: >> Dear Peter, >> >> I feel that I'm bit confusing about the situation and possible >> mistake. >> >> As presented in a precis WG long before, and as talked with you >> with Julien, my intended set for username in HTTP is almost "every >> printable string", so "@yoiwa", "@@@@@", "Yutaka Oiwa", "Y O" >> must be all allowed, and my understanding is that saslprepbis does >> not allow most of these. In other words, http's name must be >> superset of sasl, and is never be a proper subset of that. Did I >> made some mistake on specification or interpretation of >> saslprepbis? > > What you describe is not consistent wtih the definition in your > document, because your ABNF says that only characters from the > IdentifierClass are allowed (note, for example, SPACE is disallowed in > the IdentifierClass). > > When you say "every printable string", does that include all symbol > characters, all punctuation characters, every kind of space character > (not just ASCII space), etc.? What about characters that are > disallowed even by the FreeformClass, such as Old Hangul Jamo > characters, control characters, and the ignorable characters described > in Section 7.13 of the PRECIS framework specification? > > I think you need to revisit your httpauthprep document and more > clearly define the allowable characters for your use cases in terms of > the PRECIS framework. If you really want to allow "Y O" (with six > spaces between 'Y' and 'O') as an HTTP username then even > draft-ietf-precis-nickname is too restrictive for you. > > A wider question: why do you think that the definition of an HTTP > username needs to be so loose? Do you define things this way to be > backward compatible with existing implementations, or do you really > think that this is a best practice? I'm truly curious. (And I wonder > if we even want to call this construct a "username"...) > > Peter > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJTI7MJAAoJEOoGpJErxa2pBu0P/3QCU4zx2i/smvPk5RJAlkYq > 8b17rjXZfnS+K4zLS89FI7KtBsQjGglT7CTvoe4VJt9Xr62/xpMdgRIhfjOC8ZgA > hAs0l7zbADArHgcA1AENBVUV0C/GGu5QPgJRgn/Mhnf51JxVgyu2ejG+iL0amr7I > +eQ+0aEhefItYpXF3rhiB8c3hZK+YRrpj6yK4WUDeSzGUi6MPQyhq6WkfHX87gNj > SsN0T26wIUq5asXKbTC7Yia1aABBYwp+DwMu4O46CkltRv3MYdX1sIAE4sljgzaE > 837hQE10WTXgSJOQ/qyIHsIBddAItvwewzYNEqUjT1fo8de/hL2gMQ/KV+VTyBEi > eq59I5wlvqBNlmGj8mOWtv1aVPk/0ANLHeOJVdgumppkYhRbvmSGfjZ5qsFLMDML > hDxHeQdYb319KlNTrbRmcPLgBZnv5Mlk8T5p9/jUIkID4gk8lDEOVGHImI7ip/jK > z0mgrCmbsWJtu12cKMHy34URtYVVN0pfdVGup/83/mK4Aq67Mb2iCnv6xWXsc61l > 1OtGFh1KNY8fTkpabUPwFj5ZAMARI32EQNUbwF4A7kh4aktItqyq6IWhOq3qABlt > Z6xl3gofvbOQ3LDrrqY/7XKxWNtz4WaGWa0b9SWe8zgopXxQ5W/QncmtMqkCnrG+ > aWDhAUslrrTuqHqw15mp > =aaQD > -----END PGP SIGNATURE----- -- Yutaka OIWA, Ph.D. Leader, System Life-cycle Research Group Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From nobody Sun Mar 23 18:31:57 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FF01A0090 for ; Sun, 23 Mar 2014 18:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.299 X-Spam-Level: *** X-Spam-Status: No, score=3.299 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 nKO-bcFbEAlz for ; Sun, 23 Mar 2014 18:31:54 -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 483241A0089 for ; Sun, 23 Mar 2014 18:31:54 -0700 (PDT) Received: from [192.168.0.5] (i114-185-245-87.s41.a012.ap.plala.or.jp [114.185.245.87]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.kmd.keio.ac.jp (Postfix) with ESMTPSA id 8F9FB7FBD1 for ; Mon, 24 Mar 2014 10:31:50 +0900 (JST) From: Takahiro Nemoto Content-Type: multipart/signed; boundary="Apple-Mail=_87E80772-BD6B-492F-A579-F7356B9CB417"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: Date: Mon, 24 Mar 2014 10:31:49 +0900 To: precis@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/precis/33DBqerawyqPUHSOku4GrzNGn9w Subject: [precis] proposed modifications of mappings document 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, 24 Mar 2014 01:31:56 -0000 --Apple-Mail=_87E80772-BD6B-492F-A579-F7356B9CB417 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, I am trying to reflect comments from the discussion in a last WG in = London. I would like you to review the following modifications and give your = comments/suggestions. Abstract & 1. Introduction OLD 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 alternative to Unicode Default Case Folding as case mapping in the PRECIS framework. NEW 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 delimiter mapping and special = mapping=20 rules described here are applied as "additional mappings" beyond = those=20 defined in the PRECIS framework, whereas the "local case mapping" = rule=20 is applied as an option of methods that handles some locale-dependent=20= and context-dependent mappings, which is the case mapping rule=20 specified in the PRECIS framework.=20 2.3. Local case mapping OLD If a codepoint is a target, the case folding method for the codepoint is mapping into lower case as defined in SpecialCasing.txt. On the other hand, if a codepoint is not a target, the case folding method for the codepoint is the same with case mapping in PRECIS framework. This local case mapping provides alternative case folding method to Unicode Default Case Folding as case mapping in the PRECIS framework, therefore if a PRECIS profile chooses local case mapping, it should not choose case mapping. The reason for this is written in the Appendix B. NEW The case folding method for a target character is to map into lower = case=20 as defined in SpecialCasing.txt. The case folding method for all = other,=20 non-target characters is as specified in Section 4.1.3 of the PRECIS=20= framework (i.e., Unicode Default Case Folding SHOULD be used for all=20= non-target characters). If an application supports users' locale = and/or=20 context and gets them information from user input, local case mapping=20= can increase the probability of getting matching-results from the = comparison=20 between strings. 3. Order of operations OLD The mappings described in this document are expected to be applied as additional mappings and alternative to Unicode Default Case Folding as case mapping in the PRECIS framework. The mappings described in this document could be applied in any order. This section specifies a particular order to minimize the effect of codepoint changes introduced by the mappings. This mapping order is very general and has been designed to be acceptable to the widest user community. NEW The mappings described in this document are expected to be applied as additional mappings in the PRECIS framework. The mappings described = in this document could be applied in any order. This section specifies a particular order to minimize the effect of codepoint changes introduced by the mappings. This mapping order is very general and has been designed to be acceptable to the widest user community. Regards, Nemo -- Takahiro Nemoto t.nemo10@kmd.keio.ac.jp --Apple-Mail=_87E80772-BD6B-492F-A579-F7356B9CB417 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJTL4sFAAoJEJk7o/xhVanahAkH/01g6G+RcD+IlqPZHYDuL1E8 UPyzEQoYvZ2a9iUyQ1nDPTw603GmuJwspUB2qbhAd5ztonmmPoLKDxQD8ct/6rU/ CJctwW8oUAKokRWoSwDjw07WwiR9bTsPG2XQslfr6Er7peMPs0+wN4tT5+WEeqwp f19CchVqdav+Umi/ixxwUwl/LdNOBalu84BgO4cMG7/6io5acMNr9CYQ52hROIHe 0Ot9/6cU+E0c65e0oj2c1/jwMXp/qSsYix89VMwBqXNiy7mj7OUm/BobuceR996R dubAKyLPsaWooZ2HiK8xo8fQNAirlE+yuIeP1TbWGdN9nIg8hAtLBVJFq7qnaNY= =ZlpU -----END PGP SIGNATURE----- --Apple-Mail=_87E80772-BD6B-492F-A579-F7356B9CB417-- From nobody Mon Mar 24 20:36:17 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9121A1A0330 for ; Mon, 24 Mar 2014 20:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.788 X-Spam-Level: X-Spam-Status: No, score=0.788 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-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 99NBngAtmoEi for ; Mon, 24 Mar 2014 20:36:14 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A8D021A031A for ; Mon, 24 Mar 2014 20:36:14 -0700 (PDT) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0E0DB4032A; Mon, 24 Mar 2014 21:36:12 -0600 (MDT) Message-ID: <5330F9AB.30204@stpeter.im> Date: Mon, 24 Mar 2014 21:36:11 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Yutaka OIWA References: <531A09C7.7070904@stpeter.im> <5323B309.3070700@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/B05qJqrlX4PhDKLRbk8QKwEEZyI Cc: precis@ietf.org Subject: Re: [precis] usernames in PRECIS and http-auth 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, 25 Mar 2014 03:36:16 -0000 On 3/14/14, 8:48 PM, Yutaka OIWA wrote: > Dear Peter and all PRECIS related members, > > Thank you very much, and I'm really sorry that our definition > had a serious mistake which have confused many of you. > I'll talk with co-authors (especially, Nemoto-san) again and > revise the document as soon as possible, > to restart the next steps as fast as possible. > > # That's why our specification has mentioned about > # the mapping for spaces, which are not included by current definition. > > When I talked with Peter and Julian, we mentioned about > another character classes during the talk, and at that time > I should be noticed that I possibly referred the incorrect class. > >> A wider question: why do you think that the definition of an HTTP >> username needs to be so loose? Do you define things this way to be >> backward compatible with existing implementations, or do you really >> think that this is a best practice? I'm truly curious. (And I wonder >> if we even want to call this construct a "username"...) > I think the reasons are both. > > 1: For backward compatibility, we need to keep all ASCII "printable" > (U+0020 - U+007E, including SP) characters as is, as well as > Latin-1 printable (U+00A1 - U+00FF, except SHY) be independent. I think "saslprepbis" does this. > 2: For more semantic reasons, HTTP authentication will be a vehicle > for many different kinds of existing application frameworks, including > IMs, Web mails, social network, and others. > It should be able to accept all kinds of "user name" formats, > for example a simple "user ID" (yoiwa), user "Name" (Yutaka OIWA), > a mail address (y.oiwa@example.com), > Social ID formats (@yoiwa or =yoiwa), Here again, I think that "saslprepbis" handles those. > and many others. Here we might have some disagreement. If we think that http-auth needs to allow just about any string as a "userid" (to use the term from RFC 2617 - I don't want to call it a username), then even a PRECIS profile as loose as draft-ietf-precis-nickname is too strict for your purposes. However, I question whether those purposes are justified. Do we really expect that an actual userid in http-auth might be any of the following? "Y u taka O i w a " "♖♘♗♕♔♗♘♖" (i.e., the back line of white chess pieces) "mycatisa bby" (where those spaces are actually a tab) and so on. Do we have evidence from existing applications that we need to support strings of characters like those as userids in HTTP authentication? Or are we being way too liberal in what we accept? > Unlike SASL or XMPP which have its own semantics in framework, > the authentication names in HTTP must be semanticless, > unstructured strings, which can later be added a meaningful > semantics for each application which uses Web/HTTP. > > We are not likely to correct all possible use cases of > IDs which are to be used with HTTP (including future uses) and > then take a union set of these, > so instead we're defining a "grand-father" ID notations, > expecting that all ID string use-cases are likely to be subsets of it. My concern is that this "grandfather set" is every Unicode character, and if we allow that then we're really not providing any kind of helpful guidance to application developers. One fundamental assumption underlying the PRECIS work is that it is our responsibility as internationalization experts to prevent application developers from shooting themselves in the foot. In particular, the IdentifierClass in the PRECIS framework tries to provide a safe subset of characters, and the username construct in "saslprepbis" profiles the IdentifierClass so that application developers can avoid trouble. As far as I can see, what you are proposing would invite such trouble, and I'm not comfortable with that. > At the same time, defining it just a "UTF-8" makes users' confusion > and inter-operability mess about possible "visiblly-same" strings, > so we must care about that side of string preparation with PRECIS. > For example, NBSP and other spaces should be replaced. Hmm. So you are saying that if a user inputs the following string: "Iam cey" Then " " would be replaced with U+0020 (SPACE) as follows: "Iam cey" "Just UTF-8" is just as useless for internationalization as "just TLS" is for security. I definitely agree that we need something more than "just UTF-8", which is why we've put so much work into PRECIS. Although we cannot solve the problem of confusable characters, we can define some string classes that "first do no harm" (is there a Hippocratic Oath for i18n?). So far, I do not think that what you are proposing does no harm, in fact I think it is actively harmful to allow such a wide range of Unicode characters into userids. Peter From nobody Mon Mar 24 23:53:32 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2009C1A037E for ; Mon, 24 Mar 2014 23:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.079 X-Spam-Level: X-Spam-Status: No, score=-3.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 qy6-pX-0eLaT for ; Mon, 24 Mar 2014 23:53:18 -0700 (PDT) Received: from na3sys010aog111.obsmtp.com (na3sys010aog111.obsmtp.com [74.125.245.90]) by ietfa.amsl.com (Postfix) with ESMTP id 184661A037F for ; Mon, 24 Mar 2014 23:53:17 -0700 (PDT) Received: from mail-ve0-f175.google.com ([209.85.128.175]) (using TLSv1) by na3sys010aob111.postini.com ([74.125.244.12]) with SMTP ID DSNKUzEn3QG6LXoZYyX6WeF7HnTG/sX5MDiT@postini.com; Mon, 24 Mar 2014 23:53:17 PDT Received: by mail-ve0-f175.google.com with SMTP id oz11so36620veb.34 for ; Mon, 24 Mar 2014 23:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=Ip8R8SUj6T4EaIkzovzBUmrGjOODaF/COmauSLqIO18=; b=FQHBK6Mflt7SHDeIKmMnlXcr2PpUX7fO6RSTlLf3kv7RSkWwZyWP5woeY3Ygedtja+ b7LkSPlB/bRtFnUyqsJI21aap2NDKepBsOlhv2J+bSiPXaC2/lxcHTDL85trD8BSE8Rq /xmjfii3E6JXbkSmJhu6QEMe55dYo2kAsx0ys= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Ip8R8SUj6T4EaIkzovzBUmrGjOODaF/COmauSLqIO18=; b=EqSF0KUGYw1z+ZX7uh5Qtf4nEeNMBxou5jCO2AEsSt1ZnoT7pue8S8smqBnrDmiLKW ABW2JB+btOk/HGzK0Fm5oMnS4YZ371RJG/BGu8tba56pDFBoAfSGiO8ahFRd/K3AINLK c85oEonV4prVBJu6ALqmHwj+LZmMh3/uA4AO5/WnFAb2j6Wqj4gjOiVmbkQwF2OE4EBf dPsvrIRws98x0eIaGhsyqqWd6lESl4jsQJJskLMiKQsgFUr7t+TTIeVR76skzQ2gRvlN b8FpHMusn5RfB4vp42o5qQhDB6nwh28OAxbbecC3XGUhSZVmRKr6trRW2KFBYib+ePzr o//Q== X-Gm-Message-State: ALoCoQl3Pya+DQl6A865yT3Uy5y0ZhraOqruoIuDUKhoyade+JQRrOgRg2jleSVjCKLupaGtfnqrioY1JIO/WlaHITJxbD+Wgm+SjwvhN1KR8dFB/eb6nFFT6SR3nJo7PjsLBiKSp6Fj8XowVPhLgcQHSFfKLZcqPQ== X-Received: by 10.58.38.166 with SMTP id h6mr5933872vek.22.1395730396626; Mon, 24 Mar 2014 23:53:16 -0700 (PDT) X-Received: by 10.58.38.166 with SMTP id h6mr5933862vek.22.1395730396506; Mon, 24 Mar 2014 23:53:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.100.227 with HTTP; Mon, 24 Mar 2014 23:52:56 -0700 (PDT) In-Reply-To: <5330F9AB.30204@stpeter.im> References: <531A09C7.7070904@stpeter.im> <5323B309.3070700@stpeter.im> <5330F9AB.30204@stpeter.im> From: Yutaka OIWA Date: Tue, 25 Mar 2014 15:52:56 +0900 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/precis/1uyi4gohuFZY7tUehD0a5WtKoC8 Cc: precis@ietf.org Subject: Re: [precis] usernames in PRECIS and http-auth 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, 25 Mar 2014 06:53:22 -0000 Dear Peter, I have a side question: looking into saslprepbis spec, username =3D userpart [1*(1*SP userpart)] / userpart =E2=80=99@=E2=80=99 domainpart userpart =3D 1*(idpoint) domainpart =3D IP-literal / IPv4address / ifqdn ifqdn =3D 1*1023(domainpoint) Is the set of strings generated by "userpart '@' domainpart" the proper subset of the set generated by userpart rule? If so, I will be more-than-80% happy by just removing the redundant second line from the username rule. We (from HTTP side) do not want any rule which may even *seem* to handle any characters (here, the @ mark) specially than others. It's up to the application's own definition. We're aware of some use case for which the application defines a meaningful semantics for strings with 2 @ marks. (user@domain style identifier used for roaming accesses, appended with another @provider-domain suffix. So, the result is user@internal-domain@external-domain.) (Exception: the colon is special in HTTP Basic and Digest, but I see it as a known technical issue of these and should not be generalized for every HTTP authentication.) I have to (and will) dig in to the original Unicode table for more analysis, but the thing I intuitively want seems to be something between IdentifierClass and FreeFormClass. My answers to the Peter's questions: > "Y u taka O i w a " Current HTTP allows it, and we don't need to reject that mostly. (and saslprepbis's username acutally allows it except the last spaces.) > "=E2=99=96=E2=99=98=E2=99=97=E2=99=95=E2=99=94=E2=99=97=E2=99=98=E2=99=96= " (i.e., the back line of white chess pieces) I have a 50-50 feeling on this, little bit offseted to accept. It's really weired, *I* will never use this, but it's still harmless, I thi= nk. Someone may be using this as a funny identifier. I think I have to convince HTTP people that it's harmful. > "mycatisa bby" (where those spaces are actually a tab) I think this should be either rejected or replaced with a single space. The support: most text input field of modern applications accepts the top two, but for the last case some apps are rejecting TAB. At least, almost all applications explicitly filter CR and LF out. I think we can declare that "CR, LF, TAB, SHY and NBSP are harmful so we should handle it as a part of I18N string handling". It's the purpose of PRECIS, I agree. (and that's why I am strongly opposing against "just UTF-8" in HTTPAUTH WG)= . 2014-03-25 12:36 GMT+09:00 Peter Saint-Andre : > On 3/14/14, 8:48 PM, Yutaka OIWA wrote: >> >> Dear Peter and all PRECIS related members, >> >> Thank you very much, and I'm really sorry that our definition >> had a serious mistake which have confused many of you. >> I'll talk with co-authors (especially, Nemoto-san) again and >> revise the document as soon as possible, >> to restart the next steps as fast as possible. >> >> # That's why our specification has mentioned about >> # the mapping for spaces, which are not included by current definition. >> >> When I talked with Peter and Julian, we mentioned about >> another character classes during the talk, and at that time >> I should be noticed that I possibly referred the incorrect class. >> >>> A wider question: why do you think that the definition of an HTTP >>> username needs to be so loose? Do you define things this way to be >>> backward compatible with existing implementations, or do you really >>> think that this is a best practice? I'm truly curious. (And I wonder >>> if we even want to call this construct a "username"...) >> >> I think the reasons are both. >> >> 1: For backward compatibility, we need to keep all ASCII "printable" >> (U+0020 - U+007E, including SP) characters as is, as well as >> Latin-1 printable (U+00A1 - U+00FF, except SHY) be independent. > > > I think "saslprepbis" does this. > > >> 2: For more semantic reasons, HTTP authentication will be a vehicle >> for many different kinds of existing application frameworks, >> including >> IMs, Web mails, social network, and others. >> It should be able to accept all kinds of "user name" formats, >> for example a simple "user ID" (yoiwa), user "Name" (Yutaka OIWA), >> a mail address (y.oiwa@example.com), >> Social ID formats (@yoiwa or =3Dyoiwa), > > > Here again, I think that "saslprepbis" handles those. > >> and many others. > > > Here we might have some disagreement. > > If we think that http-auth needs to allow just about any string as a > "userid" (to use the term from RFC 2617 - I don't want to call it a > username), then even a PRECIS profile as loose as draft-ietf-precis-nickn= ame > is too strict for your purposes. > > However, I question whether those purposes are justified. > > Do we really expect that an actual userid in http-auth might be any of th= e > following? > > "Y u taka O i w a " > "=E2=99=96=E2=99=98=E2=99=97=E2=99=95=E2=99=94=E2=99=97=E2=99=98=E2=99=96= " (i.e., the back line of white chess pieces) > "mycatisa bby" (where those spaces are actually a tab) > > and so on. > > Do we have evidence from existing applications that we need to support > strings of characters like those as userids in HTTP authentication? Or ar= e > we being way too liberal in what we accept? > > >> Unlike SASL or XMPP which have its own semantics in framework, >> the authentication names in HTTP must be semanticless, >> unstructured strings, which can later be added a meaningful >> semantics for each application which uses Web/HTTP. >> >> We are not likely to correct all possible use cases of >> IDs which are to be used with HTTP (including future uses) and >> then take a union set of these, >> so instead we're defining a "grand-father" ID notations, >> expecting that all ID string use-cases are likely to be subsets of >> it. > > > My concern is that this "grandfather set" is every Unicode character, and= if > we allow that then we're really not providing any kind of helpful guidanc= e > to application developers. > > One fundamental assumption underlying the PRECIS work is that it is our > responsibility as internationalization experts to prevent application > developers from shooting themselves in the foot. In particular, the > IdentifierClass in the PRECIS framework tries to provide a safe subset of > characters, and the username construct in "saslprepbis" profiles the > IdentifierClass so that application developers can avoid trouble. As far = as > I can see, what you are proposing would invite such trouble, and I'm not > comfortable with that. > > >> At the same time, defining it just a "UTF-8" makes users' confusion >> and inter-operability mess about possible "visiblly-same" strings, >> so we must care about that side of string preparation with PRECIS. >> For example, NBSP and other spaces should be replaced. > > > Hmm. So you are saying that if a user inputs the following string: > > "Iam cey" > > Then " " would be replaced with U+0020 (SPACE) as follows: > > "Iam cey" > > "Just UTF-8" is just as useless for internationalization as "just TLS" is > for security. I definitely agree that we need something more than "just > UTF-8", which is why we've put so much work into PRECIS. Although we cann= ot > solve the problem of confusable characters, we can define some string > classes that "first do no harm" (is there a Hippocratic Oath for i18n?). = So > far, I do not think that what you are proposing does no harm, in fact I > think it is actively harmful to allow such a wide range of Unicode > characters into userids. > > Peter > --=20 Yutaka OIWA, Ph.D. Leader, System Life-cycle Research Group Research Institute for Secure Systems (RISEC= ) National Institute of Advanced Industrial Science and Technology (AIST= ) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5= ] From nobody Tue Mar 25 02:20:19 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3DE1A0369; Tue, 25 Mar 2014 02:20:17 -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 45EJUna95gEE; Tue, 25 Mar 2014 02:20:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBC61A03A3; Tue, 25 Mar 2014 02:20:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140325092014.24166.51076.idtracker@ietfa.amsl.com> Date: Tue, 25 Mar 2014 02:20:14 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/precis/6pjmly-EHIwoNrHcn_BC0cYmk1s Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-saslprepbis-07.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, 25 Mar 2014 09:20: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 and Comparison of Internationalized Strings Representing Usernames and Passwords Authors : Peter Saint-Andre Alexey Melnikov Filename : draft-ietf-precis-saslprepbis-07.txt Pages : 18 Date : 2014-03-24 Abstract: This document describes methods for handling Unicode strings representing usernames and passwords. This document obsoletes RFC 4013. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-saslprepbis-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 27 15:04:11 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43D6F1A03D1 for ; Thu, 27 Mar 2014 15:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 yMeYQ4DWImmt for ; Thu, 27 Mar 2014 15:03:57 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id ECA7D1A06F0 for ; Thu, 27 Mar 2014 15:03:56 -0700 (PDT) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BAFAF40352; Thu, 27 Mar 2014 16:03:53 -0600 (MDT) Message-ID: <5334A049.9070902@stpeter.im> Date: Thu, 27 Mar 2014 16:03:53 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Takahiro Nemoto , precis@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/ksnfI1mtU-2Sw4D8FW0CXG29-jk Subject: Re: [precis] proposed modifications of mappings document 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, 27 Mar 2014 22:04:03 -0000 On 3/23/14, 7:31 PM, Takahiro Nemoto wrote: > Dear all, > > I am trying to reflect comments from the discussion in a last WG in London. > I would like you to review the following modifications and give your comments/suggestions. > > Abstract & 1. Introduction > > OLD > > 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 alternative to > Unicode Default Case Folding as case mapping in the PRECIS framework. > > NEW > > 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 delimiter mapping and special mapping > rules described here are applied as "additional mappings" beyond those > defined in the PRECIS framework, whereas the "local case mapping" rule > is applied as an option of methods that handles some locale-dependent > and context-dependent mappings, which is the case mapping rule > specified in the PRECIS framework. I think this is a bit clearer: 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. One thing that I *thought* I heard in London is "the case mapping text in the framework document handles internationalization and the case mapping text in the mappings document handles localization". I tried to capture that in the framework with this text: Informational Note: Unicode Default Case Folding is not designed to handle various localization issues (such as so-called "dotless i" in several Turkic languages). The PRECIS mappings document [I-D.ietf-precis-mappings] describes these issues in greater detail and defines a "local case mapping" method that handles some locale-dependent and context-dependent mappings. Two questions: 1. Is that accurate? 2. Do we want to capture this in the mappings document as well? > 2.3. Local case mapping > > OLD > > If a codepoint is a target, the case folding method for the codepoint > is mapping into lower case as defined in SpecialCasing.txt. On the > other hand, if a codepoint is not a target, the case folding method > for the codepoint is the same with case mapping in PRECIS framework. > This local case mapping provides alternative case folding method to > Unicode Default Case Folding as case mapping in the PRECIS framework, > therefore if a PRECIS profile chooses local case mapping, it should > not choose case mapping. The reason for this is written in the > Appendix B. > > NEW > > The case folding method for a target character is to map into lower case > as defined in SpecialCasing.txt. The case folding method for all other, > non-target characters is as specified in Section 4.1.3 of the PRECIS > framework (i.e., Unicode Default Case Folding SHOULD be used for all > non-target characters). If an application supports users' locale and/or > context and gets them information from user input, local case mapping > can increase the probability of getting matching-results from the comparison > between strings. I would strike "and gets them information from user input" because I don't think that text adds anything to the sentence. > 3. Order of operations > > OLD > > The mappings described in this document are expected to be applied as > additional mappings and alternative to Unicode Default Case Folding > as case mapping in the PRECIS framework. The mappings described in > this document could be applied in any order. This section specifies > a particular order to minimize the effect of codepoint changes > introduced by the mappings. This mapping order is very general and > has been designed to be acceptable to the widest user community. > > NEW > > The mappings described in this document are expected to be applied as > additional mappings in the PRECIS framework. The mappings described in > this document could be applied in any order. This section specifies > a particular order to minimize the effect of codepoint changes > introduced by the mappings. This mapping order is very general and > has been designed to be acceptable to the widest user community. That looks fine to me. Thanks for working on this. Peter