From nobody Thu Mar 16 18:53:23 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33DED129BA0 for ; Thu, 16 Mar 2017 18:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=danieloaks-net.20150623.gappssmtp.com 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 RupY_1YnUvTR for ; Thu, 16 Mar 2017 18:53:19 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74DFC129BB3 for ; Thu, 16 Mar 2017 18:53:19 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id i34so52903081qtc.0 for ; Thu, 16 Mar 2017 18:53:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danieloaks-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=w6hEr8ptPAzIUU3HMZR1M9kxBNoJ/+ssaL9Yu5VOdRc=; b=tP1XSERnIQxAphCswGX+BbTp0anpREbK8Ac7+/hHWKxo6/yZmv+aG6kJI7TSC9Lhs9 9nEYmGm4Um/JC+JRDFYWjYFG/1zEvDBQY6lkNS3I/GbKG2T3nUPuAD0qFZ4H8vmwQ9+U QJUd5Pq05FkqIzAdn+Sv6L69LNfLcvtDDwj8HXavufk93PECex8aVRRHmbWGkRONCs6z 273CyE7eUo/6NCm+ZnCjggE6BIEkHPiKOKeVpmsD8639/s/Z6YNZsrWdM2SegQcCD8Vr Hujq2A+18K3/dWLtMVE64omAmZ1NqNVjfys4xIZL9mcT+FUBa0tf9l0Kr5D6udQMOgTq O6kA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=w6hEr8ptPAzIUU3HMZR1M9kxBNoJ/+ssaL9Yu5VOdRc=; b=GGjm7HKm6qG9rc1PWQq9nl4qkII7BJ+LJc/HVjEYly9WEVBeSYLC3NDip4mx3qiQ66 tzZrH2hVlZj3bxtOauO8F/Sm//MhKHLaP2Bbezb8iol8NCQJySPNwNc3iV68HPxvdO1z t19UsLcsM4/Yc7Bk5E4sPHoJuKU4n+9zadftl2hdpZYoCLNFfrtxpXuHmu7vKRJPxbv6 MFrxjbzMQsORiQj3IL4brBjklPQ+in3nmJ4WCxaIRIhmvxPyJdaRC5bhowQBK+0yYLbh wmBaFSqbLBMoXr1DgntHhYLaGUTPosnm3sNvJmECkw45aqKiY9HKqZZuSLIoGztIlQFN gxsQ== X-Gm-Message-State: AFeK/H0R7WcYa6JpA7fv96xnaycnUjftDZKO7t9RNL1ZjOXDcGwpY+K46uv0oj9OoYeX4KuZHXgLW3EWB+goyQ== X-Received: by 10.200.55.235 with SMTP id e40mr11179022qtc.251.1489715598349; Thu, 16 Mar 2017 18:53:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.35.2 with HTTP; Thu, 16 Mar 2017 18:52:57 -0700 (PDT) From: Daniel Oaks Date: Fri, 17 Mar 2017 11:52:57 +1000 Message-ID: To: precis@ietf.org Content-Type: multipart/alternative; boundary=001a113977dc0e6da8054ae371b0 Archived-At: Subject: [precis] Emoji, Names and Normalisation X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 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, 17 Mar 2017 01:53:21 -0000 --001a113977dc0e6da8054ae371b0 Content-Type: text/plain; charset=UTF-8 Hey everyone, I do work with the IRC chat protocol. Specifically, right now I'm doing work around allowing proper Unicode support, and writing the casefolding specs that would required to allow that. My current solution is based on PRECIS, but I'm running into an issue and not exactly sure how to solve it. Essentially, we need to casefold 'nicknames' (usernames that clients are referred to by), and for 'channel names' (chat room names). It would be much preferred to use an *IdentifierClass* profile. Using a single profile for both name types is also much preferred for reasons of implementation simplicity and for other protocol reasons (while we can have different ones for both if it's necessary, sticking to a single one would be much preferred). The only real profile out there which matches that description right now is UsernameCaseMapped, which while does everything we want to for nicknames, disallows emoji in channel names (which some services have already knowingly allowed). I haven't dived deep into Unicode and normalisation, but would there be a way for an *IdentifierClass* profile to allow and appropriately normalise emoji? If so, would the best thing for us to do here be to actually create our own profile for IRC (channel) names? I'm wary of doing so seeing the advice against profile proliferation here , but given the restriction it's difficult for us to adopt an *IdentifierClass* profile for this without creating our own. Any advice on what we should do here would be much appreciated. Thanks for the work you've all done so far! Regards, Daniel Oakley --001a113977dc0e6da8054ae371b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey everyone,

I do work with the IRC ch= at protocol. Specifically, right now I'm doing work around allowing pro= per Unicode support, and writing the casefolding specs that would required = to allow that.

My current solution is based on PRE= CIS, but I'm running into an issue and not exactly sure how to solve it= .

Essentially, we need to casefold 'nicknames&= #39; (usernames that clients are referred to by), and for 'channel name= s' (chat room names). It would be much preferred to use an Identifie= rClass profile. Using a single profile for both name types is also much= preferred for reasons of implementation simplicity and for other protocol = reasons (while we can have different ones for both if it's necessary, s= ticking to a single one would be much preferred).

= The only real profile out there which matches that description right now is= =C2=A0UsernameCaseMapped, which while does everything we = want to for nicknames, disallows emoji in channel names (which some service= s have already knowingly allowed).

I haven= 't dived deep into Unicode and normalisation, but would there be a way = for an IdentifierClass profile to allow and appropriately normalise = emoji? If so, would the best thing for us to do here be to actually create = our own profile for IRC (channel) names? I'm wary of doing so seeing th= e advice against profile proliferation here, but given the restriction it's diffic= ult for us to adopt an IdentifierClass profile for this without crea= ting our own.

Any advice on what we sho= uld do here would be much appreciated. Thanks for the work you've all d= one so far!

Regards,
Daniel Oakley
=
--001a113977dc0e6da8054ae371b0-- From nobody Sat Mar 18 13:08:09 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0BE12709D for ; Sat, 18 Mar 2017 13:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 nOZl9cBS-1MK for ; Sat, 18 Mar 2017 13:08:06 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35F2312942F for ; Sat, 18 Mar 2017 13:08:06 -0700 (PDT) Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1cpKdv-000EEE-Cd; Sat, 18 Mar 2017 16:08:03 -0400 Date: Sat, 18 Mar 2017 16:07:54 -0400 From: John C Klensin To: Daniel Oaks cc: precis@ietf.org Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.70 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [precis] Emoji, Names and Normalisation X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 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, 18 Mar 2017 20:08:09 -0000 Daniel, (top post) Two very quick comments/ suggestions: (1) You could do a lot worse than using a PRECIS IdentifierClass profile, if only because it would give you consistency with other applications based on IETF specs. Regardless of the number of things users and designers "want" (often including a plentiful supply of ponies), one thing I've learned from far more years of experience with users and user interfaces is that, in the last analysis, the dominant desire is for consistency and predictability. It also turns that that consistency and predictability makes things more secure, so that is a win across the board. Where possible, I also prefer to avoid case folding in identifiers. Yes, users "want" it and we generally assume that it is important, but remember that Unix and closely-related systems don't do that and most people stopped complaining years ago. Avoiding it gets more important with non-ASCII strings because there are some language and/or locality issues that lead, for a small number of edge cases, to behavior that users who haven't studied and accepted the rules think are inconsistent with their expectations. If you must do case conversions, UsernameCaseMapped is at least as good as anything else you might choose and has just about the same consistency properties as other standardized IdentifierClass profiles. (2) As much as people want them, emoji are really not suitable for use in identifiers. Maybe they will be some years from now but, at present, the names assigned by Unicode are not generally accepted and used, the icons used for a given one are significantly inconsistent across systems, there is no agreement about matching rules or normalization (especially in the context of modifiers), and so on. If you (or the IETF) were to invent emoji normalization, someone else (such as the Unicode Consortium, but they aren't the only candidate) may come along, create their own version, and _really_ confuse your users. FWIW, the Unicode Consortium seems to agree about unsuitability in identifiers -- some issues with domain names notwithstanding, their identifier recommendations (UAX #31: Unicode Identifier and Pattern Syntax) do not allow emoji in identifiers. This topic has been discussed extensively during the last few weeks on the IDNA-Update mailing list (archives at http://www.alvestrand.no/pipermail/idna-update/, at least for now). While parts of the discussion are specific to domain names, you can learn a lot more there if you are curious. john --On Friday, March 17, 2017 11:52 +1000 Daniel Oaks wrote: > Hey everyone, > > I do work with the IRC chat protocol. Specifically, right now > I'm doing work around allowing proper Unicode support, and > writing the casefolding specs that would required to allow > that. > > My current solution is based on PRECIS, but I'm running into > an issue and not exactly sure how to solve it. > > Essentially, we need to casefold 'nicknames' (usernames that > clients are referred to by), and for 'channel names' (chat > room names). It would be much preferred to use an > *IdentifierClass* profile. Using a single profile for both > name types is also much preferred for reasons of implementation > simplicity and for other protocol reasons (while we can have > different ones for both if it's necessary, sticking to a > single one would be much preferred). > > The only real profile out there which matches that description > right now is UsernameCaseMapped, which while does everything > we want to for nicknames, disallows emoji in channel names > (which some services have already knowingly allowed). > > I haven't dived deep into Unicode and normalisation, but would > there be a way for an *IdentifierClass* profile to allow and > appropriately normalise emoji? If so, would the best thing for > us to do here be to actually create our own profile for IRC > (channel) names? I'm wary of doing so seeing the advice > against profile proliferation here > , but given > the restriction it's difficult for us to adopt an > *IdentifierClass* profile for this without creating our own. > > Any advice on what we should do here would be much > appreciated. Thanks for the work you've all done so far! > > Regards, > Daniel Oakley From nobody Sun Mar 19 03:26:59 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 487DB120724 for ; Sun, 19 Mar 2017 03:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=danieloaks-net.20150623.gappssmtp.com 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 rfYgHgfrJD-0 for ; Sun, 19 Mar 2017 03:26:55 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AC65126C7A for ; Sun, 19 Mar 2017 03:26:53 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id y76so92190603qkb.0 for ; Sun, 19 Mar 2017 03:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danieloaks-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GeiGa/yjLDtfQea57MCFX7QaPxVfl5GUqOlaQEyCAeQ=; b=azutvZLhCdSgEL0VENP2UMWW9BQU+d4gedEoTImbGLdjXWJJsWfityuicdGlgD4qFs VKO1z0WVyo9+rcv5zNR0xBD2NNPQBrxDrphBczJha2sHy+8JDFkOe/aGf1zTa6WumuTI 352yBCm6S5x7mb5fFAkKl01tpKv9fTTx/SHa9Zr2oNx90tJhGf9aK8HzbSz0bQaybZpp P9NbC4dWb4o5Tpkl6Mqy4WM3HWTQ14q9iZD7knvHTJ+TnJl5lG1x/yBFZSj9NvBXN1oS Wu0AdUnLhZJn1hkHrcbKmIW99lRvjZgf+X7xucYcbuEpba8hRkA4VSdox2m/v4yfnRei 37cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GeiGa/yjLDtfQea57MCFX7QaPxVfl5GUqOlaQEyCAeQ=; b=luJbGwgmmjUfZGoab7iZibOf1whDdatvP9uH9t4fxRDtRdtuzX6cTNX2N6hKan8JkR RyRfhQ7miWBc+wCyCLtgFapwvna2Su+K3Gx3g7uTw+Gm5L85IkLj7IRtn1b/LFi32ndK 7kioFYeGrKUwb1XNJc4inAkDjEfwBFXtr3dvvxyhtEELl9IAddbhgg/O0pv5ezf3jM4N EZ3iAVyTKcwRTrBl16mNqZdvRpmJkFhox2UEP78Jm3vOas5BPCVUJuzPAjJ2IV9ZU82o LRaAyVrMIt5LFTdhMeq3aLn1Iei6rlYT9uPPqMxPW7mlTgkV7+NC9wNOU14UW+sfdsqc RL3Q== X-Gm-Message-State: AFeK/H3rG+4qx8jdgloE4NOI2Lv7DeCumt2fzyjgx8fE1aSVmTtsXh5Gcr7etpPnJyFiPebd/D/IzHfNkfNHEw== X-Received: by 10.55.41.16 with SMTP id p16mr19375676qkh.321.1489919212200; Sun, 19 Mar 2017 03:26:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.35.2 with HTTP; Sun, 19 Mar 2017 03:26:31 -0700 (PDT) In-Reply-To: References: From: Daniel Oaks Date: Sun, 19 Mar 2017 20:26:31 +1000 Message-ID: To: John C Klensin Cc: precis@ietf.org Content-Type: multipart/alternative; boundary=001a1140572663374e054b12d905 Archived-At: Subject: Re: [precis] Emoji, Names and Normalisation X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 10:26:58 -0000 --001a1140572663374e054b12d905 Content-Type: text/plain; charset=UTF-8 Hi John, Thanks very much for your comments. I can definitely see what you mean regarding the issues surrounding casefolding emoji -- thanks for spelling them out so clearly and providing the relevant links, I've certainly got some reading to do. Regardless of emoji, the expanded range of characters we can use thanks to adopting an IdentifierClass profile makes it more than worthwhile anyways. Looking at the issues surrounding this, I'll likely go forward with the UsernameCaseMapped profile for this. All else fails, later on if/when a consistent strategy is adopted across the industry for casefolding emoji we can always revisit this. Your point about case conversions I can understand, particularly in newer systems with the sort of audience that'd expect that. In this particular protocol, not doing case conversion would go against many years of established behaviour for both software and users so we'll probably stick with the folding for now. However, I appreciate the view and I'll definitely keep it in mind going forward. Thanks again for your reply, I have a much clearer idea of where to go with this. Regards, Daniel Oakley On 19 March 2017 at 06:07, John C Klensin wrote: > Daniel, > > (top post) > > Two very quick comments/ suggestions: > > (1) You could do a lot worse than using a PRECIS IdentifierClass > profile, if only because it would give you consistency with > other applications based on IETF specs. Regardless of the number > of things users and designers "want" (often including a > plentiful supply of ponies), one thing I've learned from far > more years of experience with users and user interfaces is that, > in the last analysis, the dominant desire is for consistency and > predictability. It also turns that that consistency and > predictability makes things more secure, so that is a win across > the board. > > Where possible, I also prefer to avoid case folding in > identifiers. Yes, users "want" it and we generally assume that > it is important, but remember that Unix and closely-related > systems don't do that and most people stopped complaining years > ago. Avoiding it gets more important with non-ASCII strings > because there are some language and/or locality issues that > lead, for a small number of edge cases, to behavior that users > who haven't studied and accepted the rules think are > inconsistent with their expectations. If you must do case > conversions, UsernameCaseMapped is at least as good as anything > else you might choose and has just about the same consistency > properties as other standardized IdentifierClass profiles. > > (2) As much as people want them, emoji are really not suitable > for use in identifiers. Maybe they will be some years from now > but, at present, the names assigned by Unicode are not generally > accepted and used, the icons used for a given one are > significantly inconsistent across systems, there is no agreement > about matching rules or normalization (especially in the context > of modifiers), and so on. If you (or the IETF) were to invent > emoji normalization, someone else (such as the Unicode > Consortium, but they aren't the only candidate) may come along, > create their own version, and _really_ confuse your users. > FWIW, the Unicode Consortium seems to agree about unsuitability > in identifiers -- some issues with domain names notwithstanding, > their identifier recommendations (UAX #31: Unicode Identifier > and Pattern Syntax) do not allow emoji in identifiers. > > This topic has been discussed extensively during the last few > weeks on the IDNA-Update mailing list (archives at > http://www.alvestrand.no/pipermail/idna-update/, at least for > now). While parts of the discussion are specific to domain > names, you can learn a lot more there if you are curious. > > john > > > > > --On Friday, March 17, 2017 11:52 +1000 Daniel Oaks > wrote: > > > Hey everyone, > > > > I do work with the IRC chat protocol. Specifically, right now > > I'm doing work around allowing proper Unicode support, and > > writing the casefolding specs that would required to allow > > that. > > > > My current solution is based on PRECIS, but I'm running into > > an issue and not exactly sure how to solve it. > > > > Essentially, we need to casefold 'nicknames' (usernames that > > clients are referred to by), and for 'channel names' (chat > > room names). It would be much preferred to use an > > *IdentifierClass* profile. Using a single profile for both > > name types is also much preferred for reasons of implementation > > simplicity and for other protocol reasons (while we can have > > different ones for both if it's necessary, sticking to a > > single one would be much preferred). > > > > The only real profile out there which matches that description > > right now is UsernameCaseMapped, which while does everything > > we want to for nicknames, disallows emoji in channel names > > (which some services have already knowingly allowed). > > > > I haven't dived deep into Unicode and normalisation, but would > > there be a way for an *IdentifierClass* profile to allow and > > appropriately normalise emoji? If so, would the best thing for > > us to do here be to actually create our own profile for IRC > > (channel) names? I'm wary of doing so seeing the advice > > against profile proliferation here > > , but given > > the restriction it's difficult for us to adopt an > > *IdentifierClass* profile for this without creating our own. > > > > Any advice on what we should do here would be much > > appreciated. Thanks for the work you've all done so far! > > > > Regards, > > Daniel Oakley > > > > > --001a1140572663374e054b12d905 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi John,

T= hanks very much for your comments.

I can definitely see what y= ou mean regarding the issues surrounding casefolding emoji -- thanks for sp= elling them out so clearly and providing the relevant links, I've certa= inly got some reading to do.

Regardless of emoji, the expanded= range of characters we can use thanks to adopting an IdentifierClass profi= le makes it more than worthwhile anyways. Looking at the issues surrounding= this, I'll likely go forward with the UsernameCaseMapped profile for t= his. All else fails, later on if/when a consistent strategy is adopted acro= ss the industry for casefolding emoji we can always revisit this.

Your point about case conversions I can understand, particularly in new= er systems with the sort of audience that'd expect that. In this partic= ular protocol, not doing case conversion would go against many years of est= ablished behaviour for both software and users so we'll probably stick = with the folding for now. However, I appreciate the view and I'll defin= itely keep it in mind going forward.

Thanks again for your rep= ly, I have a much clearer idea of where to go with this.

Regar= ds,
Daniel Oakley

On 19 March 2017 at 06:07, John C Klensin <john-ietf@jc= k.com> wrote:
Daniel,

(top post)

Two very quick comments/ suggestions:

(1) You could do a lot worse than using a PRECIS IdentifierClass
profile, if only because it would give you consistency with
other applications based on IETF specs. Regardless of the number
of things users and designers "want" (often including a
plentiful supply of ponies), one thing I've learned from far
more years of experience with users and user interfaces is that,
in the last analysis, the dominant desire is for consistency and
predictability.=C2=A0 It also turns that that consistency and
predictability makes things more secure, so that is a win across
the board.

Where possible, I also prefer to avoid case folding in
identifiers.=C2=A0 Yes, users "want" it and we generally assume t= hat
it is important, but remember that Unix and closely-related
systems don't do that and most people stopped complaining years
ago.=C2=A0 Avoiding it gets more important with non-ASCII strings
because there are some language and/or locality issues that
lead, for a small number of edge cases, to behavior that users
who haven't studied and accepted the rules think are
inconsistent with their expectations.=C2=A0 =C2=A0If you must do case
conversions, UsernameCaseMapped is at least as good as anything
else you might choose and has just about the same consistency
properties as other standardized IdentifierClass profiles.

(2) As much as people want them, emoji are really not suitable
for use in identifiers.=C2=A0 =C2=A0Maybe they will be some years from now<= br> but, at present, the names assigned by Unicode are not generally
accepted and used, the icons used for a given one are
significantly inconsistent across systems, there is no agreement
about matching rules or normalization (especially in the context
of modifiers), and so on.=C2=A0 If you (or the IETF) were to invent
emoji normalization, someone else (such as the Unicode
Consortium, but they aren't the only candidate) may come along,
create their own version, and _really_ confuse your users.
FWIW, the Unicode Consortium seems to agree about unsuitability
in identifiers -- some issues with domain names notwithstanding,
their identifier recommendations (UAX #31: Unicode Identifier
and Pattern Syntax) do not allow emoji in identifiers.

This topic has been discussed extensively during the last few
weeks on the IDNA-Update mailing list (archives at
http://www.alvestrand.no/pipermail/idna-update/<= /a>, at least for
now).=C2=A0 While parts of the discussion are specific to domain
names, you can learn a lot more there if you are curious.

=C2=A0 =C2=A0 john




--On Friday, March 17, 2017 11:52 +1000 Daniel Oaks
<daniel@daniel= oaks.net> wrote:

> Hey everyone,
>
> I do work with the IRC chat protocol. Specifically, right now
> I'm doing work around allowing proper Unicode support, and
> writing the casefolding specs that would required to allow
> that.
>
> My current solution is based on PRECIS, but I'm running into
> an issue and not exactly sure how to solve it.
>
> Essentially, we need to casefold 'nicknames' (usernames that > clients are referred to by), and for 'channel names' (chat
> room names). It would be much preferred to use an
> *IdentifierClass* profile. Using a single profile for both
> name types is also much preferred for reasons of impl= ementation
> simplicity and for other protocol reasons (while we can have
> different ones for both if it's necessary, sticking to a
> single one would be much preferred).
>
> The only real profile out there which matches that description
> right now is UsernameCaseMapped, which while does everything
> we want to for nicknames, disallows emoji in channel names
> (which some services have already knowingly allowed).
>
> I haven't dived deep into Unicode and normalisation, but would
> there be a way for an *IdentifierClass* profile to allow and > appropriately normalise emoji? If so, would the best = thing for
> us to do here be to actually create our own profile for IRC
> (channel) names? I'm wary of doing so seeing the advice
> against profile proliferation here
> <https://tools.ietf.org/html/rfc7= 564#section-5.1>, but given
> the restriction it's difficult for us to adopt an=
> *IdentifierClass* profile for this without creating our own.
>
> Any advice on what we should do here would be much
> appreciated. Thanks for the work you've all done so far!
>
> Regards,
> Daniel Oakley





--001a1140572663374e054b12d905-- From nobody Tue Mar 21 09:18:12 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 013CD129B74 for ; Tue, 21 Mar 2017 09:17:54 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=f+lzl/QT; dkim=pass (1024-bit key) header.d=yitter.info header.b=KmVA20nq 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 F2y43wwrWYmU for ; Tue, 21 Mar 2017 09:17:51 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C9A8129B77 for ; Tue, 21 Mar 2017 09:17:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 8CE13BB807 for ; Tue, 21 Mar 2017 16:17:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1490113041; bh=zS+5fj/08nZ2zuLC90MVB7eHwEJ0/Wrh4cR1tQI7FPk=; h=Date:From:To:Subject:References:In-Reply-To:From; b=f+lzl/QTYpOLyoiJQaOMnEkE5NrFqeJ6N9Ytfj8bCpVP65CHNlP3jnVQCrsnn5uuo arJ4BdUUinYqJuygECrW95HwtUvfr0hxP/36ZpkFOWCvrBpzUzkHJDuxiBeAIjRqfK /4sJKGgVDZRxOtumZHzwcDgs1vc/r2dkz6hdySBs= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0kZ-o5Xp8By for ; Tue, 21 Mar 2017 16:17:20 +0000 (UTC) Date: Tue, 21 Mar 2017 12:17:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1490113040; bh=zS+5fj/08nZ2zuLC90MVB7eHwEJ0/Wrh4cR1tQI7FPk=; h=Date:From:To:Subject:References:In-Reply-To:From; b=KmVA20nqBPI4NB8FrCEItIWMcWyLxdiwWRe5yhNvmmpoGR52i13tiQrFGa9LK72RZ 0ZXMMdTGCizvdbxZeDN6dYu/uEvt8ZASOKuidobipqVWSKlA85gUjab2nrKIcljb2i jjnaJc1e1TP5fHnlhnDDm1q51BkStAylwOrH35dQ= From: Andrew Sullivan To: precis@ietf.org Message-ID: <20170321161718.GN27276@mx4.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [precis] Emoji, Names and Normalisation X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 16:17:54 -0000 On Fri, Mar 17, 2017 at 11:52:57AM +1000, Daniel Oaks wrote: > way for an *IdentifierClass* profile to allow and appropriately normalise > emoji? The basic problem is that emoji are not letters, but are symbols. So they don't have a normalization form. I do hope UTC takes up this problem soon. But I suspect your only hope right now is to create a profile that permits emoji, while yet noting that because of the lack of normalization rules you're going to have troubles if you use them. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Mar 21 18:30:07 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7D1129415 for ; Tue, 21 Mar 2017 18:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=cJ+/E88h; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=OFmtb2G+ 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 1m4chMDf8L9F for ; Tue, 21 Mar 2017 18:30:04 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7C031292F4 for ; Tue, 21 Mar 2017 18:30:04 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 25ADA20BA2; Tue, 21 Mar 2017 21:30:04 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Tue, 21 Mar 2017 21:30:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=FFCWGVYjkYEBhACeOB ZOEimLjbPFNORI0uzxuGgKUv0=; b=cJ+/E88hFByjLcSy/ZhitBYM/AWRepvSX9 bXCHf0QIeWiyeMBObWOFnNyQA96oa10E9tnGYP/pP8rTm37kRDjyMuX+Y8KRTcGl pizz3ctcWH8CYa3jdXEBs7S1ticDrQNy3EeFT35bVVz4lop9GdKjVytfAqL6txVu pFm5XUEHKw35g/ANyx75cgBDcNC89qUdokXg+oDE1nH6ZWHxZkzmRkMUN9NGHQoo D0yZgEa/xXDkK2DZw2R+1onzjy6zcp+5Nvsl4waAmy32q0WmrgGWVH+KKeFrtSpI R0/GBFdGKgFA9vTgiKE6qe3v3HWhHUUxfoSrRZvqJhCHKCWHT89g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=FFCWGVYjkYEBhACeOBZOEimLjbPFNORI0uzxuGgKUv0=; b=OFmtb2G+ R2IbPqq3ZZe7pR/yicet9vTdKpzH2qFlXXaMg01M5PyxQxOjWa6gqLbj76CvV5NG FJHoUawWB63VgMwIyHFrcq4ekpeET86wtvUsWopFNnP5wG3lMsEVaKvPbmzMq4Kg Cf0evp4QOBxDCxtytGXyFtaCK99D1q8wuE1tgWi4aYS5ClL1y6JxylSTA9vQOn4X v1Zv0dV5VF7uoRmj2GY7UO6qGD0gVgKFFDmUSy87nQJkbU4oHPF59azOUEtiFQv/ S9bc3eJ1RuphqVZc9HicsULhGQDcseAneBfFSttbNvqQZzag0FzMIlIPGxRCzACQ Xdmq//kflqNJww== X-ME-Sender: X-Sasl-enc: 4wdbMZEjhjBGkCN2FpcK0UOGdB3MuaCHtPkWK+kQqo89 1490146203 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id ACBDD7E65A; Tue, 21 Mar 2017 21:30:03 -0400 (EDT) To: William Fisher References: <15c31273-c278-af61-2a01-0b68ab8af182@stpeter.im> <0f5b55f8-5fcb-2a61-435e-7b93d2d8f9e6@stpeter.im> Cc: precis@ietf.org From: Peter Saint-Andre Message-ID: <6df28263-cdfa-cc61-4ba9-1bdae17bcca8@stpeter.im> Date: Tue, 21 Mar 2017 19:30:02 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <0f5b55f8-5fcb-2a61-435e-7b93d2d8f9e6@stpeter.im> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [precis] Enforcement as an Idempotent operation X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 01:30:06 -0000 On 2/26/17 5:48 PM, Peter Saint-Andre wrote: > On 2/13/17 12:04 AM, William Fisher wrote: >> On Sun, Feb 12, 2017 at 12:27 PM, Peter Saint-Andre wrote: >>> Did you mean U+212A (KELVIN SIGN)? That decomposes to U+004B (LATIN CAPITAL >>> LETTER K). >>> >>>> The full example is: >>>> "\U0001f11aevin" => "(K)evin" => "(k)evin" >> >> I'm talking about 'PARENTHESIZED LATIN CAPITAL LETTER K' (U+1F11A). >> Sorry it's not clear that the A is part of the unicode escape. > > Thanks for the clarification. > >> With casefold or tolower, the result is the same for these Nicknames: >> >> Not idempotent: "\U0001f11A" => "(K)" => "(k)" >> Not idempotent: "\U0001f13A" => "K" => "k" >> Not idempotent: "\u210c" => "H" => "h" >> Not idempotent: "\u210d" => "H" => "h" >> Not idempotent: "\u20a8" => "Rs" => "rs" >> >> When you apply the comparison steps from RFC 7700, Section 2.4, you >> still get something that is upper case. If you apply the comparison >> steps again, you now get lower case. > > I see what you mean. I'm now leaning toward moving the case mapping rule > after the normalization rule, but first I want to think about the > implications for all of the PRECIS profiles (e.g., when using NFC vs. > using NFKC). If we go down this road, we will also want to describe the > reasoning in Section 5.2.3 of 7564bis. Thinking about this further, I now lean against making this change in the PRECIS processing rules, for several reasons: 1. Existing PRECIS implementations would need to be modified, resulting in a behavioral difference between older and newer implementations (or older and newer versions of the same implementation). 2. The order of operations in PRECIS was intended to be consistent with IDNA2008 (in which case mapping is performed before normalization, albeit in the application before the protocol is invoked), and with IDNA2003 and Stringprep prior to IDNA2008 (note also that several PRECIS profiles were designed as modernized replacements for Stringprep profiles). Making PRECIS inconsistent with IDNA might make it harder to reuse code and might lead to unexpected and undesirable consequences. 3. Idempotence, although a desirable quality, in my opinion falls into the category of "nice but not necessary". (If we were designing PRECIS anew, my opinion might be different.) A safer approach would be to add an implementation note to the effect that PRECIS processing might not be idempotent, and that implementations might need to apply the rules more than once to the same string. Peter From nobody Thu Mar 23 12:46:05 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91BC3131597 for ; Thu, 23 Mar 2017 12:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 kecNOBLFlT0Y for ; Thu, 23 Mar 2017 12:46:03 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFD7F129BCB for ; Thu, 23 Mar 2017 12:46:01 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id 190so4005720itm.0 for ; Thu, 23 Mar 2017 12:46:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NzSDYcK5wUBrqCCtuI7gT10s6BYXl8Xo7NwC8Scb27Q=; b=HDrdmyQeZyiW/c/GPAYU/A6BW+o43Try1FzGS6RpuGYWuLSn6S1E9BFwSVeI1mag/h uXQnPZspVZMtY9OFFYTi0vTxi4MeAzubGhinpih80Ma+YGXw6u/W2mBN3RnlfHhJmyGQ Itpc71+jAw9dUfm6EeHUXWhocjNy37l3AYUutESlqDg9ZhRpcjRmY9nNB5U/K3ckb5Lc VQ3lEzK3k+b6PE+fTBYHUUlLEUD4OMpQ+vfjRgAe4NysGEbSebjd/r7N+U59k5oP89ay iOGdSixI9rJv4xOa7kj9zWHMFctY+YbIwcsbuoeOL0OZ6qS55E61shjd1j2/UOJYxVOL hiYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NzSDYcK5wUBrqCCtuI7gT10s6BYXl8Xo7NwC8Scb27Q=; b=SUt9LQLjGvao8pH2MBzN6Yl1bbvSn1q7bed7s4+lOXTIJiHVtWwgTB09iWd12r7Nsu aPdy1DEjihzVkEHapRUek9UlxH86quvfxEF8VXNG+FpKVPK9v93Ka8YWwk/BZLPg+IrX 4bnRTxW64jHH9LP7QxAWcrYuEDTKSwwVjfmvrKpWQh1Q2EGCCwyAOeqUnLbjkuAFPha7 fe7Powu1rwbsvhidz6S+nU1CfRV7Ue4I5NSth4LQ/c28R0e4T945IiSQlvb+XgLukMtx 5DSKjcLFdYzRXifbHJnpLqx2VFCHE0ZZg0afiRzZavGQA6fNeZDX9ppSmgjdXf4LJAa8 ri7A== X-Gm-Message-State: AFeK/H2JDMK4wsksK5uKczzoXv95TlJAjehhhn08RwRdMruDb1dmtcEmzgoRl1R4YJUFWWIg6u1mJRf4ABqkkQ== X-Received: by 10.36.224.136 with SMTP id c130mr4588876ith.57.1490298361243; Thu, 23 Mar 2017 12:46:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.12.213 with HTTP; Thu, 23 Mar 2017 12:46:00 -0700 (PDT) In-Reply-To: <6df28263-cdfa-cc61-4ba9-1bdae17bcca8@stpeter.im> References: <15c31273-c278-af61-2a01-0b68ab8af182@stpeter.im> <0f5b55f8-5fcb-2a61-435e-7b93d2d8f9e6@stpeter.im> <6df28263-cdfa-cc61-4ba9-1bdae17bcca8@stpeter.im> From: William Fisher Date: Thu, 23 Mar 2017 12:46:00 -0700 Message-ID: To: Peter Saint-Andre Cc: precis@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [precis] Enforcement as an Idempotent operation X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 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, 23 Mar 2017 19:46:05 -0000 I agree with the "implementation note" strategy. In all my testing, only the "Nickname" profile can fail to be idempotent for some inputs. I have not found any inputs that fail the idempotent test using the Username or OpaqueString profiles. I believe "Nickname" has problems because it uses NFKC. I would add an implementation note/warning to the Nickname profile. Thanks, Bill On Tue, Mar 21, 2017 at 6:30 PM, Peter Saint-Andre wrote: > Thinking about this further, I now lean against making this change in > the PRECIS processing rules, for several reasons: > > 1. Existing PRECIS implementations would need to be modified, resulting > in a behavioral difference between older and newer implementations (or > older and newer versions of the same implementation). > > 2. The order of operations in PRECIS was intended to be consistent with > IDNA2008 (in which case mapping is performed before normalization, > albeit in the application before the protocol is invoked), and with > IDNA2003 and Stringprep prior to IDNA2008 (note also that several PRECIS > profiles were designed as modernized replacements for Stringprep > profiles). Making PRECIS inconsistent with IDNA might make it harder to > reuse code and might lead to unexpected and undesirable consequences. > > 3. Idempotence, although a desirable quality, in my opinion falls into > the category of "nice but not necessary". (If we were designing PRECIS > anew, my opinion might be different.) > > A safer approach would be to add an implementation note to the effect > that PRECIS processing might not be idempotent, and that implementations > might need to apply the rules more than once to the same string. > > Peter > From nobody Thu Mar 23 16:52:15 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B89C128CFF for ; Thu, 23 Mar 2017 16:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=jkMqVUhv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=krG9xuib 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 rfhIfJMsOuhy for ; Thu, 23 Mar 2017 16:52:12 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C050129516 for ; Thu, 23 Mar 2017 16:52:12 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id D26882091B; Thu, 23 Mar 2017 19:52:11 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 23 Mar 2017 19:52:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=ycQ+WuqJd2xb3RauLE 7AoVcZTPnSN8bbPNrJjUup0iI=; b=jkMqVUhvnO+Oye22nBKl674NgiLhBz7qMt tZzgbRyAWTNIKFXBXEAKZjOcviDrheeb07Y5ZTuYm1Jz8GITjAtiLCaPEE7nhPs1 LAteap6r59qe1vokUSeq0KMFlZ7L0bI9R7QGwDxlcDhw3kwcgVmkOK1UwM+OhW3W PYSefS6nzewfXCmT2trSKv8JsJSWi7XaSl+6F2WmGOvE1883h9ZXwfxnYysVyVcS fB+3+QJfYcMzjAkNq79SLwjWn7Pu6XWOl2kxralDUM2wrsjntc/l5gamm5Ee+ol2 Jx7Bsx9FMurqSTm9N93/RSVa2hUbDPp0dtI91YhUHujWMquo5PPA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=ycQ+WuqJd2xb3RauLE7AoVcZTPnSN8bbPNrJjUup0iI=; b=krG9xuib UDat0dEUyHAhanjicgPWCDQJEsthC5wQ3K3/NtjolUmkQxmtWLRYHpknQps4vnR+ nUhR5DwCcHLsbopMs5QRxRDKjNO+czmeifZVFCtE4HqD2pescsqIb8iOb1K8Mych 1cYE+sqBBIGAiYhKOA2Sm3OfnEvFR2swJO5P7L7BgxhlhxpWD0ZBEzme4XeYqnq9 UYwPc6x6zFh3DumjLB5hm2bay6JhyGh1yCZQD5xz23CFt1Yz0JqCsghKitVCkRB6 3KUGQZ/1TCtzDZz/WKUnF5/WZKCMnxZfGVocYrc86TZnkbSnZ5qhb5jGUdVUmyCL tXqWIy1VTE0UGw== X-ME-Sender: X-Sasl-enc: G5sTAe5dtkjaDpm1QLCz6/8mVQ0zyPI2Ekyr4ZN9mvwR 1490313131 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 607297E202; Thu, 23 Mar 2017 19:52:11 -0400 (EDT) To: William Fisher References: <15c31273-c278-af61-2a01-0b68ab8af182@stpeter.im> <0f5b55f8-5fcb-2a61-435e-7b93d2d8f9e6@stpeter.im> <6df28263-cdfa-cc61-4ba9-1bdae17bcca8@stpeter.im> Cc: precis@ietf.org From: Peter Saint-Andre Message-ID: Date: Thu, 23 Mar 2017 17:52:04 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [precis] Enforcement as an Idempotent operation X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 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, 23 Mar 2017 23:52:14 -0000 On 3/23/17 1:46 PM, William Fisher wrote: > I agree with the "implementation note" strategy. In all my testing, > only the "Nickname" profile can fail to be idempotent for some inputs. > I have not found any inputs that fail the idempotent test using the > Username or OpaqueString profiles. I believe "Nickname" has problems > because it uses NFKC. I would add an implementation note/warning to > the Nickname profile. Hi Bill, thanks for your feedback. I propose the following text. 1. At the end of Section 7 ("Order of Operations") of 7564bis, add this note: Because of the order of operations specified here, applying the rules for any given PRECIS profile is not necessarily an idempotent procedure (e.g., under certain circumstances, such as when Unicode normalization form KC is used, performing Unicode normalization after case mapping can still yield uppercase characters for certain code points); therefore, implementations might need to apply the rules more than once to an internationalized string. 2. At the end of Section 4 ("Use in Application Protocols") of 7700bis, add this note: Implementation experience has shown that applying the rules for the Nickname profile is not an idempotent procedure for all code points. Therefore, implementations might need to apply the rules more than once to a nickname string. 3. I see no harm in also adding the following note to the end of Section 5 ("Use in Application Protocols") of 7613bis: Applying the rules for any given PRECIS profile is not necessarily an idempotent procedure for all code points. Therefore, implementations might need to apply the rules more than once to an internationalized string. Peter From nobody Fri Mar 24 11:40:34 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71DA81292F5 for ; Fri, 24 Mar 2017 11:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 veOIWTZFhFYu for ; Fri, 24 Mar 2017 11:40:30 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76554126C2F for ; Fri, 24 Mar 2017 11:40:30 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id y18so7073484itc.1 for ; Fri, 24 Mar 2017 11:40:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UtnDdo/BMYTzLPWTeox+5Scet9MJjDx5Cge6uaDEbkQ=; b=dGbUk7qIzuwCHsYXA4rU7J8xigAUPPl2rqfNfhi8U0a6CmsYbaQeSG8YnnHPsyNyok XXoGZImJzUG09d0LrJRG05E3wASmxJT47gK3+KIUJj1bD05hobmy7VGhoE/kZ9alylKS BX5LW1BUmSlZWy3aAntr6KrabVae81QzgJN84R0FOA+PZtciXUzKEV/VCcXu1+YzHwCS pPV5tGY/BvtulPrczjduaVOuzJFmOA1H50cd7QnY75HrVCYj2/nszOLnQXSFbMREAinL P4zmgJCuacbRO0ZB2C7CKKLB4uM5FBIptPKPrsjf430LFWUt4AnXx88Oh+Arc+lK7Qsh ywtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UtnDdo/BMYTzLPWTeox+5Scet9MJjDx5Cge6uaDEbkQ=; b=iKWlE3EQbCy+JM+AR8oXnBf6hrAdHIiiHki7lZ0094AZ1evxfOkLEKFpea2hwLXyT9 RcXljN80XwoCq3oLuMxvpkkenVfubejkcqYIhlpOB3/4u/rhs7XlVFUld7SOoJSPJ6pZ 1bnTN/fSBVWf+f6Gi7VSqoXFGBkUFLgNjyg6rzkFkQ44lnCn28AJp9Jwn5MTsPbmDsHZ pK2/Ewvy18wVKTSrYe7mVlwq/RDOnRclWLJiEJemqN5gHfz9T8IVpdiskjt0ztx2DmaS W/44Ds9JH/qJ5ZgQ9air3HXVIqh4uPwfbGVaDQ7Pgv74vAkRQ8DkJC9CJlVgSqUUU/Fm 8M9g== X-Gm-Message-State: AFeK/H1sdfSCeGSA2RScyP273FgxA/OANFzBRs8FJdjGUiTGldEJx/kDRT9Tp2TqErhZb1ahIvEp8YkiY1sUFg== X-Received: by 10.36.77.10 with SMTP id l10mr4355844itb.59.1490380829632; Fri, 24 Mar 2017 11:40:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.12.213 with HTTP; Fri, 24 Mar 2017 11:40:29 -0700 (PDT) In-Reply-To: References: <15c31273-c278-af61-2a01-0b68ab8af182@stpeter.im> <0f5b55f8-5fcb-2a61-435e-7b93d2d8f9e6@stpeter.im> <6df28263-cdfa-cc61-4ba9-1bdae17bcca8@stpeter.im> From: William Fisher Date: Fri, 24 Mar 2017 11:40:29 -0700 Message-ID: To: Peter Saint-Andre Cc: precis@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [precis] Enforcement as an Idempotent operation X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 18:40:32 -0000 Looks good to me. -Bill On Thu, Mar 23, 2017 at 4:52 PM, Peter Saint-Andre wrote: > On 3/23/17 1:46 PM, William Fisher wrote: >> I agree with the "implementation note" strategy. In all my testing, >> only the "Nickname" profile can fail to be idempotent for some inputs. >> I have not found any inputs that fail the idempotent test using the >> Username or OpaqueString profiles. I believe "Nickname" has problems >> because it uses NFKC. I would add an implementation note/warning to >> the Nickname profile. > > Hi Bill, thanks for your feedback. I propose the following text. > > 1. At the end of Section 7 ("Order of Operations") of 7564bis, add this > note: > > Because of the order of operations specified here, applying the rules > for any given PRECIS profile is not necessarily an idempotent > procedure (e.g., under certain circumstances, such as when Unicode > normalization form KC is used, performing Unicode normalization after > case mapping can still yield uppercase characters for certain code > points); therefore, implementations might need to apply the rules > more than once to an internationalized string. > > 2. At the end of Section 4 ("Use in Application Protocols") of 7700bis, > add this note: > > Implementation experience has shown that applying the rules for the > Nickname profile is not an idempotent procedure for all code points. > Therefore, implementations might need to apply the rules more than > once to a nickname string. > > 3. I see no harm in also adding the following note to the end of Section > 5 ("Use in Application Protocols") of 7613bis: > > Applying the rules for any given PRECIS profile is not necessarily > an idempotent procedure for all code points. Therefore, > implementations might need to apply the rules more than once to an > internationalized string. > > Peter > From nobody Mon Mar 27 06:50:32 2017 Return-Path: X-Original-To: precis@ietf.org Delivered-To: precis@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8CE1294CD; Mon, 27 Mar 2017 06:50:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: precis@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149062262009.30650.971013828438673941@ietfa.amsl.com> Date: Mon, 27 Mar 2017 06:50:20 -0700 Archived-At: Subject: [precis] I-D Action: draft-ietf-precis-7564bis-06.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 13:50:20 -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 of the IETF. Title : PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols Authors : Peter Saint-Andre Marc Blanchet Filename : draft-ietf-precis-7564bis-06.txt Pages : 42 Date : 2017-03-27 Abstract: Application protocols using Unicode code points in protocol strings need to properly handle such strings in order to enforce internationalization rules for strings placed in various protocol slots (such as addresses and identifiers) and to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation, enforcement, and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode code points and thus is more 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 7564. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-7564bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-precis-7564bis-06 https://datatracker.ietf.org/doc/html/draft-ietf-precis-7564bis-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-precis-7564bis-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 27 06:50:39 2017 Return-Path: X-Original-To: precis@ietf.org Delivered-To: precis@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 61AB9129545; Mon, 27 Mar 2017 06:50:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: precis@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149062262836.30583.7872647350611139446@ietfa.amsl.com> Date: Mon, 27 Mar 2017 06:50:28 -0700 Archived-At: Subject: [precis] I-D Action: draft-ietf-precis-7613bis-06.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 13:50:28 -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 of the IETF. Title : Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords Authors : Peter Saint-Andre Alexey Melnikov Filename : draft-ietf-precis-7613bis-06.txt Pages : 25 Date : 2017-03-27 Abstract: This document describes updated methods for handling Unicode strings representing usernames and passwords. The previous approach was known as SASLprep (RFC 4013) and was based on stringprep (RFC 3454). The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords. The preparation, enforcement, and comparison of internationalized strings (PRECIS) framework, RFC 7564, obsoletes RFC 3454, and this document obsoletes RFC 7613. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-7613bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-precis-7613bis-06 https://datatracker.ietf.org/doc/html/draft-ietf-precis-7613bis-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-precis-7613bis-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 27 06:50:51 2017 Return-Path: X-Original-To: precis@ietf.org Delivered-To: precis@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56ABD1296BD; Mon, 27 Mar 2017 06:50:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: precis@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149062263914.30541.11377934005470141421@ietfa.amsl.com> Date: Mon, 27 Mar 2017 06:50:39 -0700 Archived-At: Subject: [precis] I-D Action: draft-ietf-precis-7700bis-06.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 13:50:40 -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 of the IETF. Title : Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames Author : Peter Saint-Andre Filename : draft-ietf-precis-7700bis-06.txt Pages : 11 Date : 2017-03-27 Abstract: This document describes methods for handling Unicode strings representing memorable, human-friendly names (called "nicknames", "display names", or "petnames") for people, devices, accounts, websites, and other entities. This document obsoletes RFC 7700. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-7700bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-precis-7700bis-06 https://datatracker.ietf.org/doc/html/draft-ietf-precis-7700bis-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-precis-7700bis-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 27 07:02:28 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD7212783A for ; Mon, 27 Mar 2017 07:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=ChJihou0; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rZiw8sjH 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 GlUXixbHlgw0 for ; Mon, 27 Mar 2017 07:02:25 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44CFD126FDC for ; Mon, 27 Mar 2017 07:02:25 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id AB14120A23; Mon, 27 Mar 2017 10:02:24 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Mon, 27 Mar 2017 10:02:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=v0HXHx1SIOT+oP05GuCWczwx9PqATBxuiq4ji+FDH h8=; b=ChJihou0mEudbqtlJQOMFvLZt5yiD80pg7ybDxomOhG+EcKq9uPB3emw7 BR2CQe4T7ueoUWeaLLcQP4e27m+qGg5S9iAT3DtHj6fsBFXfDVAvrSouHZ4PDV0n A/G6QuOq35xplRSN11zBdw3+2HAZMZyLTBpgHtHerRUk3YtIH6YIzY1NLXgM07TX THxqePrNMg7jTGznHyii003+33QIFeUYR8Tjc2bz0ya8pjaMeATMiY+2i80JuFUq 0XuYDb7Q1dDV44Ac5Hc0FkZKzHSFX0UAsPRXvzOM8bVm1XDMOBs4McH8WOcZeJJZ THqV9zso14ojjxnWfGUAcLuerVNng== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=v0HXHx1SIOT+oP05Gu CWczwx9PqATBxuiq4ji+FDHh8=; b=rZiw8sjHqJm/x48NoH39MqciMWGgLMKVtS Rj/BfnOlXqSQI4GJDhevNBU1YhWKsdyRRGcZ9cBTHH+XHjvjRtZdj7zRg4+7LFQJ jXbc2apBbidZpiIV8wkwb99cTL6a0nbgE7Pdzbx9JRwFTEjmHu40d84V/oWTs9Zj 0Vy3gTroo3ME+PoD2ZlvvtDaNxpKXb+IoK5axJ6la/fPGRROETvfWl1FSasb1EGu n6fJcD8ClvMDZ7GVr/n5xJhpAn1AxtGvqyvAmGuhwNvQGc1n9ANa3E9q4et9fjox Y4EXdH7KpQ4HVXBRf0cVlP9CGMzymIzXmNaZ7R500NVvs84g1dsg== X-ME-Sender: X-Sasl-enc: hyqW8GTibhi0osHxxb7sZBViLkF5ClRO665X7KhdbhZp 1490623344 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 317997E6B8; Mon, 27 Mar 2017 10:02:24 -0400 (EDT) To: "precis@ietf.org" From: Peter Saint-Andre Message-ID: <614797b9-e4c5-0119-c542-7bb688ed2c29@stpeter.im> Date: Mon, 27 Mar 2017 08:02:23 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [precis] version -06 I-Ds X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 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, 27 Mar 2017 14:02:27 -0000 The -06 versions of 7564bis, 7613bis, and 7700bis (just posted) are my attempt to address all feedback received to date. I believe that they are ready for Working Group Last Call, which I also hope will elicit more feedback so that we can finish our work on these specifications. Peter From nobody Mon Mar 27 15:22:36 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE05128E19 for ; Mon, 27 Mar 2017 15:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 1DFPCSUpc71h for ; Mon, 27 Mar 2017 15:22:33 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id EE1CD126BFD for ; Mon, 27 Mar 2017 15:22:32 -0700 (PDT) Received: from [206.123.31.198] (unknown [IPv6:2620:0:230:2001::1004]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 7514647984 for ; Mon, 27 Mar 2017 18:22:32 -0400 (EDT) From: "Marc Blanchet" To: precis@ietf.org Date: Mon, 27 Mar 2017 17:22:32 -0500 Message-ID: <299766BF-AA2A-4F96-B5CF-581346A42A2D@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: [precis] wglc on draft-ietf-precis-7564bis X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 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, 27 Mar 2017 22:22:34 -0000 Hello, this is a simultaneous working group last call on the updates of precis RFCs: - draft-ietf-precis-7564bis - draft-ietf-precis-7613bis - draft-ietf-precis-7700bis Given IETF week, we will do a 3 weeks last call, ending April 14th 23h59 UTC. Please reply to each document thread separately (as shown in the subject line) Marc. From nobody Mon Mar 27 15:22:56 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1910A12968F for ; Mon, 27 Mar 2017 15:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 0TUrko3qEZd3 for ; Mon, 27 Mar 2017 15:22:49 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 92C5D129685 for ; Mon, 27 Mar 2017 15:22:49 -0700 (PDT) Received: from [206.123.31.198] (unknown [IPv6:2620:0:230:2001::1004]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3622B47984 for ; Mon, 27 Mar 2017 18:22:49 -0400 (EDT) From: "Marc Blanchet" To: precis@ietf.org Date: Mon, 27 Mar 2017 17:22:49 -0500 Message-ID: <84357135-059A-4AEC-8A8F-A88AE1C94171@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: [precis] wglc on draft-ietf-precis-7613bis X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 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, 27 Mar 2017 22:22:53 -0000 Hello, this is a simultaneous working group last call on the updates of precis RFCs: - draft-ietf-precis-7564bis - draft-ietf-precis-7613bis - draft-ietf-precis-7700bis Given IETF week, we will do a 3 weeks last call, ending April 14th 23h59 UTC. Please reply to each document thread separately (as shown in the subject line) Marc. From nobody Mon Mar 27 15:23:09 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9409129683 for ; Mon, 27 Mar 2017 15:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 RwPWpss2BtcB for ; Mon, 27 Mar 2017 15:23:05 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id C1D64127871 for ; Mon, 27 Mar 2017 15:23:05 -0700 (PDT) Received: from [206.123.31.198] (unknown [IPv6:2620:0:230:2001::1004]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 30C0347984 for ; Mon, 27 Mar 2017 18:23:05 -0400 (EDT) From: "Marc Blanchet" To: precis@ietf.org Date: Mon, 27 Mar 2017 17:23:05 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: [precis] wglc on draft-ietf-precis-7700bis X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 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, 27 Mar 2017 22:23:07 -0000 Hello, this is a simultaneous working group last call on the updates of precis RFCs: - draft-ietf-precis-7564bis - draft-ietf-precis-7613bis - draft-ietf-precis-7700bis Given IETF week, we will do a 3 weeks last call, ending April 14th 23h59 UTC. Please reply to each document thread separately (as shown in the subject line) Marc. From nobody Thu Mar 30 08:01:06 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E02DA120726 for ; Thu, 30 Mar 2017 08:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 C1L3yAwefWe8 for ; Thu, 30 Mar 2017 08:01:03 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56F47129512 for ; Thu, 30 Mar 2017 08:01:00 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6473983F46 for ; Thu, 30 Mar 2017 14:53:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 6473983F46 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=nmav@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 6473983F46 Received: from dhcp-10-40-1-102.brq.redhat.com (unknown [10.40.3.166]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DB20D78DCA for ; Thu, 30 Mar 2017 14:53:56 +0000 (UTC) Message-ID: <1490885635.10364.10.camel@redhat.com> From: Nikos Mavrogiannopoulos To: precis@ietf.org Date: Thu, 30 Mar 2017 16:53:55 +0200 Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Thu, 30 Mar 2017 14:53:57 +0000 (UTC) Archived-At: Subject: [precis] rationale of rfc7613 decisions X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2017 15:01:05 -0000 Hi, I'd like to update an rfc in order to follow the rfc7613 recommendations for passwords, however I'd like first to understand the reason of the restrictions applied to passwords (i.e., freeformclass choice, space elimination, etc.). I'm checking both rfc7564 and rfc7613, and I cannot find the rationale of the restrictions being done. In particular: 1. why rfc7613 restricts all spaces for passwords to U+0020? 2. what is the purpose of "Contextual Rule Required" in section 4.3.2 of rfc7564?  3. why freeform class doesn't allow "Old Hangul Jamo characters"? 4. why freeform class doesn't allow ignorable charaters? The context of that, is that I am trying to understand what would be the drawbacks from recommending a fixed normalization form (e.g., NFC), for passwords, in contrast to recommending rfc7613. regards, Nikos From nobody Thu Mar 30 18:45:14 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB84129444 for ; Thu, 30 Mar 2017 18:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=k2y1Tsys; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=N6VJ/ohV 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 sXWxqGrWLtoS for ; Thu, 30 Mar 2017 18:45:10 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB9AC1286CA for ; Thu, 30 Mar 2017 18:45:10 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 412C320C4E; Thu, 30 Mar 2017 21:45:10 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Thu, 30 Mar 2017 21:45:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=HSgcMdd8XKuXoH9ivX 6/fKgHGOduTFNBLSqmQaD+4X4=; b=k2y1Tsys1rFUZCvdW0Kfx6fYVyeSGirULo Otl8ZnKnQ1NwssXrHv6nSpV4lah2gIIZfl+pKxb21vS3AU5UHHTzWOtkkDJ4g4k7 frh8yYST212f3PGNW+bFJoMmGl/wJToqkgNb7nw1ZxynLgT6TL5MZOZfoTrBThL5 Iq2I/EmsM6+NgiwIgEb/L8YnNiI4i5HbA4VecSPleVuVLetCJWXaJwHSVtYOERIc oNyiMkXwRanh4E5IIoKOdZih99rTOXhMeuJOoOXHllcPN/OECQ8bj2Htx5sOC4BB +TgVPP03/4osuoRaiBdzlgsn/dutr59umbMie2tgahGMFeEsagYg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=HSgcMdd8XKuXoH9ivX6/fKgHGOduTFNBLSqmQaD+4X4=; b=N6VJ/ohV oT9a+XXe3QoVw2RHTATwh/W7IKE8yc0nMyjMwtQoYaoyVIKhlKeV1jqYx/TsdKzk l1JQbJGl8PuR1ufvYjnnxKaCKzyuVnfJBqQzLZBSW2+zFO4Eyh+QbM9qrpfL+uJt D0LgkgJeBcXiQulXnzyyKbZHmV8V9My9wxAO/aJUrbltxpL5GBCLq4YkE9eRR2CO Ea15rVzfXNoR1NnBZk+Jo221LomQjFQInHv+pqZM5Pp9ZPqxM3EBZt2WQM4ync7m Q7tNnDNvPKR9rzWBbuZMfyEeScnofvXQ3LVkBkjbBxw5ZI5fZ+ENLNl8XCcl8IDO L55pllYP3UHy4Q== X-ME-Sender: X-Sasl-enc: fe2eMQbreZt5HuGuMSp8nliWPDp+yxcPk/0BlIAyhAeR 1490924709 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id BDEFA24370; Thu, 30 Mar 2017 21:45:09 -0400 (EDT) To: Nikos Mavrogiannopoulos , precis@ietf.org References: <1490885635.10364.10.camel@redhat.com> From: Peter Saint-Andre Message-ID: <5d02a0bc-5f53-a9fe-33fe-be0c66de24ee@stpeter.im> Date: Thu, 30 Mar 2017 19:45:08 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1490885635.10364.10.camel@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [precis] rationale of rfc7613 decisions X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 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, 31 Mar 2017 01:45:13 -0000 On 3/30/17 8:53 AM, Nikos Mavrogiannopoulos wrote: > Hi, > I'd like to update an rfc in order to follow the rfc7613 > recommendations for passwords, however I'd like first to understand the > reason of the restrictions applied to passwords (i.e., freeformclass > choice, space elimination, etc.). Thanks for asking! > I'm checking both rfc7564 and rfc7613, and I cannot find the rationale > of the restrictions being done. In particular: > 1. why rfc7613 restricts all spaces for passwords to U+0020? First, RFC 4013 prohibited non-ASCII space code points (see §2.3), and RFC 7613 was intended as much as possible to not change handling of code points. Second, there are many issues with non-ASCII space code points, such as zero-width spaces that aren't visible to a user and variations in input methods across devices that are "localized" for different scripts and locales. You can find some discussion about it here: https://www.ietf.org/mail-archive/web/precis/current/msg00251.html > 2. what is the purpose of "Contextual Rule Required" in section 4.3.2 > of rfc7564? It's complicated, but in essence PRECIS is consistent with IDNA2008 here (see RFC 5891, RFC 5892, and RFC 5894). In particular, the code points ZERO WIDTH JOINER (U+200D) and ZERO WIDTH NON-JOINER (U+200C) are necessary to produce certain combinatiosn of characters in certain scripts (e.g., Arabic, Persian, and Indic scripts) but if used in other contexts can have consequences that violate the principle of least user astonishment. > 3. why freeform class doesn't allow "Old Hangul Jamo characters"? As explained in §2.9 of RFC 5892: Elimination of conjoining Hangul Jamo from the set of PVALID characters results in restricting the set of Korean PVALID characters just to preformed, modern Hangul syllable characters. Here again PRECIS is consistent with IDNA2008. > 4. why freeform class doesn't allow ignorable charaters? These are things like soft hyphen, certain joiners, specialized code points for use within Unicode itself (e.g., language tags and variation selectors), and so on. They were disallowed in RFC 4013 and are disallowed in IDNA2008, too. By saying "PRECIS is consistent with IDNA2008" I'm not appealing to authority or saying that a consistency is necessarily a good thing. Instead, defining as few string handling methods as possible helps users because strings aren't handled differently in different protocols and contexts (see §5.1 of RFC 7564). This has security implications, too, because the more such methods exist the easier it will be for attackers to trick users. > The context of that, is that I am trying to understand what would be > the drawbacks from recommending a fixed normalization form (e.g., NFC), > for passwords, in contrast to recommending rfc7613. Nikos, instead of asking us why the foregoing restrictions were made, ask yourself why you would want to ignore them and whether you understand internationalization well enough to independently craft appropriate rules and guidelines for the RFC you're updating. Because you actively work on security technologies, think of it this way: would you want someone who doesn't understand all the issues to "just use TLS" without specifying appropriate cipher suites (ignoring RFC 7525) or certificate checking procedures (ignoring RFC 5280 and RFC 6125)? The issues involved with internationalization are just as complex (albeit in different ways) and the whole reason we developed IDNA2008 and PRECIS is so that well-meaning folks like you don't shoot yourselves in the foot. I strongly encourage you to use the PRECIS profile for passwords in RFC 7613, and we'd be happy to help you do so in the safest ways possible. Peter From nobody Fri Mar 31 01:29:41 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58DAA127735 for ; Fri, 31 Mar 2017 01:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 gPZB3yuyNuFg for ; Fri, 31 Mar 2017 01:29:37 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6737126BF7 for ; Fri, 31 Mar 2017 01:29:36 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8319464062; Fri, 31 Mar 2017 08:29:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 8319464062 Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=nmav@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 8319464062 Received: from dhcp-10-40-1-102.brq.redhat.com (unknown [10.40.3.166]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D11F277DD0; Fri, 31 Mar 2017 08:29:35 +0000 (UTC) Message-ID: <1490948974.24162.5.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Peter Saint-Andre , precis@ietf.org Date: Fri, 31 Mar 2017 10:29:34 +0200 In-Reply-To: <5d02a0bc-5f53-a9fe-33fe-be0c66de24ee@stpeter.im> References: <1490885635.10364.10.camel@redhat.com> <5d02a0bc-5f53-a9fe-33fe-be0c66de24ee@stpeter.im> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Fri, 31 Mar 2017 08:29:36 +0000 (UTC) Archived-At: Subject: Re: [precis] rationale of rfc7613 decisions X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 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, 31 Mar 2017 08:29:39 -0000 On Thu, 2017-03-30 at 19:45 -0600, Peter Saint-Andre wrote: > > I'm checking both rfc7564 and rfc7613, and I cannot find the > > rationale > > of the restrictions being done. In particular: > >  1. why rfc7613 restricts all spaces for passwords to U+0020? > > [...] > >  2. what is the purpose of "Contextual Rule Required" in section > > 4.3.2 > > of rfc7564? > > It's complicated, but in essence PRECIS is consistent with IDNA2008 > here > (see RFC 5891, RFC 5892, and RFC 5894). In particular, the code > points > ZERO WIDTH JOINER (U+200D) and ZERO WIDTH NON-JOINER (U+200C) are > necessary to produce certain combinatiosn of characters in certain > scripts (e.g., Arabic, Persian, and Indic scripts) but if used in > other > contexts can have consequences that violate the principle of least > user astonishment. I think that such issues should warrant extensive discussions in an RFC like 7613. It is not apparent for me for example why that principle should apply for passwords (which are not visible). I guess there are arguments for that, but should be presented in order to understand and be able to convince people that RFC7613 is the way to go. >  3. why freeform class doesn't allow "Old Hangul Jamo characters"? > As explained in §2.9 of RFC 5892: > >    Elimination of conjoining Hangul Jamo from the set of PVALID >    characters results in restricting the set of Korean PVALID > characters >    just to preformed, modern Hangul syllable characters. > Here again PRECIS is consistent with IDNA2008. As I am mostly restricted in the context of passwords, my question is mostly on why is this done for the passwords. E.g., Is it because the Hangual Jamo set is a deprecated set which may not be in use years from now or another reason? > >  4. why freeform class doesn't allow ignorable charaters? > > These are things like soft hyphen, certain joiners, specialized code > points for use within Unicode itself (e.g., language tags and > variation > selectors), and so on. They were disallowed in RFC 4013 and are > disallowed in IDNA2008, too. > > By saying "PRECIS is consistent with IDNA2008" I'm not appealing to > authority or saying that a consistency is necessarily a good thing. > Instead, defining as few string handling methods as possible helps > users > because strings aren't handled differently in different protocols and > contexts (see §5.1 of RFC 7564). This has security implications, too, > because the more such methods exist the easier it will be for > attackers to trick users. In the context of 'passwords', I see very little applicability of such attacks, though I may be wrong. The main concern I see for passwords used for storage is compatibility, e.g., even with legacy software which did not follow these rules, and simplicity, so that software can follow the rules under reasonable for the task effort (I find the effort RFC7613 requires for processing UTF-8 passwords unproportionaly complex to the effort needed for US-ASCII passwords). > > The context of that, is that I am trying to understand what would > > be > > the drawbacks from recommending a fixed normalization form (e.g., > > NFC), > > for passwords, in contrast to recommending rfc7613. > > Nikos, instead of asking us why the foregoing restrictions were made, > ask yourself why you would want to ignore them and whether you > understand internationalization well enough to independently craft > appropriate rules and guidelines for the RFC you're updating. Because > you actively work on security technologies, think of it this way: > would > you want someone who doesn't understand all the issues to "just use > TLS" > without specifying appropriate cipher suites (ignoring RFC 7525) or > certificate checking procedures (ignoring RFC 5280 and RFC 6125)? The > issues involved with internationalization are just as complex (albeit > in different ways) and the whole reason we developed IDNA2008 and > PRECIS is so that well-meaning folks like you don't shoot yourselves > in the foot. I cannot disagree with that, however, providing rationale for the decisions is important, especially in documents which are developed in disconnect with many existing protocols/practices. The current state in PKCS#12, PKCS#8 encrypted files, is pass there whatever you have as long as it is UTF-8. Convincing developers to deploy thousands lines of code for pre-processing such passwords, would require to underline the problems of the previous practice. RFC7613 unfortunately ignores that part completely, and I have no arguments when trying to convince people that this should be preferred. > I strongly encourage you to use the PRECIS profile for passwords in > RFC7613, and we'd be happy to help you do so in the safest ways > possible. I'm trying to make a list of items which make apparent why RFC7613 is needed. What I have now is: "UTF-8 however, does not imply that strings conforming to it, are unambiguously unique, since there are can be various forms of the same string which may look identical to an observer, although being represented by a different byte string. Some issues are the following." [The NFC argument is the easier to explain] * Various normalization forms, which result to different data for the same input. [why spaces need to be merged to 0x20 is harder to sell] * The unicode standard includes a number of space characters which cannot be distinguished from each other, or have no width resulting to different results when switching to a different input method [Hangual Jamo even harder] * There are deprecated alphabet sets, which are no longer in use(?) and may not be available as input methods in the future. [contextual rule] * Certain combinations of code points between certain scripts produce unexpected visible results. (the question here is why would one care for visible results on passwords which are not printed) regards, Nikos