From nobody Sun Jan 18 09:00:30 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABE011ACD70 for ; Sun, 18 Jan 2015 09:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.1 X-Spam-Level: *** X-Spam-Status: No, score=3.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MANGLED_NAIL=2.3] 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 JEKyOeE0lV18 for ; Sun, 18 Jan 2015 09:00:27 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id C6E241ACDA2 for ; Sun, 18 Jan 2015 09:00:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id CA2FD2240DF3 for ; Sun, 18 Jan 2015 18:00:25 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Dz57MnGbHO7 for ; Sun, 18 Jan 2015 18:00:24 +0100 (CET) Received: from [192.168.20.49] (198-84-181-115.cpe.teksavvy.com [198.84.181.115]) by power.freeradius.org (Postfix) with ESMTPSA id A15422240173 for ; Sun, 18 Jan 2015 18:00:23 +0100 (CET) From: Alan DeKok Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <3431839C-572D-458D-882B-F2045B0FF377@deployingradius.com> Date: Sun, 18 Jan 2015 12:00:20 -0500 To: precis@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [precis] Oracle / ZFS note on normalization 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: Sun, 18 Jan 2015 17:00:28 -0000 h= ttps://blogs.oracle.com/nico/entry/normalization_insensitivity_should_be_t= he They recommend storing the data / filename entered by the client = as-is. Then for comparisons, each client reads the filename, does = normalization, and compares the normalized strings. This is the same conclusion we got to in the RADEXT NAI document: https://tools.ietf.org/html/draft-ietf-radext-nai-15 Is there a reference which makes this recommendation clear? It would = be good to help people create good solutions. If there isn=92t a reference, should there be one? Alan DeKok. From nobody Sun Jan 18 09:11:19 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D22A1ACD74 for ; Sun, 18 Jan 2015 09:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.938 X-Spam-Level: ** X-Spam-Status: No, score=2.938 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_SE=0.35, MANGLED_NAIL=2.3, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDq7tkn0oAlZ for ; Sun, 18 Jan 2015 09:11:11 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 841E41ACD70 for ; Sun, 18 Jan 2015 09:11:11 -0800 (PST) Received: from [192.168.1.125] (frobbit.cust.teleservice.net [85.30.128.225]) by mail.frobbit.se (Postfix) with ESMTPSA id 1AD9D201B7; Sun, 18 Jan 2015 18:11:09 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_B29384A1-49A1-46F6-95F6-3A193C8C1EC2"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b4 From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= In-Reply-To: <3431839C-572D-458D-882B-F2045B0FF377@deployingradius.com> Date: Sun, 18 Jan 2015 18:11:08 +0100 Message-Id: <436D84EF-158A-4260-B36D-10A5B54DF732@frobbit.se> References: <3431839C-572D-458D-882B-F2045B0FF377@deployingradius.com> To: Alan DeKok X-Mailer: Apple Mail (2.1993) Archived-At: Cc: precis@ietf.org Subject: Re: [precis] Oracle / ZFS note on normalization 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: Sun, 18 Jan 2015 17:11:13 -0000 --Apple-Mail=_B29384A1-49A1-46F6-95F6-3A193C8C1EC2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On 18 jan 2015, at 18:00, Alan DeKok = wrote: >=20 > = https://blogs.oracle.com/nico/entry/normalization_insensitivity_should_be_= the >=20 > They recommend storing the data / filename entered by the client = as-is. Then for comparisons, each client reads the filename, does = normalization, and compares the normalized strings. Very english/us centric text when conclusions are drawn on how often = issues might arrive. That said, the thinking is not bad, but requires quite some thinking on = various scenarios. > This is the same conclusion we got to in the RADEXT NAI document: >=20 > https://tools.ietf.org/html/draft-ietf-radext-nai-15 >=20 > Is there a reference which makes this recommendation clear? It would = be good to help people create good solutions. >=20 > If there isn=92t a reference, should there be one? There must be much more work behind something like this, like looking at = the various normalization forms, when matching actually happens (risk = for creation of two different files, when later only one of them can be = accessed -- and it might even be a random one of them) etc. Patrik --Apple-Mail=_B29384A1-49A1-46F6-95F6-3A193C8C1EC2 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 iD8DBQFUu+ksrMabGguI180RAhrMAJ4yU6zbLFaMinkHHAeHDWyQHC5mOgCgh+8z IPND/JBTeh5/QsvjhMR8500= =VyDo -----END PGP SIGNATURE----- --Apple-Mail=_B29384A1-49A1-46F6-95F6-3A193C8C1EC2-- From nobody Tue Jan 27 11:19:44 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6168B1A86E9 for ; Tue, 27 Jan 2015 11:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 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_HI=-5, 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 pRRa8xp6-D9o for ; Tue, 27 Jan 2015 11:19:41 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AE411A7018 for ; Tue, 27 Jan 2015 11:19:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1422386380; x=1453922380; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=m9yy0J2NXspPZpEx/fmhXG955ih3drf3/8uhkLsYMAY=; b=r1qTO6wrovdgyO+ysEwzjhTbU/kocD3QZ491gm0KhuhfKADduAnwUo1/ TTnGJqURYDFpSf3PsMLXJ2AMnjA3iAT5tWnVwIOzaqr/7Nhjvqk1KeCza CJ92hW6IiNONL6qEzTRZKvK/7ASUU7EECfnkfVMdYNhCf1lfFvxgBZhF7 U=; X-IronPort-AV: E=McAfee;i="5600,1067,7694"; a="100430508" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by wolverine01.qualcomm.com with ESMTP; 27 Jan 2015 11:19:39 -0800 X-IronPort-AV: E=Sophos;i="5.09,476,1418112000"; d="scan'208";a="32234955" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 27 Jan 2015 11:19:39 -0800 Received: from presnick-mac.wlan.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 27 Jan 2015 11:19:38 -0800 Message-ID: <54C7E4CA.9080803@qti.qualcomm.com> Date: Tue, 27 Jan 2015 11:19:38 -0800 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "precis@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (10.85.0.81) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Subject: [precis] Temporary chair duties for -precis-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, 27 Jan 2015 19:19:43 -0000 Greetings, As you may know, -precis-framework went through a few revisions after IESG Evaluation. We now feel it's ready to go, but we will want to do another IETF-wide Last Call and IESG Evaluation, if for no other reason than to dot-'i's and cross-'t's. Unfortunately, I have recently spoken to Yoneya-san, and his workload at his regular job is such that he is unable to do the final duties for the document, and so he has asked to step down as chair. I want to thank him for his excellent service to the WG and to the IETF. But to complicate matters a bit for the framework document, since Marc is a document co-editor, he can't perform those duties either. Luckily, Alexey Melnikov has agreed to step in as interim chair for purposes of getting this document across the finish line. Given that he acted as document shepherd for the document, I have no worries that he'll be able to pick up the ball. I thank Alexey for taking on this role. I hope the framework document will be Last Called tout de suite, and will be approved by the IESG on their 19 February telechat. Thanks again to Yoneya-san and Alexey, and thank you all for your patience. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478