From discuss-bounces@apps.ietf.org Sat May 05 11:19:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkM2W-0005wi-Uy; Sat, 05 May 2007 11:19:16 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hjzi2-0008Cq-Is for discuss-confirm+ok@megatron.ietf.org; Fri, 04 May 2007 11:28:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjzi2-0008Ci-99 for discuss@apps.ietf.org; Fri, 04 May 2007 11:28:38 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hjzi0-0002A5-UT for discuss@apps.ietf.org; Fri, 04 May 2007 11:28:38 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id AE1CD2CAA; Fri, 4 May 2007 18:28:31 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070322 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070322 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id E84B82CA6; Fri, 4 May 2007 18:28:30 +0300 (EEST) Date: Fri, 4 May 2007 18:28:30 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: discuss@apps.ietf.org Subject: sockets APIs extensions for Host Identity Protocol Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-Mailman-Approved-At: Sat, 05 May 2007 11:19:15 -0400 Cc: Thomas Henderson X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi all, we are contemplating a level of indirection in naming hosts to future-proof the Host Identity Protocol (HIP). The proposed sockets API extensions use locally-scoped "handles" instead of Host Identity Tags (HITs, that is, cryptographically generated IPv6-like addresses). One could conceive that such a level of indirection could be used more generally outside of HIP, to enable applications to be more compatible across IP versions, for instance. What are the benefits and costs that you see about migrating the basic socket API calls towards end-system handles rather than explicit end-system addresses? A potential benefit of the handles is that it would make the API future-proof againts changes to the HIT size. Similarly, one might argue that the IPv6 transition would have been a lot easier for applications if the concept of endpoint descriptor were already available for the past twenty years; IPv6 could have been hidden in the system. This latter observation makes me wonder whether there have been such considerations previously in the applications area? The sockets API extensions are defined here: http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-01.txt -- Miika & Tom From discuss-bounces@apps.ietf.org Mon May 07 04:27:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkyZP-0000a9-89; Mon, 07 May 2007 04:27:47 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HkyZM-0000TM-42 for discuss-confirm+ok@megatron.ietf.org; Mon, 07 May 2007 04:27:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkyZL-0000SO-Lj for discuss@apps.ietf.org; Mon, 07 May 2007 04:27:43 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HkyZI-0001cr-C1 for discuss@apps.ietf.org; Mon, 07 May 2007 04:27:43 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 4CCF61C00D8; Mon, 7 May 2007 10:27:39 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 476E81C00D7; Mon, 7 May 2007 10:27:37 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 44E1258EBBC; Mon, 7 May 2007 10:27:37 +0200 (CEST) Date: Mon, 7 May 2007 10:27:37 +0200 From: Stephane Bortzmeyer To: Miika Komu Subject: Re: sockets APIs extensions for Host Identity Protocol Message-ID: <20070507082737.GB21759@nic.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: discuss@apps.ietf.org, Thomas Henderson X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Fri, May 04, 2007 at 06:28:30PM +0300, Miika Komu wrote a message of 27 lines which said: > One could conceive that such a level of indirection could be used > more generally outside of HIP, to enable applications to be more > compatible across IP versions, for instance. One important thing: this is only for the C programming language. In most (all?) other languages, programmers no longer handle directly IP addresses and thus are shielded from things like IPv4 vs. IPv6 or addresses vs. handles. > This latter observation makes me wonder whether there have been such > considerations previously in the applications area? The big advice should be: use a high-level language (or, in C, a high-level library, like Neon - http://www.webdav.org/neon/ - or cURL - http://curl.haxx.se/) and you're safe from the changes in IETF fashions. From discuss-bounces@apps.ietf.org Mon May 07 17:31:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlAnx-0006IT-9P; Mon, 07 May 2007 17:31:37 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HlAnw-0006IO-1q for discuss-confirm+ok@megatron.ietf.org; Mon, 07 May 2007 17:31:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlAnv-0006IF-OU for discuss@apps.ietf.org; Mon, 07 May 2007 17:31:35 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlAnu-0003V2-5f for discuss@apps.ietf.org; Mon, 07 May 2007 17:31:35 -0400 Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l47LVXRj024604 for ; Mon, 7 May 2007 21:31:33 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JHO00101WTGCU00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for discuss@apps.ietf.org; Mon, 07 May 2007 15:31:33 -0600 (MDT) Received: from [10.0.1.21] ([10.1.110.5]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHO008J6X4I6330@mail-amer.sun.com>; Mon, 07 May 2007 15:31:33 -0600 (MDT) Date: Mon, 07 May 2007 14:31:31 -0700 From: Chris Newman Subject: Re: sockets APIs extensions for Host Identity Protocol In-reply-to: To: Miika Komu , discuss@apps.ietf.org Message-id: <31BC7A8C1A51004A84E08DEF@[10.1.110.5]> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Thomas Henderson X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Speaking as a technical participant, not as an area director... Application software wants to work with strings. When I want to make a network connection, I have a string which says what I want to connect to. It might be a DNS name, an IPv4 address literal, and IPv6 address literal, the field after the "//" in a URL or whatever the string format for a HIP endpoint is going to be. As an application developer I don't want to care what that string means. I might want a way to turn that string into an opaque object (or objects) and back (with a timeout) and then use that opaque object in something equivalent to connect and/or bind. I also want a way to enumerate the string representations of the local interfaces on a server so that I can offer the administrator a choice of which interface(s) the listen ports bind to. I don't want to care whether those are IPv4, IPv6 or HIP or something else. The only reason I might care what the string or opaque object refers to is for debugging/logging/diagnostic purposes. If I change my "connectbyname" code again, I will change it once more to use a new OS API that hides all the v4 vs. v6 vs. HIP vs. whatever junk, preferably to something much simpler than the code today. If such an API isn't produced, I will be very reluctant to change that code no matter how cool HIP might or might not be. So the API described in your document is one I plan to never use if at all possible. That might have consequences for HIP deployment, just as the present state of IPv6 C socket APIs has not been great for IPv6 deployment. - Chris Miika Komu wrote on 5/4/07 18:28 +0300: > Hi all, > > we are contemplating a level of indirection in naming hosts to future-proof > the Host Identity Protocol (HIP). The proposed sockets API extensions use > locally-scoped "handles" instead of Host Identity Tags (HITs, that is, > cryptographically generated IPv6-like addresses). One could conceive that > such a level of indirection could be used more generally outside of HIP, to > enable applications to be more compatible across IP versions, for instance. > What are the benefits and costs that you see about migrating the basic socket > API calls towards end-system handles rather than explicit end-system > addresses? > > A potential benefit of the handles is that it would make the API future-proof > againts changes to the HIT size. Similarly, one might argue that the IPv6 > transition would have been a lot easier for applications if the concept of > endpoint descriptor were already available for the past twenty years; IPv6 > could have been hidden in the system. This latter observation makes me > wonder whether there have been such considerations previously in the > applications area? > > The sockets API extensions are defined here: > > http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-01.txt > > -- > Miika & Tom > > > From discuss-bounces@apps.ietf.org Mon May 07 18:16:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlBVH-0001xe-16; Mon, 07 May 2007 18:16:23 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HlBVG-0001xZ-GK for discuss-confirm+ok@megatron.ietf.org; Mon, 07 May 2007 18:16:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlBVG-0001xR-6u for discuss@apps.ietf.org; Mon, 07 May 2007 18:16:22 -0400 Received: from sparkle.rodents.montreal.qc.ca ([216.46.5.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlBVE-0003Sp-5G for discuss@apps.ietf.org; Mon, 07 May 2007 18:16:22 -0400 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id SAA06179; Mon, 7 May 2007 18:16:16 -0400 (EDT) From: der Mouse Message-Id: <200705072216.SAA06179@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Mon, 7 May 2007 18:07:14 -0400 (EDT) To: discuss@apps.ietf.org Subject: Re: sockets APIs extensions for Host Identity Protocol In-Reply-To: <31BC7A8C1A51004A84E08DEF@[10.1.110.5]> References: <31BC7A8C1A51004A84E08DEF@[10.1.110.5]> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > Application software wants to work with strings. [...] > If I change my "connectbyname" code again, I will change it once more > to use a new OS API that hides all the v4 vs. v6 vs. HIP vs. whatever > junk, preferably to something much simpler than the code today. Something wrong with getaddrinfo()? It certainly could use something HIPish under the hood, if some implementor decided to. >> A potential benefit of the handles is that it would make the API >> future-proof againts changes to the HIT size. getaddrinfo() already is...or at least, it is when used correctly, and in this respect it's easier to use it correctly than incorrecetly (which is about all you can expect). It's a slightly broken API, true, but the problems with it are not in areas that any putative HIP/HIT stuff would fix. >> Similarly, one might argue that the IPv6 transition would have been >> a lot easier for applications if the concept of endpoint descriptor >> were already available for the past twenty years; That concept *has* been available for the past twenty years; it's called a "socket". What hasn't been available is a socket implementation that doesn't expose the underlying addressing details to the application. This could be - and arguably should be - fixed entirely under the socket-layer hood, not by inventing new protocols and exposing *them* to the application. I speculate that the major reason this hasn't been done is tradition - sockets have traditionally been a fairly direct interface into the kernel, and preserving that while presenting this kind of socket interface is relatively hard. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From discuss-bounces@apps.ietf.org Tue May 08 23:20:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlcij-0000F4-Ly; Tue, 08 May 2007 23:20:05 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hlcii-0000Ez-Go for discuss-confirm+ok@megatron.ietf.org; Tue, 08 May 2007 23:20:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlcii-0000Er-5N for discuss@apps.ietf.org; Tue, 08 May 2007 23:20:04 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlcig-0005za-U5 for discuss@apps.ietf.org; Tue, 08 May 2007 23:20:04 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 4B8B71EE19F; Tue, 8 May 2007 23:20:00 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8U0I2-5XaPb; Tue, 8 May 2007 23:19:55 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 641641EE197; Tue, 8 May 2007 23:19:54 -0400 (EDT) Message-ID: <46413DD7.8020702@cs.utk.edu> Date: Tue, 08 May 2007 23:19:51 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Stephane Bortzmeyer Subject: Re: sockets APIs extensions for Host Identity Protocol References: <20070507082737.GB21759@nic.fr> In-Reply-To: <20070507082737.GB21759@nic.fr> X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: discuss@apps.ietf.org, Thomas Henderson , Miika Komu X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Stephane Bortzmeyer wrote: >> One could conceive that such a level of indirection could be used >> more generally outside of HIP, to enable applications to be more >> compatible across IP versions, for instance. >> > > One important thing: this is only for the C programming language. In > most (all?) other languages, programmers no longer handle directly IP > addresses and thus are shielded from things like IPv4 vs. IPv6 or > addresses vs. handles. > In those cases, the programmers are also crippled and prevented from dealing effectively with various cases that are now increasingly common in the Intenet today: NATs, multiple addresses for source and destination (not all of which work equally well), IPv4 vs IPv6 (for which the default address selection rules are woefully inadequate), multi-faced DNS, LLMNR, etc. > The big advice should be: use a high-level language (or, in C, a > high-level library, like Neon - http://www.webdav.org/neon/ - or cURL > - http://curl.haxx.se/) and you're safe from the changes in IETF > fashions. > only if you want to limit the deployability and/or efficiency of your application. Keith From discuss-bounces@apps.ietf.org Tue May 08 23:22:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlclK-0001bk-CE; Tue, 08 May 2007 23:22:46 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HlclJ-0001bJ-3M for discuss-confirm+ok@megatron.ietf.org; Tue, 08 May 2007 23:22:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlclI-0001Zj-Om for discuss@apps.ietf.org; Tue, 08 May 2007 23:22:44 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlclH-0006b5-IE for discuss@apps.ietf.org; Tue, 08 May 2007 23:22:44 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 1F2CF1EE19F; Tue, 8 May 2007 23:22:43 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cvoJUOaSmAi; Tue, 8 May 2007 23:22:38 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 14C241EE197; Tue, 8 May 2007 23:22:38 -0400 (EDT) Message-ID: <46413E7D.5060403@cs.utk.edu> Date: Tue, 08 May 2007 23:22:37 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Chris Newman Subject: Re: sockets APIs extensions for Host Identity Protocol References: <31BC7A8C1A51004A84E08DEF@[10.1.110.5]> In-Reply-To: <31BC7A8C1A51004A84E08DEF@[10.1.110.5]> X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: discuss@apps.ietf.org, Thomas Henderson , Miika Komu X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > If I change my "connectbyname" code again, I will change it once more > to use a new OS API that hides all the v4 vs. v6 vs. HIP vs. whatever > junk, preferably to something much simpler than the code today. If > such an API isn't produced, I will be very reluctant to change that > code no matter how cool HIP might or might not be. If you can figure out how to write that kind of code in a way that works well for a wide variety of applications, with different requirements for bandwidth, stability, mobility, etc. all of which affect address selection, interface selection, etc., and do all of that efficiently and in the absence of routing information from the network, you should probably get a prize of some sort. Granted that programmers want a simple interface, but the more complex the network gets, the more apps will be expected to do jobs that were supposed to be done at layer 3. Keith From discuss-bounces@apps.ietf.org Tue May 08 23:24:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlcnE-0003mE-Gd; Tue, 08 May 2007 23:24:44 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HlcnD-0003jF-Gv for discuss-confirm+ok@megatron.ietf.org; Tue, 08 May 2007 23:24:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlcnD-0003iF-6t for discuss@apps.ietf.org; Tue, 08 May 2007 23:24:43 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlcnC-0007XJ-0Q for discuss@apps.ietf.org; Tue, 08 May 2007 23:24:43 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 978CC1EE1A5; Tue, 8 May 2007 23:24:41 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kq2NPOyLaSPs; Tue, 8 May 2007 23:24:37 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id B02C01EE179; Tue, 8 May 2007 23:24:36 -0400 (EDT) Message-ID: <46413EF3.1090302@cs.utk.edu> Date: Tue, 08 May 2007 23:24:35 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: der Mouse Subject: Re: sockets APIs extensions for Host Identity Protocol References: <31BC7A8C1A51004A84E08DEF@[10.1.110.5]> <200705072216.SAA06179@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: <200705072216.SAA06179@Sparkle.Rodents.Montreal.QC.CA> X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > Something wrong with getaddrinfo()? It certainly could use something > HIPish under the hood, if some implementor decided to. > getaddrinfo() is a disaster. not only is it the most baroque call in the entire sockets API, it also invites implementors to abuse its semantics in numerous ways (for instance, looking up SRV records for apps that weren't intended to use SRV records). Keith From discuss-bounces@apps.ietf.org Wed May 09 08:17:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hll6T-0004tM-PV; Wed, 09 May 2007 08:17:09 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hll6S-0004sC-Ps for discuss-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 08:17:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hll6S-0004s4-GL for discuss@apps.ietf.org; Wed, 09 May 2007 08:17:08 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hll6R-0001kl-7B for discuss@apps.ietf.org; Wed, 09 May 2007 08:17:08 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 29DFE1C009D; Wed, 9 May 2007 14:17:04 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 255BC1C00DE; Wed, 9 May 2007 14:17:03 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 22BC258EBB8; Wed, 9 May 2007 14:17:03 +0200 (CEST) Date: Wed, 9 May 2007 14:17:03 +0200 From: Stephane Bortzmeyer To: Keith Moore Subject: Re: sockets APIs extensions for Host Identity Protocol Message-ID: <20070509121703.GA21070@nic.fr> References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46413DD7.8020702@cs.utk.edu> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Tue, May 08, 2007 at 11:19:51PM -0400, Keith Moore wrote a message of 29 lines which said: > In those cases, the programmers are also crippled and prevented from > dealing effectively with various cases that are now increasingly > common in the Intenet today: NATs, multiple addresses for source and > destination (not all of which work equally well), IPv4 vs IPv6 (for > which the default address selection rules are woefully inadequate), > multi-faced DNS, LLMNR, etc. I strongly object to the idea of application programmers dealing with NAT, IPv4 vs. IPv6 or source address selection for the eternity. The wiring of level-3 details in the applications is precisely what makes the transition to IPv6 so difficult. Applications should not have to be "ported to IPv6". They should work the same with both level-3 protocols (and, indeed, they do, in every language but C). If the IPv6 problems are to be useful, it is in showing that there is ZERO probability of splitting the identifier and the locator if we have to change the applications. I also really doubt that the typical application programmer is able to do a better job than the kernel / libraries to, choose the source address or other level-3 features. Plus, IMHO, if someone must influence this selection, it should be the system and network administrator, not the application programmer. > only if you want to limit the deployability and/or efficiency of > your application. As an user, I would be very afraid of an application which tries to play tricks with NAT... From discuss-bounces@apps.ietf.org Wed May 09 09:19:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlm4i-0000bt-EW; Wed, 09 May 2007 09:19:24 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hlm4h-0000bn-Sl for discuss-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 09:19:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlm4h-0000be-JB for discuss@apps.ietf.org; Wed, 09 May 2007 09:19:23 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlm4g-0004Gk-5B for discuss@apps.ietf.org; Wed, 09 May 2007 09:19:23 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id A8ECA1EE1A8; Wed, 9 May 2007 09:19:21 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldCucsR0NapS; Wed, 9 May 2007 09:19:16 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 50AB81EE191; Wed, 9 May 2007 09:19:15 -0400 (EDT) Message-ID: <4641CA52.70504@cs.utk.edu> Date: Wed, 09 May 2007 09:19:14 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Stephane Bortzmeyer Subject: Re: sockets APIs extensions for Host Identity Protocol References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> In-Reply-To: <20070509121703.GA21070@nic.fr> X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >> In those cases, the programmers are also crippled and prevented from >> dealing effectively with various cases that are now increasingly >> common in the Intenet today: NATs, multiple addresses for source and >> destination (not all of which work equally well), IPv4 vs IPv6 (for >> which the default address selection rules are woefully inadequate), >> multi-faced DNS, LLMNR, etc. >> > > I strongly object to the idea of application programmers dealing with > NAT, IPv4 vs. IPv6 or source address selection for the eternity. The > wiring of level-3 details in the applications is precisely what makes > the transition to IPv6 so difficult. Applications should not have to > be "ported to IPv6". They should work the same with both level-3 > protocols (and, indeed, they do, in every language but C). > In a sense, I agree with you that we don't want most applications having to deal with these things, and we certainly don't want to saddle the application with having to deal with these problems forever. However, I do not reach the same conclusion about the API that you appear to reach, for a few reasons. First is that there will always be some applications (such as diagnostic tools) that need to know more about the network, so it is necessary to have an API that allows those applications to function. Second, I don't share the view that many seem to have that applications in general should be IP version agnostic. IPv4 with NAT is far too brain-damaged, and has such limited reach, so there is a strong case to be made that in some point in the future, many kinds of apps should operate only under IPv6. Similarly there is a case to be made for some legacy apps (e.g. apps that exist mostly to talk to obsolete hardware) to operate only under IPv4. Third, while it is well and good to talk about ideals, the notion that "applications should not have to" deal with these things ignores the fact that in the current network architecture, applications _do_ have to deal with these things. This isn't just a consequence of NATs, but also of the IPv6 architecture which insists that (for a variety of reasons) hosts shall have multiple addresses, but fails to provide hosts (and host stacks) with an effective mechanism for selecting among those addresses on behalf of applications. Such selection needs to take a variety of factors into account, including the communications topology of the application (is it multiparty or point-to-point?) the application's need for bandwidth, the likely duration of the application's association with peers, the ability of the application to tolerate and recover from changes in IP address, the way that the different address prefixes are used by the network (ELIAs can be used differently than globals, and link-locals are certainly used differently than globals), and so forth. Fourth, for a variety of reasons, DNS names are not and have never been adequate as general purpose endpoint identifiers, and this situation is getting worse rather than better. One reason is that DNS names are not equivalent to host names, and emphatically not equivalent to distinguished host names, and haven't been so at least since the web came into existence. A given DNS name might be bound to a single host, multiple hosts having more-or-less equivalent function, a service, a community of users, or whatever; the binding might be stable or ephemeral; and the name might or might not be suitable as a distinguished name (one chosen preferentially over others for use in indicating that host, group of hosts, service, whatever). There's no way to tell. Another reason is that DNS is often slow and unreliable and/or out of sync with reality - one of many factors making DNS names less suitable for referrals between hosts. Another reason is that multi-faced DNS limits the visibility of DNS names even when applications are expected to work across the boundary. Another reason is that DNS is increasingly polluted. For instance, my ISP's default DNS servers lie about DNS results for domains that have no A records, even if there are other records in that domain, in order to redirect HTTP requests for misspelled DNS names to a web server that will "helpfully" offer links to alternatives (and also display advertisements). So however noble it might be to try to present apps with a simple interface based on DNS names, what this really does is to cripple apps' ability to cope with the mess that is DNS. Fifth, trying to overload so many functions in a single API inevitably masks error conditions that often need to be distinguished, and treated differently, by the application. As for the notion that applications work the same for both v4 and v6 in every language but C: This goes a long way toward explaining why network applications continue to be written in C. And that in turn goes a long way toward explaining why network applications are notoriously insecure. I know that every time I've considered writing a network application in a new language, I take a look at the network API and conclude that it's inadequate. (granted, I tend to write more esoteric applications) > If the IPv6 problems are to be useful, it is in showing that there is > ZERO probability of splitting the identifier and the locator if we > have to change the applications. > Despite the oft-cited ideal of splitting the identifier and the locator, nobody has ever to my knowledge provided a complete and convincing example of how it can be made to work well. Actually providing those identifiers, along with a scalable, reliable, fast, and secure service that maintains identifier-to-locator bindings is a nontrivial problem that tends to be overlooked. > I also really doubt that the typical application programmer is able to > do a better job than the kernel / libraries to, choose the source > address or other level-3 features. Plus, IMHO, if someone must > influence this selection, it should be the system and network > administrator, not the application programmer. > Partially disagree, because the selection is heavily dependent on the type of application and how it uses the network. I do think that the network admin has a role in explaining to the application or API how particular addresses are to be used, but I don't think it flies to expect every application to use those addresses in exactly the same way. There's a big difference in how you want to handle address selection for a mounted remote file system than in how you want to handle address selection in an email MTA. >> only if you want to limit the deployability and/or efficiency of >> your application. >> > > As an user, I would be very afraid of an application which tries to > play tricks with NAT... I guess you wouldn't use Skype then, preferring to spend lots of money on international phone calls. In my experience users tend to prefer applications that work reliably over applications that don't work reliably. Given two apps, one that copes with NAT and another that doesn't, users will use the one that copes and blame the one that doesn't - even though arguably the failure of the latter app is the fault of the network. Keith From discuss-bounces@apps.ietf.org Wed May 09 09:20:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlm64-0002I2-Qs; Wed, 09 May 2007 09:20:48 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hlm62-0002Ht-8w for discuss-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 09:20:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlm61-0002Hl-Vj for discuss@apps.ietf.org; Wed, 09 May 2007 09:20:45 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlm5z-0004ez-Os for discuss@apps.ietf.org; Wed, 09 May 2007 09:20:45 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Hlm5w-000HPg-M8 for discuss@apps.ietf.org; Wed, 09 May 2007 09:20:41 -0400 Date: Wed, 09 May 2007 09:20:37 -0400 From: John C Klensin To: discuss@apps.ietf.org Subject: FWD: Re: Comments on Unicode Format for Network Interchange Message-ID: <398A6C120C8B166FCBD3BDAF@p3.JCK.COM> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org FYI, in the hope of _not_ having two separate discussions going on. john ---------- Forwarded Message ---------- Date: Wednesday, 09 May, 2007 08:06 -0400 From: John C Klensin To: Doug Ewell Cc: UnicoRe Mailing List , "Magda Danish \\\\(Unicode\\\\)" , Mike Padlipsky , Chris Newman , Lisa Dusseault Subject: Re: Comments on Unicode Format for Network Interchange Doug, Benson, Markus, and L2 and UTC members, My thanks for your input (and for that of Frank Ellermann, which I don't believe was copied to the Unicore/ L2 list -- see below). I appreciate informed and thoughtful comments from any source and, while I cannot speak in any formal way for the IETF, the IETF generally does too. I have two observations on this thread, the second of which is a procedural issue but one that may be of some importance. I apologize in advance for the length of this note, but it seems useful to put both sets of issues to rest. Doug's comments appear to me to exactly reflect the considerations and IETF experience that went into draft-klensin-net-utf8-03c. We tried to review and explain those considerations in the fairly extensive historical material in that document but, in spite of several suggestions that the material was too long and not needed, it apparently was not sufficient to establish the appropriate context. The long experience in the IETF and its predecessor organizations has been that options, and optional and variant behaviors, are a bad idea. If systems sending material on the wire have only a single format to send and systems receiving material need only to verify that format to the degree needed to protect themselves from attack, then we end up with good interoperability and predictable behavior. Optional "do either this or that" behavior creates a situation in which the receiver has to be prepared for every possible combination of options that might be chosen by the sender and, if carried very far, takes takes one down a path toward n-squared behavior, i.e., the need for every system to account for the characteristics of every possible other systems. That way of thinking is completely consistent with the oft-cited "robustness principle": systems are expected to be conservative about what they send and liberal about what they accept". If the designer of a potential receiving system decides to accept variant forms of input --as long as their intended interpretation is clear-- that is usually considered a laudable alternative to generating error messages over such variations. But a sender should never be able to deviate from a standard on the expectation that the receiver will compensate. Even relatively small deviations from this principle have been known to cause problems, often in unexpected places. When an implementer notices (correctly or not) that LF-only, or CR-only, line endings seem to be generally accepted, adjusts for that, and then uses and stores whatever comes off the wire, the problems usually do not show up in that implementation. Instead, they show up with other applications on the same system that can't handle that format in files they are expected to read, files that cannot be properly displayed or printed on the local system, etc. One could argue that the application is correct and everything else is wrong, and we've seen that argument made. However, the better approach seems to be that only a single form comes from (or goes onto) the wire and the receiving application is responsible for getting the "wire" form converted to local norms -- whether those local norms are as trivial as a line-ending convention or conversion to a completely different CCS or coding. So, from our standpoint, the step from a single, on-the-wire, format to variations that can be used as the discretion of the sender is not justifiable on the grounds that it "can" be easily done is a big one, one that requires considerable justification and showing of necessity. That justification has not appeared here and the arguments for a single on-the-wire form seem to prevail. While the issues appear to be more complicated, the same basic reasoning applies to the other restrictions in the draft. Given that Unicode permits, in many cases, alternate ways to represent the same character, some normalization is important, again to prevent N-squared situations. While the choice of NFC follows recommendations we have gotten from UTC leadership, the form could, in principle, have been an IETF-invented NFZZ form: our requirement is that there be only one. And, contrary for Markus's conclusions, there is reason for a MUST: if the sending is _required_ to send NFC, then the receiver merely needs to verify that format to the degree needed to prevent attacks. If it is a SHOULD, then the receiver must be prepared to convert to NFC (or whatever from it needs) from whatever optional form might appear. Similar observations would apply to non-minimal forms of UTF-8 and so on. For CR NUL, I agree that it is an historical wart and that, in a more perfect world, we would ban it entirely. I'll see if that can be reflected better in the text (the text already discourages the use of CR as an overstrike mechanism). However, the strongest argument that is usually made for the use of UTF-8 (rather than other coding forms) is that it is identical to ASCII if only ASCII characters are used. If one is going to accept that coding and compatibility without incurring additional risks, then an ASCII form that is accepted and given an interpretation in NVT (net-ASCII) must have the same interpretation in net-Unicode: if the character sequence can appear on the wire, the alternative is an "everyone makes up their own interpretation". Of course, if NFC simply removed the NUL character from a data stream, there would be no problem. But it doesn't (perhaps that could be turned into an argument for an IETF-produced normalization form, but I certainly won't make it). The restriction to Unicode 3.2 and later is related to a different aspect of the above situation and, ironically, an action taken by (then) X3L2 almost 40 years ago. Incompatibilities were introduced into Unicode, and into NFC, between 2.0 and 3.2. Implementations that conform to 2.0 only may be incompatible with the IETF definition of UTF-8 and other protocols and may not normalize in a completely compatible way. So, absent both an argument compelling enough to require that receivers make allowances for different versions and a clear and non-heuristic method for telling which version is in use, it appears rational to draw the line at 3.2 (or, were it not for a standard or two that depends on 3.2, even later). The irony, which seems worth mentioning because it might be instructive, is that X3L2 changed the definition of "new line" after X3.4-1968 was published, permitting alternate interpretations. The reaction of ASCII-dependent systems in what later became the ARPANET community was to make very specific rules about the interpretation and use of CR and LF and eventually to carry a standardized form of those rules into the ARPANET and Internet. The Internet's definition of ASCII was also frozen with the 1968 version so as to avoid further surprises of this type. Finally, I want to come back to the procedural issue while stressing that this is a personal opinion that may or may not be consistent with whatever position the IETF would take if asked. While I know of nothing that can prevent L2, or the broader Unicode community, from discussing whatever they like, I note that: * there appears to be nothing in the L2 charter or project list that provides for formally commenting on this, or any other, proposal about how one of its standards should be applied. * the IETF has not asked L2, or UTC, for an opinion on this subject, nor does there appear to be an issue requiring clarification or other maintenance of any standard under L2's scope. * My recollection is that INCITS procedures and ANSI guidelines generally discourage such out-of-charter discussions in a formal TC context, placement on the agenda, issuance of formal documents, and, especially, issuance of TC opinions. * There is no liaison between L2 and the IETF that would justify formal L2 comments on an IETF work item. The most recent L2 annual report (INCITS/in050401 and almost two years out of date) doesn't even mention the IETF or IETF work -- any more than it mentions any other set of applications of Unicode or other L2 work. * The draft specifically identifies a mailing list on which discussions of the draft are invited. Holding a semi-closed discussion on another list, presumably with the intention of producing a formal statement (I can't tell exactly what is intended because the L2 agenda is password-protected, which I believe violates INCITS rules), is not helpful and is the sort of thing that has led to misunderstandings between IETF-related bodies and the Unicode Consortium in the past. I would suggest that further discussion take place on the requested mailing list. regards and, again, thanks for the input, john --On Wednesday, 09 May, 2007 00:23 -0700 Doug Ewell wrote: > Please add this to the agenda for UTC #111, for discussion in > response to agenda item B.5.2. > > L2/07-126, written by Markus Scherer, proposes some changes to > the Internet-Draft "draft-klensin-net-utf8-03", by John > Klensin and Michael Padlipsky. This Internet-Draft proposes > to replace the venerable "network ASCII" standard with a > tightly defined profile of UTF-8, including NFC normalization > and CRLF line endings. > > In particular, L2/07-126 proposes that the requirement to end > lines of text with CRLF be relaxed to permit "bare CR" and > "bare LF" as well. The document states, "We believe that > single CR and LF are common because of implementation practice > on a variety of platforms, and that it is both unrealistic and > unnecessary to try to legislate them away." > > In fact, the concept of "network ASCII," and the purpose of > the present Internet-Draft, is to do just that: "legislate" a > specific profile of ASCII and UTF-8, respectively, that can be > expected to maximize interoperability. There is indeed a > large number of text files on the Internet that use "bare CR" > or "bare LF," just as there is a large number of files encoded > in ISO 8859-1 or other character sets, but this potentially > troublesome diversity is exactly why a standard format is > being proposed. > > I recommend that the proposal to "legislate" the use of CRLF > be retained in the Internet-Draft. Furthermore, I suggest > that the authors of the I-D withdraw their continued support > in "network Unicode" for the obscure "CR NUL" sequence, which > means "carriage return without line feed" and was formerly > used as a hack to create overstruck sequences. This mechanism > is completely unnecessary in a text-transport mechanism that > supports Unicode, with its rich support for "proper" combining > characters, and is unlikely to be handled correctly by most > text engines in any case. > > L2/07-126 also recommends that the control code HT (horizontal > tabulation, U+0009) be permitted under Section 2.2 of the > "network Unicode" definition. > > I recommend that the control code FF (form feed, U+000C) be > likewise permitted. The form feed function is well known and > well defined in almost all printing functions, and all RFCs > issued in modern times use FF to separate pages. It would > ironic indeed for the Internet-Draft to retain the requirement > that form feeds "SHOULD NOT be used unless required by > exceptional circumstances" while advancing toward publication > as an RFC, complete with form feeds! > > I have no objection to the other proposals set forth in > L2/07-126. > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN > # 14 > http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > ---------- End Forwarded Message ---------- From discuss-bounces@apps.ietf.org Wed May 09 10:23:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hln4Y-0007KZ-EP; Wed, 09 May 2007 10:23:18 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hln4X-0007GF-Jn for discuss-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 10:23:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hln4X-0007Ei-9s for discuss@apps.ietf.org; Wed, 09 May 2007 10:23:17 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hln4W-0001as-2c for discuss@apps.ietf.org; Wed, 09 May 2007 10:23:17 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 681331EE188; Wed, 9 May 2007 10:23:15 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yQ8SK68enhf; Wed, 9 May 2007 10:23:10 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id EF4F81EE1BD; Wed, 9 May 2007 10:23:09 -0400 (EDT) Message-ID: <4641D94C.9070304@cs.utk.edu> Date: Wed, 09 May 2007 10:23:08 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Tony Finch Subject: Re: sockets APIs extensions for Host Identity Protocol References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> In-Reply-To: X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >> Fourth, for a variety of reasons, DNS names are not and have never been >> adequate as general purpose endpoint identifiers, and this situation is >> getting worse rather than better. One reason is that DNS names are not >> equivalent to host names, and emphatically not equivalent to >> distinguished host names, and haven't been so at least since the web >> came into existence. A given DNS name might be bound to a single host, >> multiple hosts having more-or-less equivalent function, a service, a >> community of users, or whatever; the binding might be stable or >> ephemeral; and the name might or might not be suitable as a >> distinguished name (one chosen preferentially over others for use in >> indicating that host, group of hosts, service, whatever). There's no >> way to tell. >> > > All of this is true for IP addresses as well. > good point. though if you collect multiple hosts under the same IP address, without considering how this will affect the apps that run on those hosts, you pretty much deserve to lose. neither DNS names nor IP addresses work very well as endpoint identifiers. Keith From discuss-bounces@apps.ietf.org Wed May 09 13:27:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlpwX-0004oY-Fn; Wed, 09 May 2007 13:27:13 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HlpwV-0004oQ-LT for discuss-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 13:27:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlpwV-0004oI-C1 for discuss@apps.ietf.org; Wed, 09 May 2007 13:27:11 -0400 Received: from sparkle.rodents.montreal.qc.ca ([216.46.5.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlpwT-0001ph-U9 for discuss@apps.ietf.org; Wed, 09 May 2007 13:27:11 -0400 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id NAA22503; Wed, 9 May 2007 13:27:08 -0400 (EDT) From: der Mouse Message-Id: <200705091727.NAA22503@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Wed, 9 May 2007 13:21:45 -0400 (EDT) To: discuss@apps.ietf.org Subject: Re: sockets APIs extensions for Host Identity Protocol In-Reply-To: <20070509121703.GA21070@nic.fr> References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > I strongly object to the idea of application programmers dealing with > NAT, IPv4 vs. IPv6 or source address selection for the eternity. I object to their having to deal with those issues. I also object to their being prevented from dealing with them, even if only because of diagnostic applications. > Applications should not have to be "ported to IPv6". Diagnostic applications aside, I mostly agree. > They should work the same with both level-3 protocols (and, indeed, > they do, in every language but C). Oh, nonsense. Not every non-C language encapsulates those details sufficiently to keep applications away from them. I've seen perl code, for example, that does pack() and unpack() to construct memory blobs equivalent to structs sockaddr_in (and which thus needs to be changed to do likewise for sockaddr_in6, to be v6-ready). > I also really doubt that the typical application programmer is able > to do a better job than the kernel / libraries to, choose the source > address or other level-3 features. The typical application programmer, perhaps. But there certainly are application programmers cokmpetent to manage such details. > Plus, IMHO, if someone must influence this selection, it should be > the system and network administrator, not the application programmer. Sometimes it has to be the application coder, as creator of the user's proxy to the network. Some applications are suitable for hiding the network's complexity, true, but some aren't. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From discuss-bounces@apps.ietf.org Wed May 09 15:47:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hls86-0001El-CA; Wed, 09 May 2007 15:47:18 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hls85-0001EY-AW for discuss-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 15:47:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hls85-0001EO-0P for discuss@apps.ietf.org; Wed, 09 May 2007 15:47:17 -0400 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hls83-0005Q7-Nc for discuss@apps.ietf.org; Wed, 09 May 2007 15:47:16 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id B59F0240822; Wed, 9 May 2007 21:47:11 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id DBA291170A; Wed, 9 May 2007 21:43:09 +0200 (CEST) Date: Wed, 9 May 2007 21:43:09 +0200 From: Stephane Bortzmeyer To: Keith Moore Subject: Re: sockets APIs extensions for Host Identity Protocol Message-ID: <20070509194309.GA32096@sources.org> References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4641CA52.70504@cs.utk.edu> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Wed, May 09, 2007 at 09:19:14AM -0400, Keith Moore wrote a message of 129 lines which said: > First is that there will always be some applications (such as > diagnostic tools) that need to know more about the network, so it is > necessary to have an API that allows those applications to function. We all (I believe) agree that we need a low-level API, mostly, as you said, for debugging / monitoring / teaching purposes and for some optimizations in very specific applications. But this is not the point to discuss since we *already* have this API, the sockets API, and it works. What we discuss is a *new* API, a high-level one, not meant to replace the low-level one for *everything* but for most applications. > Fourth, for a variety of reasons, DNS names are not and have never > been adequate as general purpose endpoint identifiers, This is a sensible explanation but, if we agree with it, it only means that we rule out DNS for the identification of the new high-level "connection objects". This does not mean that the whole idea of a high-level API is wrong. > I guess you wouldn't use Skype then, Right. > preferring to spend lots of money on international phone calls. I use email. I may switch to SIP or Jabber. I did not find a RFC describing Skype. From discuss-bounces@apps.ietf.org Wed May 09 15:57:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlsHh-0005LC-6Y; Wed, 09 May 2007 15:57:13 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HlsHf-0005L0-F5 for discuss-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 15:57:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlsHf-0005Kr-5d for discuss@apps.ietf.org; Wed, 09 May 2007 15:57:11 -0400 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlsHd-00080R-Sq for discuss@apps.ietf.org; Wed, 09 May 2007 15:57:11 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 785C9240822; Wed, 9 May 2007 21:57:08 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id C858011729; Wed, 9 May 2007 21:53:19 +0200 (CEST) Date: Wed, 9 May 2007 21:53:19 +0200 From: Stephane Bortzmeyer To: der Mouse Subject: Re: sockets APIs extensions for Host Identity Protocol Message-ID: <20070509195319.GA3926@sources.org> References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <200705091727.NAA22503@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200705091727.NAA22503@Sparkle.Rodents.Montreal.QC.CA> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Wed, May 09, 2007 at 01:21:45PM -0400, der Mouse wrote a message of 38 lines which said: > > They should work the same with both level-3 protocols (and, > > indeed, they do, in every language but C). > > Oh, nonsense. Simple exaggeration. > Not every non-C language encapsulates those details sufficiently to > keep applications away from them. I've seen perl code, OK, OK, not all languages are better than C in that respect. But I do not want to mention only Java, as some people keep repeating. Many languages offer a similar high-level API (Python, Lua, Haskell, Ruby, ...). From discuss-bounces@apps.ietf.org Thu May 10 11:07:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmAEo-0006JF-K6; Thu, 10 May 2007 11:07:26 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HmAEn-0006Il-2i for discuss-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 11:07:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmAEm-0006Ic-PV for discuss@apps.ietf.org; Thu, 10 May 2007 11:07:24 -0400 Received: from ka.cs.utk.edu ([160.36.56.221]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmAEl-0002QU-D9 for discuss@apps.ietf.org; Thu, 10 May 2007 11:07:24 -0400 Received: from localhost (localhost [127.0.0.1]) by ka.cs.utk.edu (Postfix) with ESMTP id 6EC41CB7BF; Thu, 10 May 2007 11:07:22 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from ka.cs.utk.edu ([127.0.0.1]) by localhost (ka.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dpcp0C-zI4Bm; Thu, 10 May 2007 11:06:50 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by ka.cs.utk.edu (Postfix) with ESMTP id 71ED7CB827; Thu, 10 May 2007 11:06:29 -0400 (EDT) Message-ID: <464334F4.6020303@cs.utk.edu> Date: Thu, 10 May 2007 11:06:28 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Stephane Bortzmeyer Subject: Re: sockets APIs extensions for Host Identity Protocol References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <20070509194309.GA32096@sources.org> In-Reply-To: <20070509194309.GA32096@sources.org> X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >> First is that there will always be some applications (such as >> diagnostic tools) that need to know more about the network, so it is >> necessary to have an API that allows those applications to function. >> > > We all (I believe) agree that we need a low-level API, mostly, as you > said, for debugging / monitoring / teaching purposes and for some > optimizations in very specific applications. > > But this is not the point to discuss since we *already* have this API, > the sockets API, and it works. > the sockets API is not sufficient even as a low-level API. we're going to need extensions to both network protocols and the sockets API to function effectively in a world where hosts have multiple addresses and it matters which address you use. > What we discuss is a *new* API, a high-level one, not meant to replace > the low-level one for *everything* but for most applications. > we do need a high-level API, but such an API still needs to be able to accept application preferences and requirements for that particular socket. I generally find that assumptions about "most applications" turn out to be wrong - if not in the present, than in the in the near future. >> Fourth, for a variety of reasons, DNS names are not and have never >> been adequate as general purpose endpoint identifiers, >> > > This is a sensible explanation but, if we agree with it, it only means > that we rule out DNS for the identification of the new high-level > "connection objects". This does not mean that the whole idea of a > high-level API is wrong. > the idea is fine, but the devil is in the implementation details. it's easy to design a high-level API that works for a limited number of cases, very difficult to make one that works well in practice for everyone in the diversity of the Internet. > I use email. I may switch to SIP or Jabber. I did not find a RFC > describing Skype. > I'm quite willing to learn lessons from their example even if they don't document their protocol in an RFC. Keith From discuss-bounces@apps.ietf.org Thu May 10 14:40:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmDYf-0002WG-KW; Thu, 10 May 2007 14:40:09 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HmDYe-0002WB-V5 for discuss-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 14:40:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmDYe-0002W3-LX for discuss@apps.ietf.org; Thu, 10 May 2007 14:40:08 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmDYd-0004xX-60 for discuss@apps.ietf.org; Thu, 10 May 2007 14:40:08 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 36F912D0C; Thu, 10 May 2007 21:40:06 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070322 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070322 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 980F32D0A; Thu, 10 May 2007 21:40:05 +0300 (EEST) Date: Thu, 10 May 2007 21:40:05 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Keith Moore Subject: Re: sockets APIs extensions for Host Identity Protocol In-Reply-To: <4641D94C.9070304@cs.utk.edu> Message-ID: References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <4641D94C.9070304@cs.utk.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Wed, 9 May 2007, Keith Moore wrote: Hi, >>> Fourth, for a variety of reasons, DNS names are not and have never been >>> adequate as general purpose endpoint identifiers, and this situation is >>> getting worse rather than better. One reason is that DNS names are not >>> equivalent to host names, and emphatically not equivalent to >>> distinguished host names, and haven't been so at least since the web >>> came into existence. A given DNS name might be bound to a single host, >>> multiple hosts having more-or-less equivalent function, a service, a >>> community of users, or whatever; the binding might be stable or >>> ephemeral; and the name might or might not be suitable as a >>> distinguished name (one chosen preferentially over others for use in >>> indicating that host, group of hosts, service, whatever). There's no >>> way to tell. >> >> All of this is true for IP addresses as well. >> > > good point. though if you collect multiple hosts under the same IP > address, without considering how this will affect the apps that run on > those hosts, you pretty much deserve to lose. > > neither DNS names nor IP addresses work very well as endpoint identifiers. thanks for the good points! However, it is not still clear to me what to do in the case of HIP aware applications. I hope we can agree that something needs to be done at the sockets API layer? At the minimum, we want to make the application to use HIP (either by using HITs directly or indirectly through locally-scoped identifiers), and provide a way for the application to determine that it is using HIP. My exact question is that what to put into the socket address structures when we have HIP-aware applications. Based on the discussion, I think we can leave socket address structures based on DNS names out of the scope and concentrate on two alternatives: globally scoped HITs and locally scoped idenfiers (endpoint descriptors). The use of globally-scoped HITs has the following trade-offs: + No extra translation step from local id to global id + Smaller transition step to convert a legacy app to a HIP aware app? - Opportunistic HIP mode, where the server's HIT is not known before hand, will require a locally-scoped identifier anyway. This is similar to IN6ADDR_ANY, but it is used for the remote host, i.e., connect(UNKOWN_HIT) where only the locator is known. - No future proofing against the HIT size Locally-scoped identifiers have the reverse properties: - Extra translation step from local id to global id - Bigger transition step to convert a legacy app to a HIP aware app? + All identifiers are of the same type (also in opportunistic HIP mode) + Future proofing against changes in the HIT size If you had to choose between these two, what would you choose and why? Do the proposed trade-offs make sense and would have something to add? P.S. Please notice that the HITs are basically "free" of the NAT burden because they are globally scoped, end-to-end identifiers. -- Miika Komu http://www.iki.fi/miika/ From discuss-bounces@apps.ietf.org Thu May 10 14:48:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmDgo-0007Y4-3O; Thu, 10 May 2007 14:48:34 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HlSpT-0000oK-Fe for discuss-confirm+ok@megatron.ietf.org; Tue, 08 May 2007 12:46:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlSpT-0000oA-5w for discuss@apps.ietf.org; Tue, 08 May 2007 12:46:23 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlSpH-0008LP-U1 for discuss@apps.ietf.org; Tue, 08 May 2007 12:46:23 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l48Gk9QQ028957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 May 2007 09:46:10 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l48Gk8DH003445; Tue, 8 May 2007 09:46:09 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l48Gjdv3001656; Tue, 8 May 2007 09:45:47 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 09:43:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: sockets APIs extensions for Host Identity Protocol Date: Tue, 8 May 2007 09:43:45 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D040492F2@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <31BC7A8C1A51004A84E08DEF@[10.1.110.5]> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: sockets APIs extensions for Host Identity Protocol Thread-Index: AceQ7xcdhsjtI3MlRdGtmzkgAaIFsAAnuoYQ From: "Henderson, Thomas R" To: "Chris Newman" , "Miika Komu" , X-OriginalArrivalTime: 08 May 2007 16:43:46.0102 (UTC) FILETIME=[0BB41D60:01C79190] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-Mailman-Approved-At: Thu, 10 May 2007 14:48:33 -0400 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org =20 > -----Original Message----- > From: Chris Newman [mailto:Chris.Newman@Sun.COM]=20 > Sent: Monday, May 07, 2007 2:32 PM > To: Miika Komu; discuss@apps.ietf.org > Cc: Henderson, Thomas R > Subject: Re: sockets APIs extensions for Host Identity Protocol >=20 > Speaking as a technical participant, not as an area director... >=20 > Application software wants to work with strings. When I want=20 > to make a network=20 > connection, I have a string which says what I want to connect=20 > to. It might be=20 > a DNS name, an IPv4 address literal, and IPv6 address=20 > literal, the field after=20 > the "//" in a URL or whatever the string format for a HIP=20 > endpoint is going to=20 > be. As an application developer I don't want to care what=20 > that string means.=20 > I might want a way to turn that string into an opaque object=20 > (or objects) and=20 > back (with a timeout) and then use that opaque object in=20 > something equivalent=20 > to connect and/or bind. >=20 > I also want a way to enumerate the string representations of=20 > the local=20 > interfaces on a server so that I can offer the administrator=20 > a choice of which=20 > interface(s) the listen ports bind to. I don't want to care=20 > whether those are=20 > IPv4, IPv6 or HIP or something else. >=20 > The only reason I might care what the string or opaque object=20 > refers to is for=20 > debugging/logging/diagnostic purposes. >=20 > If I change my "connectbyname" code again, I will change it=20 > once more to use a=20 > new OS API that hides all the v4 vs. v6 vs. HIP vs. whatever=20 > junk, preferably=20 > to something much simpler than the code today. If such an=20 > API isn't produced,=20 > I will be very reluctant to change that code no matter how=20 > cool HIP might or=20 > might not be. Chris,=20 Is the IETF in the business of defining this new API? Or is the IETF scope limited to sockets, and the APIs that you seek are defined by library and OS developers? As a HIP WG participant, I see that there has been a history of RFCs for sockets API extensions (2292, 2960, 4584, etc.). We could do a similar one for HIP, but Miika has proposed that we go for a more future-proof API and build in some abstraction. It seems to me that there is support for defining such an API and it has already been done successfully for Java. (note also that there has been discussion on the RAM list this week on this topic). Tom From discuss-bounces@apps.ietf.org Thu May 10 14:48:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmDgo-0007YM-7d; Thu, 10 May 2007 14:48:34 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HlXOC-00024p-ML for discuss-confirm+ok@megatron.ietf.org; Tue, 08 May 2007 17:38:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlXOC-00024f-Cn for discuss@apps.ietf.org; Tue, 08 May 2007 17:38:32 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlXO8-0006yQ-LK for discuss@apps.ietf.org; Tue, 08 May 2007 17:38:32 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 05D472CF1; Wed, 9 May 2007 00:38:25 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070322 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070322 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 424282CEF; Wed, 9 May 2007 00:38:24 +0300 (EEST) Date: Wed, 9 May 2007 00:38:24 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Stephane Bortzmeyer Subject: Re: sockets APIs extensions for Host Identity Protocol In-Reply-To: <20070507082737.GB21759@nic.fr> Message-ID: References: <20070507082737.GB21759@nic.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-Mailman-Approved-At: Thu, 10 May 2007 14:48:33 -0400 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Mon, 7 May 2007, Stephane Bortzmeyer wrote: Hi Stephane and thanks for your comments, > On Fri, May 04, 2007 at 06:28:30PM +0300, > Miika Komu wrote > a message of 27 lines which said: > >> One could conceive that such a level of indirection could be used >> more generally outside of HIP, to enable applications to be more >> compatible across IP versions, for instance. > > One important thing: this is only for the C programming language. In > most (all?) other languages, programmers no longer handle directly IP > addresses and thus are shielded from things like IPv4 vs. IPv6 or > addresses vs. handles. Yes, that is true. >> This latter observation makes me wonder whether there have been such >> considerations previously in the applications area? > > The big advice should be: use a high-level language (or, in C, a > high-level library, like Neon - http://www.webdav.org/neon/ - or cURL > - http://curl.haxx.se/) and you're safe from the changes in IETF > fashions. The higher-level languages are always based on the C-language sockets API. Would it make sense to make the modification to a single place (sockets API) rather than all of the present programming language implementations? The latter is, of course, better than modifying all applications. -- Miika Komu http://www.iki.fi/miika/ From discuss-bounces@apps.ietf.org Thu May 10 14:48:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmDgo-0007Zo-EE; Thu, 10 May 2007 14:48:34 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HlY3X-0005X7-Kv for discuss-confirm+ok@megatron.ietf.org; Tue, 08 May 2007 18:21:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlY3X-0005Wz-BV for discuss@apps.ietf.org; Tue, 08 May 2007 18:21:15 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlY3U-0002pT-Ph for discuss@apps.ietf.org; Tue, 08 May 2007 18:21:15 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 15A612C66; Wed, 9 May 2007 01:21:08 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070322 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070322 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 813362C41; Wed, 9 May 2007 01:21:07 +0300 (EEST) Date: Wed, 9 May 2007 01:21:07 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: der Mouse Subject: Re: sockets APIs extensions for Host Identity Protocol In-Reply-To: <200705072216.SAA06179@Sparkle.Rodents.Montreal.QC.CA> Message-ID: References: <31BC7A8C1A51004A84E08DEF@[10.1.110.5]> <200705072216.SAA06179@Sparkle.Rodents.Montreal.QC.CA> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe X-Mailman-Approved-At: Thu, 10 May 2007 14:48:33 -0400 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Mon, 7 May 2007, der Mouse wrote: Hi and thanks for you comments, >> Application software wants to work with strings. [...] > >> If I change my "connectbyname" code again, I will change it once more >> to use a new OS API that hides all the v4 vs. v6 vs. HIP vs. whatever >> junk, preferably to something much simpler than the code today. > > Something wrong with getaddrinfo()? It certainly could use something > HIPish under the hood, if some implementor decided to. Yes, I think the changes in the native HIP API draft are not visible at all to higher-level "connectbyname" callers. However, the C-based sockets API is used by all of the higher-level libraries and languages... >>> A potential benefit of the handles is that it would make the API >>> future-proof againts changes to the HIT size. > > getaddrinfo() already is...or at least, it is when used correctly, and > in this respect it's easier to use it correctly than incorrecetly > (which is about all you can expect). It's a slightly broken API, true, > but the problems with it are not in areas that any putative HIP/HIT > stuff would fix. I am curious. Even though this is irrelevant for the discussion, can be more specific on what is broken with getaddrinfo? >>> Similarly, one might argue that the IPv6 transition would have been >>> a lot easier for applications if the concept of endpoint descriptor >>> were already available for the past twenty years; > > That concept *has* been available for the past twenty years; it's > called a "socket". What hasn't been available is a socket > implementation that doesn't expose the underlying addressing details to > the application. This could be - and arguably should be - fixed > entirely under the socket-layer hood, not by inventing new protocols > and exposing *them* to the application. I speculate that the major > reason this hasn't been done is tradition - sockets have traditionally > been a fairly direct interface into the kernel, and preserving that > while presenting this kind of socket interface is relatively hard. Yes, I agree that the socket would do the trick and would provide enough indirection. As you said, the problem is with the tradition of exposing the addresses directly to the application. To solve this problem properly, we need a "clean slate" approach for the APIs. However, I am not sure if the sockets API level is proper place to do this. The draft tries to preserve backwards compability while extending the current sockets API to its limits. The backwards compatibility is handy when porting old sockets API based applications to use the API. The limits are reached by hiding the presentation of identifiers and port numbers behind endpoint descriptors. I am not sure what you meant with protocol, but here I assume you meant PF_SHIM. The new PF_SHIM family was "invented" as a consequence of introducing a new socket address structure for endpoint descriptors. This way, the correct size of the socket structure can be determined. It also makes more sense to have a separate socket handler for endpoint descriptors rather than to mix with IPv4 or IPv6 sockets handlers. -- Miika Komu http://www.iki.fi/miika/ From discuss-bounces@apps.ietf.org Thu May 10 14:48:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmDgo-0007bs-MD; Thu, 10 May 2007 14:48:34 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hlgye-0001bF-DS for discuss-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 03:52:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlgyd-0001b7-UZ for discuss@apps.ietf.org; Wed, 09 May 2007 03:52:47 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlgyc-0002zM-Ix for discuss@apps.ietf.org; Wed, 09 May 2007 03:52:47 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 020C52CFE; Wed, 9 May 2007 10:52:45 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070322 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070322 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 615602CDF; Wed, 9 May 2007 10:52:45 +0300 (EEST) Date: Wed, 9 May 2007 10:52:45 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Keith Moore Subject: Re: sockets APIs extensions for Host Identity Protocol In-Reply-To: <46413DD7.8020702@cs.utk.edu> Message-ID: References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-Mailman-Approved-At: Thu, 10 May 2007 14:48:33 -0400 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Tue, 8 May 2007, Keith Moore wrote: Hi, > Stephane Bortzmeyer wrote: >>> One could conceive that such a level of indirection could be used >>> more generally outside of HIP, to enable applications to be more >>> compatible across IP versions, for instance. >>> >> >> One important thing: this is only for the C programming language. In >> most (all?) other languages, programmers no longer handle directly IP >> addresses and thus are shielded from things like IPv4 vs. IPv6 or >> addresses vs. handles. > > In those cases, the programmers are also crippled and prevented from > dealing effectively with various cases that are now increasingly common > in the Intenet today: NATs, multiple addresses for source and > destination (not all of which work equally well), IPv4 vs IPv6 (for > which the default address selection rules are woefully inadequate), > multi-faced DNS, LLMNR, etc. Yes, we need both simple and advanced interfaces and let the application developer choose what ever that is required for the application. This considers especially multihoming: http://www.ietf.org/internet-drafts/draft-ietf-shim6-multihome-shim-api-02.txt For the NAT traversal, my opinion is that we should should avoid making the applications NAT aware because would just too much unnecessarily redundant code around. This is approach taken in the NAT traversal draft (beware, the protocol mechanism is going to change in the next version radically): http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-01.txt -- Miika Komu http://www.iki.fi/miika/ From discuss-bounces@apps.ietf.org Thu May 10 14:48:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmDgo-0007dy-VK; Thu, 10 May 2007 14:48:35 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HlmZe-0005kd-Q7 for discuss-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 09:51:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlmZe-0005kV-Gf for discuss@apps.ietf.org; Wed, 09 May 2007 09:51:22 -0400 Received: from ppsw-2.csi.cam.ac.uk ([131.111.8.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlmZc-0003Mo-6r for discuss@apps.ietf.org; Wed, 09 May 2007 09:51:22 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:45579) by ppsw-2.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.152]:25) with esmtpa (EXTERNAL:fanf2) id 1HlmYp-0000NB-8e (Exim 4.63) (return-path ); Wed, 09 May 2007 14:50:31 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1HlmYp-000542-KC (Exim 4.54) (return-path ); Wed, 09 May 2007 14:50:31 +0100 Date: Wed, 9 May 2007 14:50:31 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Keith Moore Subject: Re: sockets APIs extensions for Host Identity Protocol In-Reply-To: <4641CA52.70504@cs.utk.edu> Message-ID: References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Thu, 10 May 2007 14:48:33 -0400 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Wed, 9 May 2007, Keith Moore wrote: > > Fourth, for a variety of reasons, DNS names are not and have never been > adequate as general purpose endpoint identifiers, and this situation is > getting worse rather than better. One reason is that DNS names are not > equivalent to host names, and emphatically not equivalent to > distinguished host names, and haven't been so at least since the web > came into existence. A given DNS name might be bound to a single host, > multiple hosts having more-or-less equivalent function, a service, a > community of users, or whatever; the binding might be stable or > ephemeral; and the name might or might not be suitable as a > distinguished name (one chosen preferentially over others for use in > indicating that host, group of hosts, service, whatever). There's no > way to tell. All of this is true for IP addresses as well. Tony. -- f.a.n.finch http://dotat.at/ NORTH FITZROY SOLE: SOUTHWESTERLY 6 TO GALE 8. ROUGH OR VERY ROUGH. RAIN OR DRIZZLE. MODERATE OR POOR. From discuss-bounces@apps.ietf.org Thu May 10 14:57:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmDpg-0006as-Sf; Thu, 10 May 2007 14:57:44 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HmDpe-0006Tq-WC for discuss-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 14:57:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmDpe-0006So-Lr for discuss@apps.ietf.org; Thu, 10 May 2007 14:57:42 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmDpd-0006LT-65 for discuss@apps.ietf.org; Thu, 10 May 2007 14:57:42 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 87B8A1EE190; Thu, 10 May 2007 14:57:40 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQ0cR-pfjLVM; Thu, 10 May 2007 14:57:21 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id D40A11EE1C7; Thu, 10 May 2007 14:57:20 -0400 (EDT) Message-ID: <46436B10.5090706@cs.utk.edu> Date: Thu, 10 May 2007 14:57:20 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Miika Komu Subject: Re: sockets APIs extensions for Host Identity Protocol References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <4641D94C.9070304@cs.utk.edu> In-Reply-To: X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > My exact question is that what to put into the socket address > structures when we have HIP-aware applications. Based on the > discussion, I think we can leave socket address structures based on > DNS names out of the scope and concentrate on two alternatives: > globally scoped HITs and locally scoped idenfiers (endpoint descriptors). > > The use of globally-scoped HITs has the following trade-offs: > + No extra translation step from local id to global id > + Smaller transition step to convert a legacy app to a HIP aware app? > - Opportunistic HIP mode, where the server's HIT is not known before > hand, > will require a locally-scoped identifier anyway. This is similar to > IN6ADDR_ANY, but it is used for the remote host, i.e., > connect(UNKOWN_HIT) where only the locator is known. > - No future proofing against the HIT size > > Locally-scoped identifiers have the reverse properties: > - Extra translation step from local id to global id > - Bigger transition step to convert a legacy app to a HIP aware app? > + All identifiers are of the same type (also in opportunistic HIP mode) > + Future proofing against changes in the HIT size > > If you had to choose between these two, what would you choose and why? > Do the proposed trade-offs make sense and would have something to add? offhand, I think you need to support both. HITs aren't very useful to apps unless they are visible to them and globally-scoped. HIP is still useful without HIT visibility, but less useful. From discuss-bounces@apps.ietf.org Thu May 10 15:04:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmDwe-0002wZ-IC; Thu, 10 May 2007 15:04:56 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HmDwd-0002tg-Bg for discuss-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 15:04:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmDwd-0002tY-29 for discuss@apps.ietf.org; Thu, 10 May 2007 15:04:55 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmDwb-0007Wi-Nj for discuss@apps.ietf.org; Thu, 10 May 2007 15:04:55 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 465E72D0E; Thu, 10 May 2007 22:04:53 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070322 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070322 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 9A4BC2D0C; Thu, 10 May 2007 22:04:52 +0300 (EEST) Date: Thu, 10 May 2007 22:04:52 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Keith Moore Subject: Re: sockets APIs extensions for Host Identity Protocol In-Reply-To: <46436B10.5090706@cs.utk.edu> Message-ID: References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <4641D94C.9070304@cs.utk.edu> <46436B10.5090706@cs.utk.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Thu, 10 May 2007, Keith Moore wrote: >> My exact question is that what to put into the socket address >> structures when we have HIP-aware applications. Based on the >> discussion, I think we can leave socket address structures based on >> DNS names out of the scope and concentrate on two alternatives: >> globally scoped HITs and locally scoped idenfiers (endpoint descriptors). >> >> The use of globally-scoped HITs has the following trade-offs: >> + No extra translation step from local id to global id >> + Smaller transition step to convert a legacy app to a HIP aware app? >> - Opportunistic HIP mode, where the server's HIT is not known before >> hand, >> will require a locally-scoped identifier anyway. This is similar to >> IN6ADDR_ANY, but it is used for the remote host, i.e., >> connect(UNKOWN_HIT) where only the locator is known. >> - No future proofing against the HIT size >> >> Locally-scoped identifiers have the reverse properties: >> - Extra translation step from local id to global id >> - Bigger transition step to convert a legacy app to a HIP aware app? >> + All identifiers are of the same type (also in opportunistic HIP mode) >> + Future proofing against changes in the HIT size >> >> If you had to choose between these two, what would you choose and why? >> Do the proposed trade-offs make sense and would have something to add? > > offhand, I think you need to support both. HITs aren't very useful to > apps unless they are visible to them and globally-scoped. HIP is still > useful without HIT visibility, but less useful. It does not mean that the HIT fingerprint, or preferably even the corresponding public key, are completely invisible to the application with locally-scoped identifiers. It is just a question of an extra function call that translates the local-scope identifier to the desired format (HIT or public key). -- Miika Komu http://www.iki.fi/miika/ From discuss-bounces@apps.ietf.org Thu May 10 17:25:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmG8F-0007dq-Gb; Thu, 10 May 2007 17:25:03 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HmG8E-0007df-9U for discuss-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 17:25:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmG8D-0007dM-L9; Thu, 10 May 2007 17:25:01 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmG8C-0002hy-6n; Thu, 10 May 2007 17:25:01 -0400 Received: from [192.168.1.200] ((unknown) [24.182.55.218]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 10 May 2007 22:24:58 +0100 X-SMTP-Protocol-Errors: NORDNS Mime-Version: 1.0 (Apple Message framework v752.3) References: <7BD54F47-0C51-43D5-B9D8-39013E5AFE57@Isode.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <796792D2-324C-4342-9E85-2A1094BAF573@Isode.com> Content-Transfer-Encoding: 7bit From: Kurt Zeilenga Subject: Fwd: [ldapext] LDAP BoF at IETF#69? Date: Thu, 10 May 2007 14:24:53 -0700 To: ietf-ldapbis@openldap.org, directory@apps.ietf.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org For discussion on the ldapext@ietf.org list... -- Kurt Begin forwarded message: > From: Kurt Zeilenga > Date: May 5, 2007 5:25:23 AM PDT > To: Ldapext > Subject: [ldapext] LDAP BoF at IETF#69? > List-Id: LDAP Extension Working Group > > It seems to me that it might be appropriate to organize a BoF (bar > or actual) > at IETF#69 to discuss specification and standardization of various > LDAP > extensions, determine whether a WG is needed/desired to further this > engineering, and, if so, rough out a charter proposal. > > Some work candidates (in no particular order): > > Internet Naming Plan (update) > Distributed Operations (chaining) > Distributed Authentication > Use of DNS in Internet directories (DNS SRV) > Password Policy administrative model and notifications > Transactions > DAP/LDAP alignment > Regular Expression Matching Rule > > If there is sufficient interested shown on this list (and > elsewhere), I > would be willing to put together a BoF proposal for AD/IESG > consideration. > So, please let your views on whether such a BoF should be held known. > > You're also more than welcomed to name other work candidates, and > comment > on those that I enumerated. > > Also, those willing to serve as a BOF chair should drop me a note. > > Regards, Kurt > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext From discuss-bounces@apps.ietf.org Fri May 11 01:00:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmNFE-0003u9-Dq; Fri, 11 May 2007 01:00:44 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HmNFD-0003u4-PT for discuss-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 01:00:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmNFD-0003tw-77 for discuss@apps.ietf.org; Fri, 11 May 2007 01:00:43 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmNFB-0004o7-V3 for discuss@apps.ietf.org; Fri, 11 May 2007 01:00:43 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 770121EE1CA; Fri, 11 May 2007 01:00:41 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqxLr-SwOjEk; Fri, 11 May 2007 01:00:36 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 7F3041EE1AC; Fri, 11 May 2007 01:00:36 -0400 (EDT) Message-ID: <4643F873.3000501@cs.utk.edu> Date: Fri, 11 May 2007 01:00:35 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Miika Komu Subject: Re: sockets APIs extensions for Host Identity Protocol References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <4641D94C.9070304@cs.utk.edu> <46436B10.5090706@cs.utk.edu> In-Reply-To: X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >> offhand, I think you need to support both. HITs aren't very useful to >> apps unless they are visible to them and globally-scoped. HIP is still >> useful without HIT visibility, but less useful. > > It does not mean that the HIT fingerprint, or preferably even the > corresponding public key, are completely invisible to the application > with locally-scoped identifiers. It is just a question of an extra > function call that translates the local-scope identifier to the > desired format (HIT or public key). It strikes me that if I'm using opportunistic HIP, then I probably want to use normal sockaddr_in* structures and do a setsockopt() that says "give me HIP if both ends support it" before doing connect() or listen(). In that case I'd want getpeername() to still return the peer's (current) IP address, but I'd want additional functions to return the peer's HIT. In that case I don't see any real value in having locally-scoped pseudo-HITs. The reason for doing things this way is that it would require fewer changes to legacy code to support opportunistic HIP. OTOH, if I'm doing "real" HIP then I want to use something like a sockaddr_hip structure that lets me specify both the HIT (as the "address") and a variable number of IP addresses (including both IPv4 and IPv6 addresses) at which the peer named by the HIT might be reachable (or at which a redirect to the actual peer might be obtainable). And then you probably want a HIP-specific replacement for getaddrinfo() that will return not only addresses but also the HIT associated with a DNS name and whatever other information is useful in a form that's easily stuffed into a sockaddr_hip. really you want to be able to map a DNS name into multiple HITs, each of which can have zero or more IPv* addresses associated with it.... and you want a standard data structure that consists of a HIT + IP addresses that can be passed around in referrals. From discuss-bounces@apps.ietf.org Fri May 11 02:19:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmOTn-0005yI-Op; Fri, 11 May 2007 02:19:51 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HmOTm-0005yA-Ht for discuss-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 02:19:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmOTm-0005y2-6P for discuss@apps.ietf.org; Fri, 11 May 2007 02:19:50 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmOTj-0006La-Mn for discuss@apps.ietf.org; Fri, 11 May 2007 02:19:50 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id C3A082D12; Fri, 11 May 2007 09:19:46 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070322 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070322 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 61B442D0E; Fri, 11 May 2007 09:19:44 +0300 (EEST) Date: Fri, 11 May 2007 09:19:44 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Keith Moore Subject: Re: sockets APIs extensions for Host Identity Protocol In-Reply-To: <4643F873.3000501@cs.utk.edu> Message-ID: References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <4641D94C.9070304@cs.utk.edu> <46436B10.5090706@cs.utk.edu> <4643F873.3000501@cs.utk.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Fri, 11 May 2007, Keith Moore wrote: Hi Keith, >>> offhand, I think you need to support both. HITs aren't very useful to >>> apps unless they are visible to them and globally-scoped. HIP is still >>> useful without HIT visibility, but less useful. >> >> It does not mean that the HIT fingerprint, or preferably even the >> corresponding public key, are completely invisible to the application >> with locally-scoped identifiers. It is just a question of an extra >> function call that translates the local-scope identifier to the >> desired format (HIT or public key). > > It strikes me that if I'm using opportunistic HIP, then I probably want > to use normal sockaddr_in* structures and do a setsockopt() that says > "give me HIP if both ends support it" before doing connect() or > listen(). In that case I'd want getpeername() to still return the > peer's (current) IP address, but I'd want additional functions to return > the peer's HIT. In that case I don't see any real value in having > locally-scoped pseudo-HITs. The reason for doing things this way is > that it would require fewer changes to legacy code to support > opportunistic HIP. We have implemented opportunistic mode in the HIPL implementation in the way you described. It required some tricks under the sockets API hood to get it working, but it is great for legacy apps. Even referrals work, assuming that you are behind a NAT or a firewall :) What about "native" HIP applications that are aware of HIP? The whole point of the locally scoped identifier was to provide single, unified end-point token to applications. Is it acceptable to handle both sockaddr_in and sockaddr_hip structures in HIP aware apps? I think a single identifier type would be simpler. > OTOH, if I'm doing "real" HIP then I want to use something like a > sockaddr_hip structure that lets me specify both the HIT (as the > "address") and a variable number of IP addresses (including both IPv4 > and IPv6 addresses) at which the peer named by the HIT might be > reachable (or at which a redirect to the actual peer might be > obtainable). The is certainly possible. One could also implement opportunistic mode by leaving out the HIT from sockaddr_hip and by specifying only the IP. However, there is an inherent problem with this approach as described below. > And then you probably want a HIP-specific replacement for > getaddrinfo() that will return not only addresses but also the HIT > associated with a DNS name and whatever other information is useful in a > form that's easily stuffed into a sockaddr_hip. Why this can't be done in the current resolver by specifying a flag? > really you want to be able to map a DNS name into multiple HITs, each of > which can have zero or more IPv* addresses associated with it.... and > you want a standard data structure that consists of a HIT + IP addresses > that can be passed around in referrals. The problem with this approach is that it will encourage developers to use the IP address directly from the socket address structure. The host corresponding to the HIT may have changed it's IP address at that point (independently of whether the structure describes the local or remote host). I believe that it is be much better to "force" the developer to obtain a valid IP address using a separate function call (see draft-ietf-shim6-multihome-shim-api). An extra call should not be a problem in a HIP aware application. -- Miika Komu http://www.iki.fi/miika/ From discuss-bounces@apps.ietf.org Fri May 11 04:13:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmQFS-0004In-H7; Fri, 11 May 2007 04:13:10 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HmQFR-0004Ia-Hu for discuss-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 04:13:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmQFP-0004IN-Pb for discuss@apps.ietf.org; Fri, 11 May 2007 04:13:08 -0400 Received: from bes.cs.utk.edu ([160.36.56.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmQFP-0006nr-Al for discuss@apps.ietf.org; Fri, 11 May 2007 04:13:07 -0400 Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id B45821032AD; Fri, 11 May 2007 04:13:02 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from bes.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwOIzrx+yFfv; Fri, 11 May 2007 04:12:57 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by bes.cs.utk.edu (Postfix) with ESMTP id B3F93103099; Fri, 11 May 2007 04:12:56 -0400 (EDT) Message-ID: <46442588.7020405@cs.utk.edu> Date: Fri, 11 May 2007 04:12:56 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Miika Komu Subject: Re: sockets APIs extensions for Host Identity Protocol References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <4641D94C.9070304@cs.utk.edu> <46436B10.5090706@cs.utk.edu> <4643F873.3000501@cs.utk.edu> In-Reply-To: X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >> It strikes me that if I'm using opportunistic HIP, then I probably want >> to use normal sockaddr_in* structures and do a setsockopt() that says >> "give me HIP if both ends support it" before doing connect() or >> listen(). In that case I'd want getpeername() to still return the >> peer's (current) IP address, but I'd want additional functions to return >> the peer's HIT. In that case I don't see any real value in having >> locally-scoped pseudo-HITs. The reason for doing things this way is >> that it would require fewer changes to legacy code to support >> opportunistic HIP. > > We have implemented opportunistic mode in the HIPL implementation in > the way you described. It required some tricks under the sockets API > hood to get it working, but it is great for legacy apps. Even > referrals work, assuming that you are behind a NAT or a firewall :) in other words, they don't work. :) > What about "native" HIP applications that are aware of HIP? The whole > point of the locally scoped identifier was to provide single, unified > end-point token to applications. Is it acceptable to handle both > sockaddr_in and sockaddr_hip structures in HIP aware apps? I think a > single identifier type would be simpler. I don't know why a HIP-aware app would use sockaddr_in* for any socket on which it wanted to use HIP. Such an app might want to use sockaddr_in for some sockets if it had a reason to not use HIP on specific sockets. (say for diagnostic purposes) I must have missed the point of locally-scoped identifiers. I thought it was so that you could fit a pseudo-HIT into 32 bits and pretend it was an IPv4 address for the sake of backward compatibility. But if your application was written to be HIP-aware, it would be cleaner to use HIP-specific sockaddrs. And in that case, why use a locally-scoped identifier when you can use a globally-scoped one? (and if your application wasn't originally written to use HIP it's probably the case that the best you can hope for with small mods to your code is opportunistic HIP anyway.) >> OTOH, if I'm doing "real" HIP then I want to use something like a >> sockaddr_hip structure that lets me specify both the HIT (as the >> "address") and a variable number of IP addresses (including both IPv4 >> and IPv6 addresses) at which the peer named by the HIT might be >> reachable (or at which a redirect to the actual peer might be >> obtainable). > > The is certainly possible. One could also implement opportunistic mode > by leaving out the HIT from sockaddr_hip and by specifying only the > IP. However, there is an inherent problem with this approach as > described below. > >> And then you probably want a HIP-specific replacement for >> getaddrinfo() that will return not only addresses but also the HIT >> associated with a DNS name and whatever other information is useful in a >> form that's easily stuffed into a sockaddr_hip. > > Why this can't be done in the current resolver by specifying a flag? for starters, the addrinfo structure doesn't have a field for a HIT, and in a HIP aware app you'd certainly want to specify which HIT you wanted to talk to. neither does addrinfo have any way of representing things that are quite reasonable - like a single DNS name mapping to multiple HITs, each of which maps to multiple IP addresses, where some of those addresses are addresses at which the peer might reasonably be found, and others are for redirect servers. more generally, getaddrinfo() sucks so bad that any excuse to get rid of it is worth considering. >> really you want to be able to map a DNS name into multiple HITs, each of >> which can have zero or more IPv* addresses associated with it.... and >> you want a standard data structure that consists of a HIT + IP addresses >> that can be passed around in referrals. > > The problem with this approach is that it will encourage developers to > use the IP address directly from the socket address structure. The > host corresponding to the HIT may have changed it's IP address at that > point (independently of whether the structure describes the local or > remote host). I believe that it is be much better to "force" the > developer to obtain a valid IP address using a separate function call > (see draft-ietf-shim6-multihome-shim-api). An extra call should not be > a problem in a HIP aware application. it's certainly the case that DNS-to-HIT mapping might change independently of a HIT-to-IP mapping. that, and when there are multiple HITs associated with a single DNS name, a single routine might end up doing several different lookups for the HIT-to-IP mappings, which could take a lot of time. so on reflection I agree that it makes sense to do the lookups separately. From discuss-bounces@apps.ietf.org Fri May 11 09:14:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmUxK-0005QW-6D; Fri, 11 May 2007 09:14:46 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HmUxI-0005QQ-OP for discuss-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 09:14:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmUxI-0005QF-El for discuss@apps.ietf.org; Fri, 11 May 2007 09:14:44 -0400 Received: from sparkle.rodents.montreal.qc.ca ([216.46.5.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmUxH-00088l-0f for discuss@apps.ietf.org; Fri, 11 May 2007 09:14:44 -0400 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id JAA17866; Fri, 11 May 2007 09:14:41 -0400 (EDT) From: der Mouse Message-Id: <200705111314.JAA17866@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Fri, 11 May 2007 09:08:26 -0400 (EDT) To: discuss@apps.ietf.org Subject: Re: sockets APIs extensions for Host Identity Protocol In-Reply-To: <46442588.7020405@cs.utk.edu> References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <4641D94C.9070304@cs.utk.edu> <46436B10.5090706@cs.utk.edu> <4643F873.3000501@cs.utk.edu> <46442588.7020405@cs.utk.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > more generally, getaddrinfo() sucks so bad that any excuse to get rid > of it is worth considering. What do you see as wrong with it? (Not that I disagree; I see it as having problems too. But I sure see it as a lot better than forcing application code to know about all the possible address families - sort of "the worst interface available except for all the others". I'm just interested in what might be wrong with it that I haven't noticed.) /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From discuss-bounces@apps.ietf.org Fri May 11 09:19:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmV29-00067u-Mr; Fri, 11 May 2007 09:19:45 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HmV27-00067A-Ty for discuss-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 09:19:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmV27-000672-KE for discuss@apps.ietf.org; Fri, 11 May 2007 09:19:43 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmV25-0000O9-VK for discuss@apps.ietf.org; Fri, 11 May 2007 09:19:43 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 444E82D1E; Fri, 11 May 2007 16:19:41 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070322 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070322 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id EEEC52D19; Fri, 11 May 2007 16:19:38 +0300 (EEST) Date: Fri, 11 May 2007 16:19:38 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Keith Moore Subject: Re: sockets APIs extensions for Host Identity Protocol In-Reply-To: <46442588.7020405@cs.utk.edu> Message-ID: References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <4641D94C.9070304@cs.utk.edu> <46436B10.5090706@cs.utk.edu> <4643F873.3000501@cs.utk.edu> <46442588.7020405@cs.utk.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Fri, 11 May 2007, Keith Moore wrote: >> What about "native" HIP applications that are aware of HIP? The whole >> point of the locally scoped identifier was to provide single, unified >> end-point token to applications. Is it acceptable to handle both >> sockaddr_in and sockaddr_hip structures in HIP aware apps? I think a >> single identifier type would be simpler. > > I don't know why a HIP-aware app would use sockaddr_in* for any socket > on which it wanted to use HIP. Such an app might want to use > sockaddr_in for some sockets if it had a reason to not use HIP on > specific sockets. (say for diagnostic purposes) Sorry, I meant sockaddr_in6 in this case. > I must have missed the point of locally-scoped identifiers. I thought > it was so that you could fit a pseudo-HIT into 32 bits and pretend it > was an IPv4 address for the sake of backward compatibility. Yes. There can be two types of "pseudo-HITs": Local Scope Identifier (HIP legacy apps draft): * Looks like an IPv4 address * Might even have a locally configured prefix to separate between a LSI and non-LSI address Endpoint descriptor (HIP native apps draft): * Looks more like a FD (increasing or random number) * No prefix > But if your application was written to be HIP-aware, it would be cleaner > to use HIP-specific sockaddrs. And in that case, why use a > locally-scoped identifier when you can use a globally-scoped one? (and > if your application wasn't originally written to use HIP it's probably > the case that the best you can hope for with small mods to your code is > opportunistic HIP anyway.) Yes, but how to do opportunistic mode in a new application that wants to use opportunistic mode for some connections and normal mode for others? >>> OTOH, if I'm doing "real" HIP then I want to use something like a >>> sockaddr_hip structure that lets me specify both the HIT (as the >>> "address") and a variable number of IP addresses (including both IPv4 >>> and IPv6 addresses) at which the peer named by the HIT might be >>> reachable (or at which a redirect to the actual peer might be >>> obtainable). >> >> The is certainly possible. One could also implement opportunistic mode >> by leaving out the HIT from sockaddr_hip and by specifying only the >> IP. However, there is an inherent problem with this approach as >> described below. >> >>> And then you probably want a HIP-specific replacement for >>> getaddrinfo() that will return not only addresses but also the HIT >>> associated with a DNS name and whatever other information is useful in a >>> form that's easily stuffed into a sockaddr_hip. >> >> Why this can't be done in the current resolver by specifying a flag? > > for starters, the addrinfo structure doesn't have a field for a HIT, and > in a HIP aware app you'd certainly want to specify which HIT you wanted > to talk to. neither does addrinfo have any way of representing things > that are quite reasonable - like a single DNS name mapping to multiple > HITs, each of which maps to multiple IP addresses, where some of those > addresses are addresses at which the peer might reasonably be found, and > others are for redirect servers. The addrinfo structure has the generic sockaddr *ai_addr field which can be used for encapsulating a HIT, LSI or ED. One of reasons for the local-scope identifier was to hide the "which HIT maps to which IP" complexity from the application. This does not prevent the application rearranging the identifiers behind the locally-scoped identifiers using a separate function call. What kind of redirect servers are we talking about? > more generally, getaddrinfo() sucks so bad that any excuse to get rid of > it is worth considering. How would a new resolver work in your opinion? I guess there has not been any prior work on this in the IETF. >>> really you want to be able to map a DNS name into multiple HITs, each of >>> which can have zero or more IPv* addresses associated with it.... and >>> you want a standard data structure that consists of a HIT + IP addresses >>> that can be passed around in referrals. >> >> The problem with this approach is that it will encourage developers to >> use the IP address directly from the socket address structure. The >> host corresponding to the HIT may have changed it's IP address at that >> point (independently of whether the structure describes the local or >> remote host). I believe that it is be much better to "force" the >> developer to obtain a valid IP address using a separate function call >> (see draft-ietf-shim6-multihome-shim-api). An extra call should not be >> a problem in a HIP aware application. > > it's certainly the case that DNS-to-HIT mapping might change > independently of a HIT-to-IP mapping. that, and when there are multiple > HITs associated with a single DNS name, a single routine might end up > doing several different lookups for the HIT-to-IP mappings, which could > take a lot of time. so on reflection I agree that it makes sense to do > the lookups separately. Ok, but what do you think about exposing the IP address to the applications in a sockaddr_hip structure? My point was not really about the lookup process, but more like what is going to happen after initial contact between two hosts. After establishing communications, a host moves to another network, detects that its IP address has changed and communicates its new location to the peer. At this point, the IP address that was originally received from the resolver is depracated. -- Miika Komu http://www.iki.fi/miika/ From discuss-bounces@apps.ietf.org Fri May 11 10:03:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmViZ-0001fV-Ix; Fri, 11 May 2007 10:03:35 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HmViY-0001fP-Hg for discuss-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 10:03:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmViY-0001fH-86 for discuss@apps.ietf.org; Fri, 11 May 2007 10:03:34 -0400 Received: from ka.cs.utk.edu ([160.36.56.221]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmViW-0005bj-RJ for discuss@apps.ietf.org; Fri, 11 May 2007 10:03:34 -0400 Received: from localhost (localhost [127.0.0.1]) by ka.cs.utk.edu (Postfix) with ESMTP id 6950CCB3C5; Fri, 11 May 2007 10:03:32 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from ka.cs.utk.edu ([127.0.0.1]) by localhost (ka.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GGkhnDj9bi9; Fri, 11 May 2007 10:03:13 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by ka.cs.utk.edu (Postfix) with ESMTP id 10531CB3D9; Fri, 11 May 2007 10:03:12 -0400 (EDT) Message-ID: <4644779F.60805@cs.utk.edu> Date: Fri, 11 May 2007 10:03:11 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Miika Komu Subject: Re: sockets APIs extensions for Host Identity Protocol References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <4641D94C.9070304@cs.utk.edu> <46436B10.5090706@cs.utk.edu> <4643F873.3000501@cs.utk.edu> <46442588.7020405@cs.utk.edu> In-Reply-To: X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >> I don't know why a HIP-aware app would use sockaddr_in* for any socket >> on which it wanted to use HIP. Such an app might want to use >> sockaddr_in for some sockets if it had a reason to not use HIP on >> specific sockets. (say for diagnostic purposes) > > Sorry, I meant sockaddr_in6 in this case. the same argument applies. If I want to specify that I'm connecting to a HIT, I don't want to use a sockaddr_in6 structure to do that and have it somehow magically know the difference between a HIT and an IPv6 address. I want to use a sockaddr_hit structure for that. That way, I get a clean separation of layers, with all that that implies - better ability to distinguish errors from different layers and handle each appropriately, clearer visibility to the programmer as to what's happening underneath the API, etc. >> I must have missed the point of locally-scoped identifiers. I thought >> it was so that you could fit a pseudo-HIT into 32 bits and pretend it >> was an IPv4 address for the sake of backward compatibility. > > Yes. There can be two types of "pseudo-HITs": > > Local Scope Identifier (HIP legacy apps draft): > * Looks like an IPv4 address > * Might even have a locally configured prefix to separate between a LSI > and non-LSI address > > Endpoint descriptor (HIP native apps draft): > * Looks more like a FD (increasing or random number) > * No prefix I don't immediately see the purpose of the latter type of pseudo-HIT? (guess I should go dig up the draft...) >> But if your application was written to be HIP-aware, it would be >> cleaner to use HIP-specific sockaddrs. And in that case, why use a >> locally-scoped identifier when you can use a globally-scoped one? >> (and if your application wasn't originally written to use HIP it's >> probably the case that the best you can hope for with small mods to >> your code is opportunistic HIP anyway.) > > Yes, but how to do opportunistic mode in a new application that wants > to use opportunistic mode for some connections and normal mode for > others? well, the setsockopt() mechanism for enabling opportunistic HIP that would be useful for modifying legacy apps could also be used for new apps. if you wanted to have a mechanism to do the same thing with sockaddr_hit, say by setting the HIT field to HIT_UNKNOWN or some such, that could be defined also. though the details would be interesting to work out. >> for starters, the addrinfo structure doesn't have a field for a HIT, and >> in a HIP aware app you'd certainly want to specify which HIT you wanted >> to talk to. neither does addrinfo have any way of representing things >> that are quite reasonable - like a single DNS name mapping to multiple >> HITs, each of which maps to multiple IP addresses, where some of those >> addresses are addresses at which the peer might reasonably be found, and >> others are for redirect servers. > > The addrinfo structure has the generic sockaddr *ai_addr field which > can be used for encapsulating a HIT, LSI or ED. ah yes, good point. > One of reasons for the local-scope identifier was to hide the "which > HIT maps to which IP" complexity from the application. This does not > prevent the application rearranging the identifiers behind the > locally-scoped > identifiers using a separate function call. at this level of API, hiding the "which HIT maps to which IP" complexity seems misguided. let the high-level API do that. you need an API that exposes this stuff. > What kind of redirect servers are we talking about? I haven't keep track of the HIP discussions on this topic, so I don't know what they're being called. but at one time there was an idea that you could have a server that could be associated with a HIT that would securely be updated with current IP addresses for that HIT, and which could securely tell peers of that HIT when the host associated with the HIT had moved. (those servers would need to be located at relatively stable addresses). you'd want to be able to discover those servers through DNS or a similar mechanism. >> more generally, getaddrinfo() sucks so bad that any excuse to get rid of >> it is worth considering. > > How would a new resolver work in your opinion? I guess there has not > been any prior work on this in the IETF. it will take more than an email message to answer that question. >> it's certainly the case that DNS-to-HIT mapping might change >> independently of a HIT-to-IP mapping. that, and when there are multiple >> HITs associated with a single DNS name, a single routine might end up >> doing several different lookups for the HIT-to-IP mappings, which could >> take a lot of time. so on reflection I agree that it makes sense to do >> the lookups separately. > > Ok, but what do you think about exposing the IP address to the > applications in a sockaddr_hip structure? My point was not really > about the lookup process, but more like what is going to happen after > initial contact between two hosts. After establishing communications, > a host moves to another network, detects that its IP address has > changed and communicates its new location to the peer. At this point, > the IP address that was originally received from the resolver is > depracated. we're a very long way from being able to trust a kernel to make effective address selection across a wide variety of network environments and application requirements. until we get there, the addresses need to be exposed to the application, and the application needs to be able to specify which addresses are allowed to be used. if nothing else, you're going to need that for diagnostics. if some user tells his sysadmin that his program can't connect to HIT xxxx, the sysadmin has no way to know how to debug the problem. if instead the message is "cannot connect to HIT xxxx at address yyyy", a traceroute to yyyy might yield some useful information. granted, however, that the sockaddr_hit structure can only communicate the IP addresses at which the peer with that HIT might initially be found. once the connection is established, all assumptions about the HIT-to-IP bindings that were established in sockaddr_hit are invalid. Keith From discuss-bounces@apps.ietf.org Fri May 11 10:52:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmWTY-0006uM-4s; Fri, 11 May 2007 10:52:08 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HmWTW-0006o5-Hh for discuss-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 10:52:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmWTW-0006nx-8A for discuss@apps.ietf.org; Fri, 11 May 2007 10:52:06 -0400 Received: from ka.cs.utk.edu ([160.36.56.221]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmWTV-0001X2-U3 for discuss@apps.ietf.org; Fri, 11 May 2007 10:52:06 -0400 Received: from localhost (localhost [127.0.0.1]) by ka.cs.utk.edu (Postfix) with ESMTP id 5ABC2CB3D9; Fri, 11 May 2007 10:52:03 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from ka.cs.utk.edu ([127.0.0.1]) by localhost (ka.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52pfQ5hBMclp; Fri, 11 May 2007 10:51:58 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by ka.cs.utk.edu (Postfix) with ESMTP id E4EDFCB3C0; Fri, 11 May 2007 10:51:57 -0400 (EDT) Message-ID: <4644830D.7050302@cs.utk.edu> Date: Fri, 11 May 2007 10:51:57 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: der Mouse Subject: Re: sockets APIs extensions for Host Identity Protocol References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <4641D94C.9070304@cs.utk.edu> <46436B10.5090706@cs.utk.edu> <4643F873.3000501@cs.utk.edu> <46442588.7020405@cs.utk.edu> <200705111314.JAA17866@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: <200705111314.JAA17866@Sparkle.Rodents.Montreal.QC.CA> X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org der Mouse wrote: >> more generally, getaddrinfo() sucks so bad that any excuse to get rid >> of it is worth considering. >> > > What do you see as wrong with it? (Not that I disagree; I see it as > having problems too. But I sure see it as a lot better than forcing > application code to know about all the possible address families - sort > of "the worst interface available except for all the others". I'm just > interested in what might be wrong with it that I haven't noticed.) > I suspect I could write an RFC about what's wrong with getaddrinfo(). the nice thing about it is that it does two things for you. one is that it completely initializes sockaddr structures for you. the other is that (at least in recent versions?) it can take either a DNS name or an address literal and do the right thing with it. so if you want to use that name or literal to initialize a sockaddr to open up a connection, it can do that. in a nutshell, the downsides are these (note, this is probably not a complete list, just what's off the top of my head): - it's actually more difficult to set the parameters for getaddrinfo() to get it to do what you want, than it is to initialize the fields in a sockaddr_in* - getaddrinfo encourages use of string constants to specify ports, rather than numeric constants, which is wrong - it adds an extra layer of indirection that can (and does) fail, and it tempts people to try to use that layer of indirection to do things that violate protocol specifications (like do a SRV lookup for protocols that aren't specified to use SRV) or otherwise try to be too clever. for instance, I've seen an implementation of getaddrinfo fail when given a numeric string constant for the port, because that port couldn't be found in /etc/services. - it has no way to be used asynchronously other than to put each call to getaddrinfo in a separate thread, and even then, many implementations are not thread-safe. - it's not specified to use DNS. so if a protocol is specified to use DNS in some particular way, and the implementation of the protocol uses getaddrinfo(), the implementation may fail to strictly follow the protocol spec. (yes, this is propagating an error that was present in gethostbyname(), but getaddrinfo() missed the opportunity to fix it. some implementations do have a flag that insists that DNS be used) - the handling of v4 vs v6 vs mapped v4 addresses is confusing. - it can lookup address literals but you still need to set the AI_NUMERICHOST bit in the flags if the name field is an address literal, if you want the code to work portably. so in the common case where you're passed a string that could either be a name or an address literal, you still have to parse that string to determine whether it's an address in order to know how to set that bit. the default should be to accept either a DNS name or address literal. there could still be options that would cause it to fail if the name parameter weren't a DNS name or address literal. - similarly for AI_NUMERICPORT for implementations that support that flag - various platforms shipped with getaddrinfo() implementations based on early specifications, so there's a fair amount of variation from one platform to another in what features are actually supported. it can be a challenge to write portable code that uses it. - address ordering often produces suboptimal results. arguably this is not the fault of getaddrinfo() except that it creates the expectation that the API or kernel can do a good job of address ordering. From discuss-bounces@apps.ietf.org Fri May 11 11:26:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmX0v-0004o6-Ma; Fri, 11 May 2007 11:26:37 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HmX0u-0004ny-Ek for discuss-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 11:26:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmX0u-0004nq-5D for discuss@apps.ietf.org; Fri, 11 May 2007 11:26:36 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmX0r-00055g-IA for discuss@apps.ietf.org; Fri, 11 May 2007 11:26:36 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 031CF2CFA; Fri, 11 May 2007 18:26:30 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070322 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070322 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id EE55C2CED; Fri, 11 May 2007 18:26:29 +0300 (EEST) Date: Fri, 11 May 2007 18:26:29 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Keith Moore Subject: Re: sockets APIs extensions for Host Identity Protocol In-Reply-To: <4644779F.60805@cs.utk.edu> Message-ID: References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <4641D94C.9070304@cs.utk.edu> <46436B10.5090706@cs.utk.edu> <4643F873.3000501@cs.utk.edu> <46442588.7020405@cs.utk.edu> <4644779F.60805@cs.utk.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Fri, 11 May 2007, Keith Moore wrote: > >>> I don't know why a HIP-aware app would use sockaddr_in* for any socket >>> on which it wanted to use HIP. Such an app might want to use >>> sockaddr_in for some sockets if it had a reason to not use HIP on >>> specific sockets. (say for diagnostic purposes) >> >> Sorry, I meant sockaddr_in6 in this case. > > the same argument applies. If I want to specify that I'm connecting to > a HIT, I don't want to use a sockaddr_in6 structure to do that and have > it somehow magically know the difference between a HIT and an IPv6 > address. I want to use a sockaddr_hit structure for that. That way, I > get a clean separation of layers, with all that that implies - better > ability to distinguish errors from different layers and handle each > appropriately, clearer visibility to the programmer as to what's > happening underneath the API, etc. Ok. Would you be fine with having a new address family (AF_HIP) to separate between sockaddr_hip and sockaddr_in6? >>> I must have missed the point of locally-scoped identifiers. I thought >>> it was so that you could fit a pseudo-HIT into 32 bits and pretend it >>> was an IPv4 address for the sake of backward compatibility. >> >> Yes. There can be two types of "pseudo-HITs": >> >> Local Scope Identifier (HIP legacy apps draft): >> * Looks like an IPv4 address >> * Might even have a locally configured prefix to separate between a LSI >> and non-LSI address >> >> Endpoint descriptor (HIP native apps draft): >> * Looks more like a FD (increasing or random number) >> * No prefix > > I don't immediately see the purpose of the latter type of pseudo-HIT? > (guess I should go dig up the draft...) I don't see any reason to give HIP aware applications LSIs that look like IPv4 addresses but are actually presenting HITs. Here's also a couple of short slide sets: http://www3.ietf.org/proceedings/05aug/slides/apparea-3.pdf http://www3.ietf.org/proceedings/06jul/slides/hip-2.pdf And some future research extensions for the endpoint descriptors: http://kathrin.dagstuhl.de/files/Materials/06/06441/06441.KomuMiika.Abstract.txt http://kathrin.dagstuhl.de/files/Materials/06/06441/06441.KomuMiika.Slides.pdf >>> But if your application was written to be HIP-aware, it would be >>> cleaner to use HIP-specific sockaddrs. And in that case, why use a >>> locally-scoped identifier when you can use a globally-scoped one? >>> (and if your application wasn't originally written to use HIP it's >>> probably the case that the best you can hope for with small mods to >>> your code is opportunistic HIP anyway.) >> >> Yes, but how to do opportunistic mode in a new application that wants >> to use opportunistic mode for some connections and normal mode for >> others? > > well, the setsockopt() mechanism for enabling opportunistic HIP that > would be useful for modifying legacy apps could also be used for new apps. > > if you wanted to have a mechanism to do the same thing with > sockaddr_hit, say by setting the HIT field to HIT_UNKNOWN or some such, > that could be defined also. though the details would be interesting to > work out. Ok. >> One of reasons for the local-scope identifier was to hide the "which >> HIT maps to which IP" complexity from the application. This does not >> prevent the application rearranging the identifiers behind the >> locally-scoped >> identifiers using a separate function call. > > at this level of API, hiding the "which HIT maps to which IP" complexity > seems misguided. let the high-level API do that. you need an API that > exposes this stuff. Right. >> What kind of redirect servers are we talking about? > > I haven't keep track of the HIP discussions on this topic, so I don't > know what they're being called. but at one time there was an idea that > you could have a server that could be associated with a HIT that would > securely be updated with current IP addresses for that HIT, and which > could securely tell peers of that HIT when the host associated with the > HIT had moved. (those servers would need to be located at relatively > stable addresses). you'd want to be able to discover those servers > through DNS or a similar mechanism. I think you are talking about rendezvous server that are similar to the home agents in MobileIP. > we're a very long way from being able to trust a kernel to make > effective address selection across a wide variety of network > environments and application requirements. until we get there, the > addresses need to be exposed to the application, and the application > needs to be able to specify which addresses are allowed to be used. if > nothing else, you're going to need that for diagnostics. if some user > tells his sysadmin that his program can't connect to HIT xxxx, the > sysadmin has no way to know how to debug the problem. if instead the > message is "cannot connect to HIT xxxx at address yyyy", a traceroute to > yyyy might yield some useful information. > > granted, however, that the sockaddr_hit structure can only communicate > the IP addresses at which the peer with that HIT might initially be > found. once the connection is established, all assumptions about the > HIT-to-IP bindings that were established in sockaddr_hit are invalid. Are you fine with a sockaddr_hit structure that contains only the HIT and letting a getsockopt() call to figure out the IP addresses in the context of HIP aware applications? (I think getsockname and getpeername should return the HITs.) -- Miika Komu http://www.iki.fi/miika/ From discuss-bounces@apps.ietf.org Fri May 11 12:42:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmYCG-0003Zn-M6; Fri, 11 May 2007 12:42:24 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HmYCF-0003Zi-Pg for discuss-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 12:42:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmYCE-0003ZX-UR for discuss@apps.ietf.org; Fri, 11 May 2007 12:42:23 -0400 Received: from sparkle.rodents.montreal.qc.ca ([216.46.5.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmYCE-0004WV-BB for discuss@apps.ietf.org; Fri, 11 May 2007 12:42:22 -0400 Received: from localhost (localhost [[UNIX: localhost]]) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id MAA19058; Fri, 11 May 2007 12:42:21 -0400 (EDT) From: der Mouse Message-Id: <200705111642.MAA19058@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Fri, 11 May 2007 12:02:00 -0400 (EDT) To: discuss@apps.ietf.org Subject: Re: sockets APIs extensions for Host Identity Protocol In-Reply-To: <4644830D.7050302@cs.utk.edu> References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <4641D94C.9070304@cs.utk.edu> <46436B10.5090706@cs.utk.edu> <4643F873.3000501@cs.utk.edu> <46442588.7020405@cs.utk.edu> <200705111314.JAA17866@Sparkle.Rodents.Montreal.QC.CA> <4644830D.7050302@cs.utk.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >> What do you see as wrong with [getaddrinfo()]? > the nice thing about it is that it does two things for you. one is > that it completely initializes sockaddr structures for you. the > other is that (at least in recent versions?) it can take either a DNS > name or an address literal and do the right thing with it. The major thing *I* use it for is to insulate the application from knowledge of what address families are available. If correctly written (getaddrinfo() can be used wrong, as most things can), an application can be totally new-AF-ready. If I write an SMTP client with getaddrinfo() and then, a year later, someone defines SMTP-over-DECnet (or SMTP-over-IPv7, or whatever), my code will start trying DECnet without any changes whatsoever to the application. (If, of course, it's running on a DECnet-aware - or IPv7-aware - system.) > - it's actually more difficult to set the parameters for > getaddrinfo() to get it to do what you want, than it is to > initialize the fields in a sockaddr_in* Yes, if all you want is AF_INET - or AF_INET6 - it is. But this is *not* true if "what you want" is for the app code to be AF-agnostic, as I sketched above. I'm not even sure it's true if you want AF_INET *and* AF_INET6; I find it about evenly balanced whether getaddrinfo() or doing both INET* AFs is messier, more difficult, whatever. > - getaddrinfo encourages use of string constants to specify ports, > rather than numeric constants, which is wrong - No, this is very right. The notion that "ports" are small integers is a *horribly* IP-centric notion. DECnet, for example, uses short strings (8-char? 12-char? I don't know the limit) which do *not* have to map into numbers - I think X over DECnet, for example, uses "port" strings like "X$0" and "X$1". > it adds an extra layer of indirection that can (and does) fail, > and it tempts people to try to use that layer of indirection to do > things that violate protocol specifications (like do a SRV lookup > for protocols that aren't specified to use SRV) We must be talking about different getaddrinfo()s. The one I'm used to doesn't do anything with SRV records, ever, as far as I can see (I checked both the manpage and the code). > - it has no way to be used asynchronously other than to put each call > to getaddrinfo in a separate thread, Neither does gethostbyname(). And, without a lot of callback or AIO scaffolding - or threading - it *can't*. > - it's not specified to use DNS. It's not really specified clearly at all, it appears. Again, a valid criticism, but a fixable one. But it can't really be specified to use DNS, since it is not restricted to address families that the DNS supports, and it also has to work on systems not connected to the Internet (/etc/hosts and its ilk). If I had to set up a private DNS root just to use host names on an isolated subnet, I'd call that cripplingly broken. > so if a protocol is specified to use DNS in some particular way, > and the implementation of the protocol uses getaddrinfo(), the > implementation may fail to strictly follow the protocol spec. This is not a problem with getaddrinfo(); this is a problem with implementors using inappropriate calls. getaddrinfo() is not appropriate for implementing protocols defined must-use-DNS, because of the above issues. (I'd actually argue that such specs are broken, because they mean the protocol is unreasonably difficult to use according to spec except on the public Internet.) > - the handling of v4 vs v6 vs mapped v4 addresses is confusing. No more than v4 vs v6 vs mapped v4 are to begin with. The rest of your points - including the pieces I cut from the oens I did address specifically - seem to fall into two categories: "no clear agreed-upon spec" and "buggy implementations are common". While these are fair answers to my question, neither one seems to me like a reason to ditch the interface entirely when considering standardizing something for (say) HIP/HIT use. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From discuss-bounces@apps.ietf.org Fri May 11 16:09:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmbQo-0006Le-2N; Fri, 11 May 2007 16:09:38 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HmbQm-0006LZ-NL for discuss-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 16:09:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmbQl-0006L5-TB for discuss@apps.ietf.org; Fri, 11 May 2007 16:09:35 -0400 Received: from ka.cs.utk.edu ([160.36.56.221]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmbQj-0007P2-Fh for discuss@apps.ietf.org; Fri, 11 May 2007 16:09:35 -0400 Received: from localhost (localhost [127.0.0.1]) by ka.cs.utk.edu (Postfix) with ESMTP id 05B04CB3D9; Fri, 11 May 2007 16:09:32 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from ka.cs.utk.edu ([127.0.0.1]) by localhost (ka.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ERfAfN8qLdz; Fri, 11 May 2007 16:09:28 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by ka.cs.utk.edu (Postfix) with ESMTP id 5EB6DCB3D8; Fri, 11 May 2007 16:09:27 -0400 (EDT) Message-ID: <4644CD76.10900@cs.utk.edu> Date: Fri, 11 May 2007 16:09:26 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Miika Komu Subject: Re: sockets APIs extensions for Host Identity Protocol References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <4641D94C.9070304@cs.utk.edu> <46436B10.5090706@cs.utk.edu> <4643F873.3000501@cs.utk.edu> <46442588.7020405@cs.utk.edu> <4644779F.60805@cs.utk.edu> In-Reply-To: X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >> the same argument applies. If I want to specify that I'm connecting to >> a HIT, I don't want to use a sockaddr_in6 structure to do that and have >> it somehow magically know the difference between a HIT and an IPv6 >> address. I want to use a sockaddr_hit structure for that. That way, I >> get a clean separation of layers, with all that that implies - better >> ability to distinguish errors from different layers and handle each >> appropriately, clearer visibility to the programmer as to what's >> happening underneath the API, etc. > > Ok. Would you be fine with having a new address family (AF_HIP) to > separate between sockaddr_hip and sockaddr_in6? yes, I think that would be appropriate. >>>> I must have missed the point of locally-scoped identifiers. I thought >>>> it was so that you could fit a pseudo-HIT into 32 bits and pretend it >>>> was an IPv4 address for the sake of backward compatibility. >>> >>> Yes. There can be two types of "pseudo-HITs": >>> >>> Local Scope Identifier (HIP legacy apps draft): >>> * Looks like an IPv4 address >>> * Might even have a locally configured prefix to separate between a LSI >>> and non-LSI address >>> >>> Endpoint descriptor (HIP native apps draft): >>> * Looks more like a FD (increasing or random number) >>> * No prefix >> >> I don't immediately see the purpose of the latter type of pseudo-HIT? >> (guess I should go dig up the draft...) > > I don't see any reason to give HIP aware applications LSIs that look > like IPv4 addresses but are actually presenting HITs. Here's also a > couple of short slide sets: > > http://www3.ietf.org/proceedings/05aug/slides/apparea-3.pdf > http://www3.ietf.org/proceedings/06jul/slides/hip-2.pdf > > And some future research extensions for the endpoint descriptors: > > http://kathrin.dagstuhl.de/files/Materials/06/06441/06441.KomuMiika.Abstract.txt > > http://kathrin.dagstuhl.de/files/Materials/06/06441/06441.KomuMiika.Slides.pdf > thanks, I'll take a look. >>> What kind of redirect servers are we talking about? >> >> I haven't keep track of the HIP discussions on this topic, so I don't >> know what they're being called. but at one time there was an idea that >> you could have a server that could be associated with a HIT that would >> securely be updated with current IP addresses for that HIT, and which >> could securely tell peers of that HIT when the host associated with the >> HIT had moved. (those servers would need to be located at relatively >> stable addresses). you'd want to be able to discover those servers >> through DNS or a similar mechanism. > > I think you are talking about rendezvous server that are similar to > the home agents in MobileIP. yes, I think that's the term that was being used last time I heard it mentioned. >> we're a very long way from being able to trust a kernel to make >> effective address selection across a wide variety of network >> environments and application requirements. until we get there, the >> addresses need to be exposed to the application, and the application >> needs to be able to specify which addresses are allowed to be used. if >> nothing else, you're going to need that for diagnostics. if some user >> tells his sysadmin that his program can't connect to HIT xxxx, the >> sysadmin has no way to know how to debug the problem. if instead the >> message is "cannot connect to HIT xxxx at address yyyy", a traceroute to >> yyyy might yield some useful information. >> >> granted, however, that the sockaddr_hit structure can only communicate >> the IP addresses at which the peer with that HIT might initially be >> found. once the connection is established, all assumptions about the >> HIT-to-IP bindings that were established in sockaddr_hit are invalid. > > Are you fine with a sockaddr_hit structure that contains only the HIT > and letting a getsockopt() call to figure out the IP addresses in the > context of HIP aware applications? (I think getsockname and > getpeername should return the HITs.) if the sockaddr_hit structure contains only the HIT, how is the kernel going to know where it can contact that peer? It has to get one or more IP addresses from somewhere. Keith From discuss-bounces@apps.ietf.org Fri May 11 16:32:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmbmZ-0007n9-0O; Fri, 11 May 2007 16:32:07 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HmbmX-0007n4-Gg for discuss-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 16:32:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmbmW-0007mv-Ml for discuss@apps.ietf.org; Fri, 11 May 2007 16:32:04 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmbmV-0003jN-7L for discuss@apps.ietf.org; Fri, 11 May 2007 16:32:04 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 79F8C2CD1; Fri, 11 May 2007 23:32:02 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070322 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070322 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 08ADC2CB8; Fri, 11 May 2007 23:32:02 +0300 (EEST) Date: Fri, 11 May 2007 23:32:01 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Keith Moore Subject: Re: sockets APIs extensions for Host Identity Protocol In-Reply-To: <4644CD76.10900@cs.utk.edu> Message-ID: References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <4641D94C.9070304@cs.utk.edu> <46436B10.5090706@cs.utk.edu> <4643F873.3000501@cs.utk.edu> <46442588.7020405@cs.utk.edu> <4644779F.60805@cs.utk.edu> <4644CD76.10900@cs.utk.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Fri, 11 May 2007, Keith Moore wrote: >> Are you fine with a sockaddr_hit structure that contains only the HIT >> and letting a getsockopt() call to figure out the IP addresses in the >> context of HIP aware applications? (I think getsockname and >> getpeername should return the HITs.) > > if the sockaddr_hit structure contains only the HIT, how is the kernel > going to know where it can contact that peer? It has to get one or more > IP addresses from somewhere. If the resolver is used, it can send a hint containing this mapping to the HIP daemon. -- Miika Komu http://www.iki.fi/miika/ From discuss-bounces@apps.ietf.org Fri May 11 16:52:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmc6G-0007Y3-9T; Fri, 11 May 2007 16:52:28 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hmc6E-0007Xt-JY for discuss-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 16:52:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmc6E-0007Xj-9O for discuss@apps.ietf.org; Fri, 11 May 2007 16:52:26 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hmc6C-0008DJ-Vs for discuss@apps.ietf.org; Fri, 11 May 2007 16:52:26 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 8885F2CE0; Fri, 11 May 2007 23:52:24 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070322 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070322 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 228422CBC; Fri, 11 May 2007 23:52:22 +0300 (EEST) Date: Fri, 11 May 2007 23:52:22 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: der Mouse Subject: Re: sockets APIs extensions for Host Identity Protocol In-Reply-To: <200705111642.MAA19058@Sparkle.Rodents.Montreal.QC.CA> Message-ID: References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <4641D94C.9070304@cs.utk.edu> <46436B10.5090706@cs.utk.edu> <4643F873.3000501@cs.utk.edu> <46442588.7020405@cs.utk.edu> <200705111314.JAA17866@Sparkle.Rodents.Montreal.QC.CA> <4644830D.7050302@cs.utk.edu> <200705111642.MAA19058@Sparkle.Rodents.Montreal.QC.CA> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Fri, 11 May 2007, der Mouse wrote: > The rest of your points - including the pieces I cut from the oens I > did address specifically - seem to fall into two categories: "no clear > agreed-upon spec" and "buggy implementations are common". While these > are fair answers to my question, neither one seems to me like a reason > to ditch the interface entirely when considering standardizing > something for (say) HIP/HIT use. The getaddrinfo may have its shortcomings, but it does not really prevent to write HIP bindings for it. As you said, it does handle address family independency quite well even though other things might be handled better. If there is better interface in the future, we can define HIP bindings also for it. -- Miika Komu http://www.iki.fi/miika/ From discuss-bounces@apps.ietf.org Fri May 11 16:53:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmc7i-0007ga-RT; Fri, 11 May 2007 16:53:58 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hmc7h-0007gP-OI for discuss-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 16:53:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmc7h-0007gH-Ek for discuss@apps.ietf.org; Fri, 11 May 2007 16:53:57 -0400 Received: from ka.cs.utk.edu ([160.36.56.221]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hmc7g-0008Oi-TI for discuss@apps.ietf.org; Fri, 11 May 2007 16:53:57 -0400 Received: from localhost (localhost [127.0.0.1]) by ka.cs.utk.edu (Postfix) with ESMTP id 71600CB3E0; Fri, 11 May 2007 16:53:56 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from ka.cs.utk.edu ([127.0.0.1]) by localhost (ka.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6d0BsH7CgVmp; Fri, 11 May 2007 16:53:45 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by ka.cs.utk.edu (Postfix) with ESMTP id 1E9A1CB3EB; Fri, 11 May 2007 16:53:44 -0400 (EDT) Message-ID: <4644D7D7.50109@cs.utk.edu> Date: Fri, 11 May 2007 16:53:43 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: der Mouse Subject: Re: sockets APIs extensions for Host Identity Protocol References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <4641D94C.9070304@cs.utk.edu> <46436B10.5090706@cs.utk.edu> <4643F873.3000501@cs.utk.edu> <46442588.7020405@cs.utk.edu> <200705111314.JAA17866@Sparkle.Rodents.Montreal.QC.CA> <4644830D.7050302@cs.utk.edu> <200705111642.MAA19058@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: <200705111642.MAA19058@Sparkle.Rodents.Montreal.QC.CA> X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org der Mouse wrote: >>> What do you see as wrong with [getaddrinfo()]? >>> >> the nice thing about it is that it does two things for you. one is >> that it completely initializes sockaddr structures for you. the >> other is that (at least in recent versions?) it can take either a DNS >> name or an address literal and do the right thing with it. >> > > The major thing *I* use it for is to insulate the application from > knowledge of what address families are available. that's just fine for some corner cases, and if it works for your app, great - but it's not the general case. I like that getaddrinfo() can do this, but I've found a surprising number of cases where I need to treat IPv4 and IPv6 addresses differently. there are several reasons for this: - one is that the default address selection rules are just broken - or at least, hopelessly naive. for example it is nearly always better to use a native IPv4 (non-private) address in preference to a 6to4 or Teredo IPv6 address that would require use of a relay router - but whether it's actually better or not depends on the application and how it uses addresses (e.g. whether it does referrals). - another reason is that an increasing number of ISPs are supplying DNS servers that lie about the contents of their zone and return bogus A records for any zone that doesn't have A records - even if the zone does have other valid records like AAAA records. those bogus A records point to http servers that will "helpfully" respond to a request for a web page with that ( supposedly misspelled) domain and return pointers to other web sites that might be the right one - along with advertisements that make money for the ISP. I've experimented with various kinds of hacks in order to keep my apps from getting screwed by such ISPs, but all of them require my app to be aware of address families. - NATs, private addresses, link-local addresses, LLMNR all complicate the picture for an app that's trying to work in a variety of environments. again, the app needs knowledge of address types in order to try to sort things out. > If correctly written > (getaddrinfo() can be used wrong, as most things can), an application > can be totally new-AF-ready. If I write an SMTP client with > getaddrinfo() and then, a year later, someone defines SMTP-over-DECnet > (or SMTP-over-IPv7, or whatever), my code will start trying DECnet > without any changes whatsoever to the application. (If, of course, > it's running on a DECnet-aware - or IPv7-aware - system.) > and the chances that this will actually work correctly are nil, because every new kind of address family will be subtly different than the old ones. for instance, SMTP over DECnet (which does exist, or at least did exist) imposed a maximum line length of 512 bytes. to take a more recent example, SCTP isn't quite a drop-in substitute for TCP even if both ends support it, because it lacks a clean close and urgent data, and there are apps that rely on each of these. again, it's nice that getaddrinfo() gives you a way to pretend that IPv4 and IPv6 are interchangeable for the benefit of the apps that can use that feature, but it's not as if all apps can or should work that way. >> - it's actually more difficult to set the parameters for >> getaddrinfo() to get it to do what you want, than it is to >> initialize the fields in a sockaddr_in* >> > > Yes, if all you want is AF_INET - or AF_INET6 - it is. But this is > *not* true if "what you want" is for the app code to be AF-agnostic, as > I sketched above. I'm not even sure it's true if you want AF_INET > *and* AF_INET6; I find it about evenly balanced whether getaddrinfo() > or doing both INET* AFs is messier, more difficult, whatever. > there are more quirks than that. you have to know whether you have a numeric address and port. >> - getaddrinfo encourages use of string constants to specify ports, >> rather than numeric constants, which is wrong - >> > > No, this is very right. sorry, I've spent way too much time debugging brain-damaged code that used getservbyname() and which failed when the NIS server went down or the /etc/services file got corrupted EVEN THOUGH THE PORT TO BE USED WAS A DEFINED CONSTANT IN THE PROTOCOL SPECIFICATION. anytime you invoke a function call that should always, always, always return a constant and that function can possibly do anything else but return that constant, you are basically asking for the sack. and you deserve it. > The notion that "ports" are small integers is > a *horribly* IP-centric notion. and the vast majority of our protocols are, by definition, IP centric. the socket() interface can and has been used for non-IP networking, but trying to make a name lookup function support the lookup semantics of every possible future networking technology is just naive. that kind of generality almost never ends up being used. what we need to make IP applications be robust is a name lookup function that works very well with DNS and DNS records. >> it adds an extra layer of indirection that can (and does) fail, >> and it tempts people to try to use that layer of indirection to do >> things that violate protocol specifications (like do a SRV lookup >> for protocols that aren't specified to use SRV) >> > > We must be talking about different getaddrinfo()s. The one I'm used to > doesn't do anything with SRV records, ever, as far as I can see (I > checked both the manpage and the code). > it's been proposed, more than once, because it seems "obvious" to those who misunderstand SRV. part of the problem is, the definition of the function doesn't actually say what the function does with respect to DNS because it's too vague - probably as a result of trying to take future hypothetical networking stacks into account. >> - it has no way to be used asynchronously other than to put each call >> to getaddrinfo in a separate thread, >> > > Neither does gethostbyname(). And, without a lot of callback or AIO > scaffolding - or threading - it *can't*. > I don't think it's quite as bad as you make it out to be. but I need to either write one or find an existing example to be sure. >> - it's not specified to use DNS. >> > > It's not really specified clearly at all, it appears. Again, a valid > criticism, but a fixable one. > > But it can't really be specified to use DNS, since it is not restricted > to address families that the DNS supports that's a bug, not a feature. > , and it also has to work on > systems not connected to the Internet (/etc/hosts and its ilk). that's possibly also a bug, not a feature. too many apps break when address lookups on different hosts produce inconsistent results. > If I > had to set up a private DNS root just to use host names on an isolated > subnet, I'd call that cripplingly broken. > no, we'd just have servers that were purpose-built to do that. or these days we'd use LLMNR to do that. unfortunately the details of how to write an app that works well on all of: the public internet, private networks with some interconnection to other private networks, and isolated subnets, don't seem to have ever been worked out - not for name lookup, address selection, automatic host configuration, or anything else. so we have a hodgepodge of half-solutions and no guidance for either software authors or network operators. >> so if a protocol is specified to use DNS in some particular way, >> and the implementation of the protocol uses getaddrinfo(), the >> implementation may fail to strictly follow the protocol spec. >> > > This is not a problem with getaddrinfo(); this is a problem with > implementors using inappropriate calls. getaddrinfo() is not > appropriate for implementing protocols defined must-use-DNS, because of > the above issues. well, then getaddrinfo() is not appropriate for a large number of IETF protocols, because these either explicitly or implicitly expect DNS (e.g. if DNS is the means by which the protocol engines locate one another in the absence of explicit agreement, as is the case for SMTP). > (I'd actually argue that such specs are broken, > because they mean the protocol is unreasonably difficult to use > according to spec except on the public Internet.) > IETF tends to define how protocols work on the public Internet, and to not concern itself quite so much with what happens elsewhere between consenting adults. traditionally that's been the right answer, but nowadays isolated/ad-hoc/private networks and private interconnections are increasingly common - and we need for apps to be able to run in all of those environments without changes or special configuration. >> - the handling of v4 vs v6 vs mapped v4 addresses is confusing. >> > > No more than v4 vs v6 vs mapped v4 are to begin with. > > The rest of your points - including the pieces I cut from the oens I > did address specifically - seem to fall into two categories: "no clear > agreed-upon spec" and "buggy implementations are common". While these > are fair answers to my question, neither one seems to me like a reason > to ditch the interface entirely when considering standardizing > something for (say) HIP/HIT use I've seen so much variation between implementations of getaddrinfo that I've become convinced that it needs to be replaced for that reason alone. But the variation seems to have resulted from two things: the vagueness of the spec (in turn the result of overgenerality) and a demand to get the interface nailed down before the requirements were understood. Keith From discuss-bounces@apps.ietf.org Fri May 11 16:59:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmcCb-0005WY-Vd; Fri, 11 May 2007 16:59:01 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HmcCa-0005WH-Ah for discuss-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 16:59:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmcCZ-0005W6-Kz for discuss@apps.ietf.org; Fri, 11 May 2007 16:59:00 -0400 Received: from ka.cs.utk.edu ([160.36.56.221]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmcCX-0000bw-Bv for discuss@apps.ietf.org; Fri, 11 May 2007 16:58:59 -0400 Received: from localhost (localhost [127.0.0.1]) by ka.cs.utk.edu (Postfix) with ESMTP id 04B4CCB3E0; Fri, 11 May 2007 16:58:56 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from ka.cs.utk.edu ([127.0.0.1]) by localhost (ka.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xrq6c3GMV7iy; Fri, 11 May 2007 16:58:52 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by ka.cs.utk.edu (Postfix) with ESMTP id 1277CCB3B7; Fri, 11 May 2007 16:58:52 -0400 (EDT) Message-ID: <4644D90B.1020304@cs.utk.edu> Date: Fri, 11 May 2007 16:58:51 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Miika Komu Subject: Re: sockets APIs extensions for Host Identity Protocol References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <4641D94C.9070304@cs.utk.edu> <46436B10.5090706@cs.utk.edu> <4643F873.3000501@cs.utk.edu> <46442588.7020405@cs.utk.edu> <4644779F.60805@cs.utk.edu> <4644CD76.10900@cs.utk.edu> In-Reply-To: X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Miika Komu wrote: > On Fri, 11 May 2007, Keith Moore wrote: > >>> Are you fine with a sockaddr_hit structure that contains only the HIT >>> and letting a getsockopt() call to figure out the IP addresses in the >>> context of HIP aware applications? (I think getsockname and >>> getpeername should return the HITs.) >> >> if the sockaddr_hit structure contains only the HIT, how is the kernel >> going to know where it can contact that peer? It has to get one or more >> IP addresses from somewhere. > > If the resolver is used, it can send a hint containing this mapping to > the HIP daemon. please no. don't try to hide this stuff from the app in the low-level API. the rest of the network keeps trying to force routing decisions on the apps in the absence of routing information. ideally, the app shouldn't have to be doing any routing or address selection or anything. but at present, how to cope with this kind of world is an unsolved problem, and the only place where experimentation can be done towards learning how to solve that problem is at layer 7. if you cripple the API, you prevent that kind of experimentation (at worst) or (at best) increase the burden on the app writer by forcing him to write his own kernel extensions. that, and you still need to expose IP addresses for diagnostic purposes. what do you gain from trying to hide the IP addresses? APIs should not try to be smarter than the apps that use them - they will always fail at this. (actually this goes for any kind of middleware) Keith From discuss-bounces@apps.ietf.org Fri May 11 16:59:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmcDE-0005m8-70; Fri, 11 May 2007 16:59:40 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HmcDD-0005m3-JU for discuss-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 16:59:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmcDD-0005lv-A5 for discuss@apps.ietf.org; Fri, 11 May 2007 16:59:39 -0400 Received: from ka.cs.utk.edu ([160.36.56.221]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmcDC-0000j0-3z for discuss@apps.ietf.org; Fri, 11 May 2007 16:59:39 -0400 Received: from localhost (localhost [127.0.0.1]) by ka.cs.utk.edu (Postfix) with ESMTP id 82110CB3B7; Fri, 11 May 2007 16:59:37 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from ka.cs.utk.edu ([127.0.0.1]) by localhost (ka.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsSygfA4OEyD; Fri, 11 May 2007 16:59:30 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by ka.cs.utk.edu (Postfix) with ESMTP id 59471CB3EB; Fri, 11 May 2007 16:59:30 -0400 (EDT) Message-ID: <4644D931.6030701@cs.utk.edu> Date: Fri, 11 May 2007 16:59:29 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Miika Komu Subject: Re: sockets APIs extensions for Host Identity Protocol References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <4641D94C.9070304@cs.utk.edu> <46436B10.5090706@cs.utk.edu> <4643F873.3000501@cs.utk.edu> <46442588.7020405@cs.utk.edu> <200705111314.JAA17866@Sparkle.Rodents.Montreal.QC.CA> <4644830D.7050302@cs.utk.edu> <200705111642.MAA19058@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: der Mouse , discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > The getaddrinfo may have its shortcomings, but it does not really > prevent to write HIP bindings for it. clearly it can be done. but some things do not deserve to live. From discuss-bounces@apps.ietf.org Fri May 11 17:18:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmcVh-0007zS-9B; Fri, 11 May 2007 17:18:45 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HmcVg-0007zN-HP for discuss-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 17:18:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmcVg-0007yG-6m for discuss@apps.ietf.org; Fri, 11 May 2007 17:18:44 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmcVe-00059S-SG for discuss@apps.ietf.org; Fri, 11 May 2007 17:18:44 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 047D82CFB; Sat, 12 May 2007 00:18:37 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070322 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070322 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 7F5042CA5; Sat, 12 May 2007 00:18:37 +0300 (EEST) Date: Sat, 12 May 2007 00:18:37 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Keith Moore Subject: Re: sockets APIs extensions for Host Identity Protocol In-Reply-To: <4644D90B.1020304@cs.utk.edu> Message-ID: References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <4641D94C.9070304@cs.utk.edu> <46436B10.5090706@cs.utk.edu> <4643F873.3000501@cs.utk.edu> <46442588.7020405@cs.utk.edu> <4644779F.60805@cs.utk.edu> <4644CD76.10900@cs.utk.edu> <4644D90B.1020304@cs.utk.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Fri, 11 May 2007, Keith Moore wrote: > please no. don't try to hide this stuff from the app in the low-level > API. the rest of the network keeps trying to force routing decisions > on the apps in the absence of routing information. ideally, the app > shouldn't have to be doing any routing or address selection or > anything. but at present, how to cope with this kind of world is an > unsolved problem, and the only place where experimentation can be done > towards learning how to solve that problem is at layer 7. if you > cripple the API, you prevent that kind of experimentation (at worst) or > (at best) increase the burden on the app writer by forcing him to write > his own kernel extensions. > > that, and you still need to expose IP addresses for diagnostic purposes. > > what do you gain from trying to hide the IP addresses? First, to discourage the use of IP addresses as referrals because application developer would have to fetch them using a separate function call. But maybe this is a weak justification... Second, the socket address structure is constrained to 255 bytes. It will fit "only" 1 HIT and 15 addresses. Is this enough for e.g. routers? -- Miika Komu http://www.iki.fi/miika/ From discuss-bounces@apps.ietf.org Fri May 11 17:47:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmcxx-0005SB-BF; Fri, 11 May 2007 17:47:57 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hmcxw-0005S6-N8 for discuss-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 17:47:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmcxv-0005Ry-Gw for discuss@apps.ietf.org; Fri, 11 May 2007 17:47:56 -0400 Received: from ka.cs.utk.edu ([160.36.56.221]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hmcxu-0005qA-8g for discuss@apps.ietf.org; Fri, 11 May 2007 17:47:55 -0400 Received: from localhost (localhost [127.0.0.1]) by ka.cs.utk.edu (Postfix) with ESMTP id D2A75CB3E0; Fri, 11 May 2007 17:47:53 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from ka.cs.utk.edu ([127.0.0.1]) by localhost (ka.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09dY026FQE43; Fri, 11 May 2007 17:47:37 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by ka.cs.utk.edu (Postfix) with ESMTP id 7323CCB3EA; Fri, 11 May 2007 17:47:37 -0400 (EDT) Message-ID: <4644E478.1070804@cs.utk.edu> Date: Fri, 11 May 2007 17:47:36 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Miika Komu Subject: Re: sockets APIs extensions for Host Identity Protocol References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <4641D94C.9070304@cs.utk.edu> <46436B10.5090706@cs.utk.edu> <4643F873.3000501@cs.utk.edu> <46442588.7020405@cs.utk.edu> <4644779F.60805@cs.utk.edu> <4644CD76.10900@cs.utk.edu> <4644D90B.1020304@cs.utk.edu> In-Reply-To: X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Miika Komu wrote: > On Fri, 11 May 2007, Keith Moore wrote: > >> please no. don't try to hide this stuff from the app in the low-level >> API. the rest of the network keeps trying to force routing decisions >> on the apps in the absence of routing information. ideally, the app >> shouldn't have to be doing any routing or address selection or >> anything. but at present, how to cope with this kind of world is an >> unsolved problem, and the only place where experimentation can be done >> towards learning how to solve that problem is at layer 7. if you >> cripple the API, you prevent that kind of experimentation (at worst) or >> (at best) increase the burden on the app writer by forcing him to write >> his own kernel extensions. >> >> that, and you still need to expose IP addresses for diagnostic purposes. >> >> what do you gain from trying to hide the IP addresses? > > First, to discourage the use of IP addresses as referrals because > application developer would have to fetch them using a separate > function call. But maybe this is a weak justification... Second, the > socket address structure is constrained to 255 bytes. It will fit > "only" 1 HIT and 15 addresses. Is this enough for e.g. routers? perhaps strangely, the latter justification makes more sense to me. no, 15 addresses is not enough. but it's not acceptable to have the IP addresses passed implicitly from the resolver to the socket. offhand, I'd say that a good compromise would be to allow some reasonable number of addresses to be specified using sockaddr_hip and to allow more peer addresses to be added using a setsockopt() call. From discuss-bounces@apps.ietf.org Fri May 11 19:46:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmeog-0002xD-Ho; Fri, 11 May 2007 19:46:30 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hmeoe-0002x8-Lc for discuss-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 19:46:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmeoe-0002x0-Bq for discuss@apps.ietf.org; Fri, 11 May 2007 19:46:28 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hmeoc-0007kn-Qc for discuss@apps.ietf.org; Fri, 11 May 2007 19:46:28 -0400 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4BNkQai026187 for ; Fri, 11 May 2007 23:46:26 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JHW00201GZNRK00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for discuss@apps.ietf.org; Fri, 11 May 2007 17:46:26 -0600 (MDT) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHW00308I1AVR00@mail-amer.sun.com>; Fri, 11 May 2007 17:46:25 -0600 (MDT) Date: Fri, 11 May 2007 16:46:25 -0700 From: Chris Newman Subject: RE: sockets APIs extensions for Host Identity Protocol In-reply-to: <77F357662F8BFA4CA7074B0410171B6D040492F2@XCH-NW-5V1.nw.nos.boeing.com> To: "Henderson, Thomas R" , Miika Komu , discuss@apps.ietf.org Message-id: <0DC32C985E2B5065559C802B@[10.1.110.5]> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <77F357662F8BFA4CA7074B0410171B6D040492F2@XCH-NW-5V1.nw.nos.boeing.c om> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Henderson, Thomas R wrote on 5/8/07 9:43 -0700: > Is the IETF in the business of defining this new API? Or is the IETF > scope limited to sockets, and the APIs that you seek are defined by > library and OS developers? The IETF's primary focus is to standardize protocols. But standard protocols are of little value if they aren't deployed. There are various ways to assist deployment of protocols and documented APIs are one way. The IETF has a long tradition of publishing APIs, mostly as informational but occasionally on the standards track. There are IETF published APIs of dubious quality that have still significantly helped deploy the underlying protocol (I'd point to the LDAP API as an example in the applications space). > As a HIP WG participant, I see that there has been a history of RFCs for > sockets API extensions (2292, 2960, 4584, etc.). We could do a similar > one for HIP, but Miika has proposed that we go for a more future-proof > API and build in some abstraction. It seems to me that there is support > for defining such an API and it has already been done successfully for > Java. The primary design goal for an IETF API should be to ease deployment of IETF standards-track protocols. If the APIs designed to ease deployment of HIP also ease deployment of IPv6 (which is clearly problematic), that would be a good thing. The key principles from this discussion are: * Don't bother the busy/lazy/dumb programmers with details they don't need or want to know (my point) * Don't hide any details from programmers who do care (Keith's point) Data hiding is often good, data losing is always bad. Be careful to avoid the latter when designing those abstractions. - Chris From discuss-bounces@apps.ietf.org Fri May 11 19:59:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmf1K-00025E-9m; Fri, 11 May 2007 19:59:34 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hmf1I-000253-Ti for discuss-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 19:59:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmf1I-00024v-KC for discuss@apps.ietf.org; Fri, 11 May 2007 19:59:32 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hmf1H-0003IX-1l for discuss@apps.ietf.org; Fri, 11 May 2007 19:59:32 -0400 Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4BNxU4p010475 for ; Fri, 11 May 2007 23:59:30 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JHW00901I51EQ00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for discuss@apps.ietf.org; Fri, 11 May 2007 17:59:30 -0600 (MDT) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHW0081OIN4NV00@mail-amer.sun.com>; Fri, 11 May 2007 17:59:30 -0600 (MDT) Date: Fri, 11 May 2007 16:59:31 -0700 From: Chris Newman Subject: Re: sockets APIs extensions for Host Identity Protocol In-reply-to: <200705111642.MAA19058@Sparkle.Rodents.Montreal.QC.CA> To: der Mouse , discuss@apps.ietf.org Message-id: <5F2A1D00CBD4D0FCFF766616@[10.1.110.5]> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <4641D94C.9070304@cs.utk.edu> <46436B10.5090706@cs.utk.edu> <4643F873.3000501@cs.utk.edu> <46442588.7020405@cs.utk.edu> <200705111314.JAA17866@Sparkle.Rodents.Montreal.QC.CA> <4644830D.7050302@cs.utk.edu> <200705111642.MAA19058@Sparkle.Rodents.Montreal.QC.CA> X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org der Mouse wrote on 5/11/07 12:02 -0400: >> - getaddrinfo encourages use of string constants to specify ports, >> rather than numeric constants, which is wrong - > > No, this is very right. The notion that "ports" are small integers is > a *horribly* IP-centric notion. DECnet, for example, uses short > strings (8-char? 12-char? I don't know the limit) which do *not* have > to map into numbers - I think X over DECnet, for example, uses "port" > strings like "X$0" and "X$1". Making an IETF-defined API more complex in order to accommodate non-IETF technology seems to go against the primary purpose of an IETF-defined API (to ease deployment of IETF protocols). >> - it has no way to be used asynchronously other than to put each call >> to getaddrinfo in a separate thread, > > Neither does gethostbyname(). And, without a lot of callback or AIO > scaffolding - or threading - it *can't*. The sockets API, on the other hand, provides a convenient socket option and socket fd/handle suitable for asynchronous use. Even though the only universal API to wait for async socket activity has a terrible design, the simple concept of an fd/handle for a socket has allowed operating systems to independently develop different asynchronous scaffolding (e.g., poll, /dev/poll, port_associate, kqueue, CFNetwork, etc). So it's possible to design an asynchronous-friendly API (like sockets) without limiting the scaffolding and with minimal impact on synchronous users. - Chris From discuss-bounces@apps.ietf.org Fri May 11 21:26:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmgN5-0008Ix-OC; Fri, 11 May 2007 21:26:07 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HmgN4-0008Is-Es for discuss-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 21:26:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmgN4-0008Ik-5N for discuss@apps.ietf.org; Fri, 11 May 2007 21:26:06 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmgN3-0007MT-K2 for discuss@apps.ietf.org; Fri, 11 May 2007 21:26:06 -0400 Received: from fe-amer-09.sun.com ([192.18.108.183]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4C1Q5XL016456 for ; Sat, 12 May 2007 01:26:05 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JHW00D01MF04100@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for discuss@apps.ietf.org; Fri, 11 May 2007 19:26:05 -0600 (MDT) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHW0040TMNEZI00@mail-amer.sun.com>; Fri, 11 May 2007 19:26:05 -0600 (MDT) Date: Fri, 11 May 2007 18:26:05 -0700 From: Chris Newman Subject: Re: sockets APIs extensions for Host Identity Protocol In-reply-to: <46413E7D.5060403@cs.utk.edu> To: Keith Moore Message-id: <992D430ADF32E9A2C10E3B3B@[10.1.110.5]> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <31BC7A8C1A51004A84E08DEF@[10.1.110.5]> <46413E7D.5060403@cs.utk.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Very simple APIs that solve the 90-95% case are extremely helpful. Just because we also need APIs for the 5-10% case doesn't mean everyone should be forced to use the more complex APIs all the time. One of the reasons HTTP is used (abused) so much is because the deployed APIs are very simple, indeed much simpler than sockets. I've met programmers who will gladly toss stuff over HTTP but consider TCP far too complex to consider using. This is very destructive to the actual complexity and security of the system. But that simply doesn't matter to the vast majority of programmers when it saves days/weeks of programming time to use the higher level API. It's also true that many of the deployed HTTP APIs limit control over HTTP headers and methods in such a way that it's impossible to use those APIs and follow all the advice in BCP 56. We've seen similar problems with DNS RR labels and DNS APIs. So API designs need to pay attention to both problems and good APIs often have both "simple" and "powerful" entry points. For example, sockets has read/write and recvmsg/sendmsg. As a programmer, I'd really hate to be forced to use the latter for all network I/O. This is an area where good protocol design and good API design differs. The primary goal of good protocol design is interoperability so infrequently used features are bad. The primary goals of (IETF) API design are ease-of-use to aid deployment and transparency to avoid data losing -- those requirements often force a good design to have infrequently used features. - Chris Keith Moore wrote on 5/8/07 23:22 -0400: > >> If I change my "connectbyname" code again, I will change it once more >> to use a new OS API that hides all the v4 vs. v6 vs. HIP vs. whatever >> junk, preferably to something much simpler than the code today. If >> such an API isn't produced, I will be very reluctant to change that >> code no matter how cool HIP might or might not be. > > If you can figure out how to write that kind of code in a way that works > well for a wide variety of applications, with different requirements for > bandwidth, stability, mobility, etc. all of which affect address > selection, interface selection, etc., and do all of that efficiently and > in the absence of routing information from the network, you should > probably get a prize of some sort. > > Granted that programmers want a simple interface, but the more complex > the network gets, the more apps will be expected to do jobs that were > supposed to be done at layer 3. > > Keith > > From discuss-bounces@apps.ietf.org Sat May 12 12:35:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmuZC-0003xa-Br; Sat, 12 May 2007 12:35:34 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HmuZA-0003wV-UM for discuss-confirm+ok@megatron.ietf.org; Sat, 12 May 2007 12:35:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmuZ8-0003v3-Jn for discuss@apps.ietf.org; Sat, 12 May 2007 12:35:31 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmuZ4-0006KA-MA for discuss@apps.ietf.org; Sat, 12 May 2007 12:35:30 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 5A13B2D4E; Sat, 12 May 2007 19:35:17 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070322 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070322 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id AC8C42D4A; Sat, 12 May 2007 19:35:16 +0300 (EEST) Date: Sat, 12 May 2007 19:35:16 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Keith Moore Subject: Re: sockets APIs extensions for Host Identity Protocol In-Reply-To: <4644E478.1070804@cs.utk.edu> Message-ID: References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <4641D94C.9070304@cs.utk.edu> <46436B10.5090706@cs.utk.edu> <4643F873.3000501@cs.utk.edu> <46442588.7020405@cs.utk.edu> <4644779F.60805@cs.utk.edu> <4644CD76.10900@cs.utk.edu> <4644D90B.1020304@cs.utk.edu> <4644E478.1070804@cs.utk.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Fri, 11 May 2007, Keith Moore wrote: Hi Keith, > Miika Komu wrote: >> On Fri, 11 May 2007, Keith Moore wrote: >> >>> please no. don't try to hide this stuff from the app in the low-level >>> API. the rest of the network keeps trying to force routing decisions >>> on the apps in the absence of routing information. ideally, the app >>> shouldn't have to be doing any routing or address selection or >>> anything. but at present, how to cope with this kind of world is an >>> unsolved problem, and the only place where experimentation can be done >>> towards learning how to solve that problem is at layer 7. if you >>> cripple the API, you prevent that kind of experimentation (at worst) or >>> (at best) increase the burden on the app writer by forcing him to write >>> his own kernel extensions. >>> >>> that, and you still need to expose IP addresses for diagnostic purposes. >>> >>> what do you gain from trying to hide the IP addresses? >> >> First, to discourage the use of IP addresses as referrals because >> application developer would have to fetch them using a separate >> function call. But maybe this is a weak justification... Second, the >> socket address structure is constrained to 255 bytes. It will fit >> "only" 1 HIT and 15 addresses. Is this enough for e.g. routers? > > perhaps strangely, the latter justification makes more sense to me. no, > 15 addresses is not enough. but it's not acceptable to have the IP > addresses passed implicitly from the resolver to the socket. Actually, the addresses passed from the resolver would be system level "hints" rather than bound to a specific socket because getaddrinfo resolver does not know anything about the sockets. What is the exact reason why you see this as an bad idea? > offhand, I'd say that a good compromise would be to allow some > reasonable number of addresses to be specified using sockaddr_hip and to > allow more peer addresses to be added using a setsockopt() call. I don't see how this would work with the resolver? I guess the only way would be to output several HITs redundantly, but with different IP addresses. Would this work for you? I thought about size limitations in more detail. A naive version of sockaddr_hip structure and its fields could look as follows based on the discussion: struct sockaddr_hip { uint8_t sinh_len; /* 1 byte */ sa_family_t sinh_family; /* 1 byte */ in_port_t sinh_port; /* 2 bytes */ struct in6_addr sinh_hit; /* 16 bytes */ struct sockaddr_in6 sinh_loc[2]; /* 2 * 112 bytes */ } /* total: 244 bytes (note: maximum size 255 bytes) */ Here I just put two IPv6 addresses inside the structure and assume that we use IPv4 address in IPv4-in-IPv6 format. I know that we could insert more than two in_addr structures, but it is more complicated to handle. Also, I think it is important to have the flowlabels etc for IPv6 addresses, so we don't use in6_addr for locators. The port is defined twice; we could use the locator port to set the ESP-IN-UDP port number. The HIT takes 16 bytes. For future extensions purposes, I would actually suggest to take the "back-up" locator away and reuse its space with 16 bytes of reserved space just after the HIT. This way, we could have future expansion space for 256 bit HITs? And the single locator would fit nicely to the resolver scheme described above. What about datagram oriented communications? What should happen when the HIT and socket remain the same, but locator changes between two sendto() calls? I guess it could be used for enforcing an handover. There also some other protocols around with their own socket address structures (un, ipx, atmpvc, ax25, irda, rose, tipc, ash, ec). Perhaps it would be more wiser to fix IPv6 format at the API layer and define the sinh_loc just as an generic sockaddr. Does this make sense? I guess this is getting quite specific already, so it may be a better idea to move the discussion to HIP mailing lists? -- Miika Komu http://www.iki.fi/miika/ From discuss-bounces@apps.ietf.org Sat May 12 17:06:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmyn1-0005OS-Ar; Sat, 12 May 2007 17:06:07 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hmymz-0005Hv-TI for discuss-confirm+ok@megatron.ietf.org; Sat, 12 May 2007 17:06:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmymz-0005Fy-Ie for discuss@apps.ietf.org; Sat, 12 May 2007 17:06:05 -0400 Received: from sparkle.rodents.montreal.qc.ca ([216.46.5.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hmymy-0000Ht-SA for discuss@apps.ietf.org; Sat, 12 May 2007 17:06:05 -0400 Received: from localhost (localhost [[UNIX: localhost]]) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id RAA01484; Sat, 12 May 2007 17:06:00 -0400 (EDT) From: der Mouse Message-Id: <200705122106.RAA01484@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Sat, 12 May 2007 16:21:24 -0400 (EDT) To: discuss@apps.ietf.org Subject: Re: sockets APIs extensions for Host Identity Protocol In-Reply-To: <4644D7D7.50109@cs.utk.edu> References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <4641D94C.9070304@cs.utk.edu> <46436B10.5090706@cs.utk.edu> <4643F873.3000501@cs.utk.edu> <46442588.7020405@cs.utk.edu> <200705111314.JAA17866@Sparkle.Rodents.Montreal.QC.CA> <4644830D.7050302@cs.utk.edu> <200705111642.MAA19058@Sparkle.Rodents.Montreal.QC.CA> <4644D7D7.50109@cs.utk.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >> The major thing *I* use it for is to insulate the application from >> knowledge of what address families are available. > that's just fine for some corner cases, and if it works for your app, > great - but it's not the general case. My "app"? My app*s*. I've converted probably at least a dozen programs to getaddrinfo(), and so far the only one that has had to pry off the AF-independence hood is a netcat variant which has specific command-line options to control use of IPv4 and/or IPv6 - and even that one is ready to handle address families other than v4 and v6 if you don't use those options. I can only infer that you and I work on rather different sorts of networking code. :-) > for instance, SMTP over DECnet (which does exist, or at least did > exist) imposed a maximum line length of 512 bytes. I'd argue that's not SMTP, but a different protocol confusingly similar to SMTP. SMTP is relatively well-defined and is rather specifically *not* tied to TCP: SMTP is independent of the particular transmission subsystem and requires only a reliable ordered data stream channel. While this document specifically discusses transport over TCP, other transports are possible. Appendices to RFC 821 describe some of them. > again, it's nice that getaddrinfo() gives you a way to pretend that > IPv4 and IPv6 are interchangeable for the benefit of the apps that > can use that feature, but it's not as if all apps can or should work > that way. Oh, certainly. But that's also no reason to impose AF-awareness on apps that *don't* need it, and as far as I have seen getaddrinfo() is the only C-language alternative that doesn't impose AF-awareness now. Have I missed something? >>> - it's actually more difficult to set the parameters for >>> getaddrinfo() to get it to do what you want, than it is to >>> initialize the fields in a sockaddr_in* >> I find it about evenly balanced whether getaddrinfo() or doing both >> INET* AFs is messier, more difficult, whatever. > there are more quirks than that. you have to know whether you have a > numeric address and port. I have never had to care. Perhaps this just means I've never run into a suitably misbehaving getaddrinfo().... >>> - getaddrinfo encourages use of string constants to specify ports, >>> rather than numeric constants, which is wrong - >> No, this is very right. > sorry, I've spent way too much time debugging brain-damaged code that > used getservbyname() and which failed when the NIS server went down > or the /etc/services file got corrupted EVEN THOUGH THE PORT TO BE > USED WAS A DEFINED CONSTANT IN THE PROTOCOL SPECIFICATION. As the people running ssh on ports other than 22 - or SMTP on ports other than 25 - attest (or, more precisely, running a protocol otherwise just like ssh on a port other than 22, or a protocol otherwise just like SMTP on a port other than 25), those "defined constant"s *aren't* constant in practice. I still maintain that using strings to name ports is right. >> The notion that "ports" are small integers is a *horribly* >> IP-centric notion. > and the vast majority of our protocols are, by definition, IP > centric. Really? Most of the specs I've read say things like "can run over any bidirectional flow-controlled octet stream; when used with TCP, uses port NN by default" and are actually not IP-centric at all. Perhaps you and I have just been working with different sorts of protocols. > part of the problem is, the definition of the function doesn't > actually say what the function does with respect to DNS because it's > too vague - probably as a result of trying to take future > hypothetical networking stacks into account. True. But I think that's better than sticking it with dependency on current technologies and having to replace it entirely when something new comes out. That's what happened with gethostbyname() - which assumes a host will have addresses in at most one address family - and, while I won't say getaddrinfo() is entirely right, I think its attempt to future-proof applications *is* right. (The desire, that is, not necessarily the way it went about it.) >>> - it's not specified to use DNS. >> But it can't really be specified to use DNS, since it is not >> restricted to address families that the DNS supports > that's a bug, not a feature. I think we'll have to disagree on this. But I do know that if something arises which is defined to use the DNS, I - and anyone else building code which needs to be useful in environments such as isolated networks where DNS is not available - will simply not use it. (For general-purpose name->address resolution, that is. I've written code using DNS-specific calls, but only for things such as MX lookup tools where the job is inherently DNS-dependent.) > I've seen so much variation between implementations of getaddrinfo > that I've become convinced that it needs to be replaced for that > reason alone. Perhaps. But I strongly believe that in order to be useful, any replacement needs to at least support (not necessarily compel) AF-agnostic code. I'd prefer to see it support string port names, too, but that is relatively easy to fix with a wrapper replacement as necessary. > But the variation seems to have resulted from two things: the > vagueness of the spec (in turn the result of overgenerality) and a > demand to get the interface nailed down before the requirements were > understood. I see getaddrinfo() as an experiment in generalizing gethostbyname(). You see it as unfixably flawed while I see it as fixably flawed; that's not that big a deal (though it's annoying to have to rewrite all my networking code *again* for yet another new API). I think the important disagreements are over what lessons the experiment has to teach us. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From discuss-bounces@apps.ietf.org Sat May 12 17:07:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmyoY-00068s-Rk; Sat, 12 May 2007 17:07:42 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HmyoX-00068n-IY for discuss-confirm+ok@megatron.ietf.org; Sat, 12 May 2007 17:07:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmyoX-00068f-97 for discuss@apps.ietf.org; Sat, 12 May 2007 17:07:41 -0400 Received: from sparkle.rodents.montreal.qc.ca ([216.46.5.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmyoV-0000cU-Rf for discuss@apps.ietf.org; Sat, 12 May 2007 17:07:41 -0400 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id RAA01505; Sat, 12 May 2007 17:07:39 -0400 (EDT) From: der Mouse Message-Id: <200705122107.RAA01505@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Sat, 12 May 2007 17:06:25 -0400 (EDT) To: discuss@apps.ietf.org Subject: Re: sockets APIs extensions for Host Identity Protocol In-Reply-To: References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <4641D94C.9070304@cs.utk.edu> <46436B10.5090706@cs.utk.edu> <4643F873.3000501@cs.utk.edu> <46442588.7020405@cs.utk.edu> <4644779F.60805@cs.utk.edu> <4644CD76.10900@cs.utk.edu> <4644D90B.1020304@cs.utk.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > Second, the socket address structure is constrained to 255 bytes. This limit borders on trivial to raise. Well, unless you're trying to do this on an OS whose source is closed to you, which I submit is a bad vehicle for such research for exactly this kind of reason. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From discuss-bounces@apps.ietf.org Sat May 12 17:23:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmz3l-0006s7-4p; Sat, 12 May 2007 17:23:25 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hmz3k-0006s2-A6 for discuss-confirm+ok@megatron.ietf.org; Sat, 12 May 2007 17:23:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmz3k-0006ru-0e for discuss@apps.ietf.org; Sat, 12 May 2007 17:23:24 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hmz3g-0002EL-Mx for discuss@apps.ietf.org; Sat, 12 May 2007 17:23:23 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id EE5962D4E; Sun, 13 May 2007 00:23:17 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070322 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070322 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 82E8B2D45; Sun, 13 May 2007 00:23:17 +0300 (EEST) Date: Sun, 13 May 2007 00:23:17 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: der Mouse Subject: Re: sockets APIs extensions for Host Identity Protocol In-Reply-To: <200705122107.RAA01505@Sparkle.Rodents.Montreal.QC.CA> Message-ID: References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <4641D94C.9070304@cs.utk.edu> <46436B10.5090706@cs.utk.edu> <4643F873.3000501@cs.utk.edu> <46442588.7020405@cs.utk.edu> <4644779F.60805@cs.utk.edu> <4644CD76.10900@cs.utk.edu> <4644D90B.1020304@cs.utk.edu> <200705122107.RAA01505@Sparkle.Rodents.Montreal.QC.CA> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Sat, 12 May 2007, der Mouse wrote: >> Second, the socket address structure is constrained to 255 bytes. > > This limit borders on trivial to raise. > > Well, unless you're trying to do this on an OS whose source is closed > to you, which I submit is a bad vehicle for such research for exactly > this kind of reason. Why is it "trivial" to raise? I think it will raise all sorts of backwards compatibility problems. -- Miika Komu http://www.iki.fi/miika/ From discuss-bounces@apps.ietf.org Sat May 12 17:50:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmzUK-0004w4-2z; Sat, 12 May 2007 17:50:52 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HmzUI-0004vz-Rs for discuss-confirm+ok@megatron.ietf.org; Sat, 12 May 2007 17:50:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmzUI-0004vr-IQ for discuss@apps.ietf.org; Sat, 12 May 2007 17:50:50 -0400 Received: from sparkle.rodents.montreal.qc.ca ([216.46.5.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmzUH-0005K3-00 for discuss@apps.ietf.org; Sat, 12 May 2007 17:50:50 -0400 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id RAA01766; Sat, 12 May 2007 17:50:45 -0400 (EDT) From: der Mouse Message-Id: <200705122150.RAA01766@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Sat, 12 May 2007 17:47:57 -0400 (EDT) To: discuss@apps.ietf.org Subject: Re: sockets APIs extensions for Host Identity Protocol In-Reply-To: References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <4641D94C.9070304@cs.utk.edu> <46436B10.5090706@cs.utk.edu> <4643F873.3000501@cs.utk.edu> <46442588.7020405@cs.utk.edu> <4644779F.60805@cs.utk.edu> <4644CD76.10900@cs.utk.edu> <4644D90B.1020304@cs.utk.edu> <200705122107.RAA01505@Sparkle.Rodents.Montreal.QC.CA> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >>> Second, the socket address structure is constrained to 255 bytes. >> This limit borders on trivial to raise. >> Well, unless you're trying to do this on an OS whose source is >> closed to you, which I submit is a bad vehicle for such research for >> exactly this kind of reason. > Why is it "trivial" to raise? Just change sa_len, sin_len, sin6_len, sun_len, etc, to short instead of char. (You may want to rearrange the element order for better packing, but that's not essential, just helpful.) > I think it will raise all sorts of backwards compatibility problems. Only if you expect to recompile only part of the world. There might be code lurking that "knows" those fields max out at 255, but I'd say it's already broken. When (if) it comes to releasing OSes with the new _len fields, it gets a little more interesting, but I'd just version the affected calls and ignore the issue. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From discuss-bounces@apps.ietf.org Sun May 13 13:18:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnHiJ-00040n-Ja; Sun, 13 May 2007 13:18:31 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HnHiI-00040i-T6 for discuss-confirm+ok@megatron.ietf.org; Sun, 13 May 2007 13:18:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnHiI-00040a-Je for discuss@apps.ietf.org; Sun, 13 May 2007 13:18:30 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnHiF-0007Yl-8s for discuss@apps.ietf.org; Sun, 13 May 2007 13:18:30 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 0BE6E2D4F; Sun, 13 May 2007 20:18:22 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070322 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070322 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 7D1B12D48; Sun, 13 May 2007 20:18:21 +0300 (EEST) Date: Sun, 13 May 2007 20:18:21 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: der Mouse Subject: Re: sockets APIs extensions for Host Identity Protocol In-Reply-To: <200705122150.RAA01766@Sparkle.Rodents.Montreal.QC.CA> Message-ID: References: <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <4641D94C.9070304@cs.utk.edu> <46436B10.5090706@cs.utk.edu> <4643F873.3000501@cs.utk.edu> <46442588.7020405@cs.utk.edu> <4644779F.60805@cs.utk.edu> <4644CD76.10900@cs.utk.edu> <4644D90B.1020304@cs.utk.edu> <200705122107.RAA01505@Sparkle.Rodents.Montreal.QC.CA> <200705122150.RAA01766@Sparkle.Rodents.Montreal.QC.CA> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Sat, 12 May 2007, der Mouse wrote: >>>> Second, the socket address structure is constrained to 255 bytes. >>> This limit borders on trivial to raise. >>> Well, unless you're trying to do this on an OS whose source is >>> closed to you, which I submit is a bad vehicle for such research for >>> exactly this kind of reason. >> Why is it "trivial" to raise? > > Just change sa_len, sin_len, sin6_len, sun_len, etc, to short instead > of char. (You may want to rearrange the element order for better > packing, but that's not essential, just helpful.) > >> I think it will raise all sorts of backwards compatibility problems. > > Only if you expect to recompile only part of the world. There might be > code lurking that "knows" those fields max out at 255, but I'd say it's > already broken. Not all of the applications are open source. This change would break binary applications which is not very nice. The change would affect all sockets, not just HIP based sockets. > When (if) it comes to releasing OSes with the new _len fields, it gets > a little more interesting, but I'd just version the affected calls and > ignore the issue. I don't think that storing of 1 vs. N locators justifies this kind of a backwards incompatibility change. It is also a huge deployment barrier. -- Miika Komu http://www.iki.fi/miika/ From discuss-bounces@apps.ietf.org Mon May 14 09:43:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnapq-00032M-1O; Mon, 14 May 2007 09:43:34 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hnapo-0002xX-Jz for discuss-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 09:43:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnapo-0002xP-AH for discuss@apps.ietf.org; Mon, 14 May 2007 09:43:32 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnapl-0002P4-Tn for discuss@apps.ietf.org; Mon, 14 May 2007 09:43:32 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 305C91EE1AA; Mon, 14 May 2007 09:43:29 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6PGwNUKvsok; Mon, 14 May 2007 09:43:05 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 7A3B21EE1DB; Mon, 14 May 2007 09:43:04 -0400 (EDT) Message-ID: <46486767.3070809@cs.utk.edu> Date: Mon, 14 May 2007 09:43:03 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Miika Komu Subject: Re: sockets APIs extensions for Host Identity Protocol References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <4641D94C.9070304@cs.utk.edu> <46436B10.5090706@cs.utk.edu> <4643F873.3000501@cs.utk.edu> <46442588.7020405@cs.utk.edu> <4644779F.60805@cs.utk.edu> <4644CD76.10900@cs.utk.edu> <4644D90B.1020304@cs.utk.edu> <4644E478.1070804@cs.utk.edu> In-Reply-To: X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >> perhaps strangely, the latter justification makes more sense to me. no, >> 15 addresses is not enough. but it's not acceptable to have the IP >> addresses passed implicitly from the resolver to the socket. > > Actually, the addresses passed from the resolver would be system level > "hints" rather than bound to a specific socket because getaddrinfo > resolver does not know anything about the sockets. What is the exact > reason why you see this as an bad idea? there are lots of reasons. one is that it unnecessarily couples the resolver routines with the socket routines, and thereby imposes a dependency that isn't there now and shouldn't be there. in other words, you shouldn't be expected to use the system resolver (e.g. maybe you want to use an asynchronous DNS library). another reason is that it requires the kernel and/or library to manage state that's invisible and inaccessible to the application - and yet there will probably be situations that will cause the application to fail if the invisible state isn't managed like the application expects. for instance, consider an app that uses HITs for referrals layered on top of a kernel that keeps HIT-to-IP mappings only for a limited time before discarding them. if the app tries to send to a HIT after that time, the kernel isn't going to have the mapping any longer. >> offhand, I'd say that a good compromise would be to allow some >> reasonable number of addresses to be specified using sockaddr_hip and >> to allow more peer addresses to be added using a setsockopt() call. > > I don't see how this would work with the resolver? I guess the only > way would be to output several HITs redundantly, but with different IP > addresses. Would this work for you? I don't think I understand the question. You're going to need different routines to look up HITs, and HIT-to-IP mappings anyway. > > I thought about size limitations in more detail. A naive version of > sockaddr_hip structure and its fields could look as follows based on > the discussion: > > struct sockaddr_hip { > uint8_t sinh_len; /* 1 byte */ > sa_family_t sinh_family; /* 1 byte */ > in_port_t sinh_port; /* 2 bytes */ > struct in6_addr sinh_hit; /* 16 bytes */ > struct sockaddr_in6 sinh_loc[2]; /* 2 * 112 bytes */ > } /* total: 244 bytes (note: maximum size 255 bytes) */ > Here I just put two IPv6 addresses inside the structure and assume > that we use IPv4 address in IPv4-in-IPv6 format. I know that we could > insert more than two in_addr structures, but it is more complicated to > handle. Also, I think it is important to have the flowlabels etc for > IPv6 addresses, so we don't use in6_addr for locators. The port is > defined twice; we could use the locator port to set the ESP-IN-UDP > port number. given that the flow label field in the sockaddr_in6 field isn't even used in the implementations I've seen (my understanding is that it's not supposed to be copied to the IPv6 packet), this seems like overkill. I'd just put a list of in6_addrs in there. it bugs me a little bit that there's a port field in there, since HIP is a layer on top of IP, and there might be IP protocols that don't have ports. what if someone wants to run SCTP over HIP? > The HIT takes 16 bytes. For future extensions purposes, I would > actually suggest to take the "back-up" locator away and reuse its > space with 16 bytes of reserved space just after the HIT. This way, we > could have future expansion space for 256 bit HITs? And the single > locator would fit nicely to the resolver scheme described above. > > What about datagram oriented communications? What should happen when > the HIT and socket remain the same, but locator changes between two > sendto() calls? I guess it could be used for enforcing an handover. interesting question. actually I think that a HIP association should be able to exist between two hosts independently of any transport-level connection, and it might be appropriate to have calls to setup and discard such associations independently of any connection setup. that would yield two cases for datagram communications: in one case the HIP association would exist and the HIT-to-IP mappings would have been maintained to keep them current. in that case the sendto() would just work, since the sending host would already know how to route to that HIT. in the other case either there would be no association or no usable HIT-to-IP mappings (say there had been a network outage and all of the mappings had expired). in that case the sendto() would fail with something like "no route to host" and it would be up to the application to supply new mappings to the kernel. > There also some other protocols around with their own socket address > structures (un, ipx, atmpvc, ax25, irda, rose, tipc, ash, ec). Perhaps > it would be more wiser to fix IPv6 format at the API layer and define > the sinh_loc just as an generic sockaddr. > > Does this make sense? I guess this is getting quite specific already, > so it may be a better idea to move the discussion to HIP mailing lists? somehow I think it would be better if the API details were hashed out here, where they can get wider exposure within the apps area. Keith From discuss-bounces@apps.ietf.org Mon May 14 10:20:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnbPb-0006FN-Ks; Mon, 14 May 2007 10:20:31 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HnbPa-0006FI-Fc for discuss-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 10:20:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnbPa-0006FA-5t for discuss@apps.ietf.org; Mon, 14 May 2007 10:20:30 -0400 Received: from sparkle.rodents.montreal.qc.ca ([216.46.5.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnbPY-0004fF-OE for discuss@apps.ietf.org; Mon, 14 May 2007 10:20:30 -0400 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id KAA01987; Mon, 14 May 2007 10:20:26 -0400 (EDT) From: der Mouse Message-Id: <200705141420.KAA01987@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Mon, 14 May 2007 10:18:10 -0400 (EDT) To: discuss@apps.ietf.org Subject: Re: sockets APIs extensions for Host Identity Protocol In-Reply-To: References: <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <4641D94C.9070304@cs.utk.edu> <46436B10.5090706@cs.utk.edu> <4643F873.3000501@cs.utk.edu> <46442588.7020405@cs.utk.edu> <4644779F.60805@cs.utk.edu> <4644CD76.10900@cs.utk.edu> <4644D90B.1020304@cs.utk.edu> <200705122107.RAA01505@Sparkle.Rodents.Montreal.QC.CA> <200705122150.RAA01766@Sparkle.Rodents.Montreal.QC.CA> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >>> I think [raising the sa_len limit] will raise all sorts of >>> backwards compatibility problems. >> Only if you expect to recompile only part of the world. > Not all of the applications are open source. So, version the calls - this is the ABI compatability issue, and it applies to binary-only apps just as much as to old-binary compat. >> When (if) it comes to releasing OSes with the new _len fields, it >> gets a little more interesting, but I'd just version the affected >> calls and ignore the issue. > I don't think that storing of 1 vs. N locators justifies this kind of > a backwards incompatibility change. I don't see it as any worse than the incompatibility of switching that field from short to char in the first place. But perhaps that's just me. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From discuss-bounces@apps.ietf.org Mon May 14 10:22:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnbRr-0006oH-Gc; Mon, 14 May 2007 10:22:51 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HnbRq-0006oB-Jf for discuss-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 10:22:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnbRq-0006o3-9v for discuss@apps.ietf.org; Mon, 14 May 2007 10:22:50 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnbRp-00059k-1r for discuss@apps.ietf.org; Mon, 14 May 2007 10:22:50 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 3E9BE1EE1A5; Mon, 14 May 2007 10:22:48 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffiA8l0tt15N; Mon, 14 May 2007 10:22:29 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 17CDA1EE207; Mon, 14 May 2007 10:22:29 -0400 (EDT) Message-ID: <464870A4.7080801@cs.utk.edu> Date: Mon, 14 May 2007 10:22:28 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Miika Komu Subject: Re: sockets APIs extensions for Host Identity Protocol References: <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <4641D94C.9070304@cs.utk.edu> <46436B10.5090706@cs.utk.edu> <4643F873.3000501@cs.utk.edu> <46442588.7020405@cs.utk.edu> <4644779F.60805@cs.utk.edu> <4644CD76.10900@cs.utk.edu> <4644D90B.1020304@cs.utk.edu> <200705122107.RAA01505@Sparkle.Rodents.Montreal.QC.CA> <200705122150.RAA01766@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: der Mouse , discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org have to agree - simply making the length field bigger would break compatibility for binary object files. however, you might probably move the location of the length field, leave sa_family where it is, put a "must be zero" field in its place, and have the kernel code distinguish between old and new sockaddr structures by looking at sa_family. Keith >> Just change sa_len, sin_len, sin6_len, sun_len, etc, to short instead >> of char. (You may want to rearrange the element order for better >> packing, but that's not essential, just helpful.) >> >>> I think it will raise all sorts of backwards compatibility problems. >> >> Only if you expect to recompile only part of the world. There might be >> code lurking that "knows" those fields max out at 255, but I'd say it's >> already broken. > > Not all of the applications are open source. This change would break > binary applications which is not very nice. The change would affect > all sockets, not just HIP based sockets. > >> When (if) it comes to releasing OSes with the new _len fields, it gets >> a little more interesting, but I'd just version the affected calls and >> ignore the issue. > > I don't think that storing of 1 vs. N locators justifies this kind of > a backwards incompatibility change. It is also a huge deployment barrier. > From discuss-bounces@apps.ietf.org Mon May 14 10:56:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnbyn-00052N-5L; Mon, 14 May 2007 10:56:53 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hnbyl-00051O-48 for discuss-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 10:56:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnbyk-00051C-Pv for discuss@apps.ietf.org; Mon, 14 May 2007 10:56:50 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnbyi-0008E2-Jo for discuss@apps.ietf.org; Mon, 14 May 2007 10:56:50 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 06F922D82; Mon, 14 May 2007 17:56:48 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070322 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070322 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 1BF472D33; Mon, 14 May 2007 17:56:47 +0300 (EEST) Date: Mon, 14 May 2007 17:56:46 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Keith Moore Subject: Re: sockets APIs extensions for Host Identity Protocol In-Reply-To: <46486767.3070809@cs.utk.edu> Message-ID: References: <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <4641D94C.9070304@cs.utk.edu> <46436B10.5090706@cs.utk.edu> <4643F873.3000501@cs.utk.edu> <46442588.7020405@cs.utk.edu> <4644779F.60805@cs.utk.edu> <4644CD76.10900@cs.utk.edu> <4644D90B.1020304@cs.utk.edu> <4644E478.1070804@cs.utk.edu> <46486767.3070809@cs.utk.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Mon, 14 May 2007, Keith Moore wrote: > >>> perhaps strangely, the latter justification makes more sense to me. no, >>> 15 addresses is not enough. but it's not acceptable to have the IP >>> addresses passed implicitly from the resolver to the socket. >> >> Actually, the addresses passed from the resolver would be system level >> "hints" rather than bound to a specific socket because getaddrinfo >> resolver does not know anything about the sockets. What is the exact >> reason why you see this as an bad idea? > > there are lots of reasons. one is that it unnecessarily couples the > resolver routines with the socket routines, and thereby imposes a > dependency that isn't there now and shouldn't be there. in other words, > you shouldn't be expected to use the system resolver (e.g. maybe you > want to use an asynchronous DNS library). another reason is that it > requires the kernel and/or library to manage state that's invisible and > inaccessible to the application - and yet there will probably be > situations that will cause the application to fail if the invisible > state isn't managed like the application expects. for instance, > consider an app that uses HITs for referrals layered on top of a kernel > that keeps HIT-to-IP mappings only for a limited time before discarding > them. if the app tries to send to a HIT after that time, the kernel > isn't going to have the mapping any longer. Ok. FYI, there is a draft about HIT lookup using DHT: http://www.ietf.org/internet-drafts/draft-ahrenholz-hiprg-dht-01.txt >>> offhand, I'd say that a good compromise would be to allow some >>> reasonable number of addresses to be specified using sockaddr_hip and >>> to allow more peer addresses to be added using a setsockopt() call. >> >> I don't see how this would work with the resolver? I guess the only >> way would be to output several HITs redundantly, but with different IP >> addresses. Would this work for you? > > I don't think I understand the question. You're going to need > different routines to look up HITs, and HIT-to-IP mappings anyway. It gets sort of complicated to do two separate lookups in separate function calls. In addition, the HIT lookup may or may not work because HITs are flat identifiers. I'd just a use single function call. Let's take an example of looking up "foo.bar" which maps to HIT1, HIT2, HIT3 and IP1, IP2, IP3, IP4, IP5, IP6. We can return the following from the resolver: item1: HIT1+IP1,IP2,IP3,IP4,IP5,IP6 item2: HIT2+IP1,IP2,IP3,IP4,IP5,IP6 item3: HIT3+IP1,IP2,IP3,IP4,IP5,IP6 But then we have to modify the size of the family in sockaddr. Alternatively, we can return: item1: HIT1+IP1 item2: HIT1+IP2 item3: HIT1+IP3 item4: HIT1+IP4 item5: HIT1+IP5 item6: HIT1+IP6 item7: HIT2+IP1 item8: HIT2+IP2 ... and now the family size does not change The drawback here is that this may reduce the latency to connect when some of the locators are broken especially when the application does not parallerize multiple connect() calls. I'd choose the second approach based on the earlier discussion that the intelligence should reside on the application or socket wrapper library. So we can assume that the entity operating on top of sockets API can do the right thing. The first approach is also inefficient. Even though longer socket address structures can be made to work, they require more sockaddr copying between userspace and kernelspace especially with datagram oriented sockets. Comments? > given that the flow label field in the sockaddr_in6 field isn't even > used in the implementations I've seen (my understanding is that it's not > supposed to be copied to the IPv6 packet), this seems like overkill. > I'd just put a list of in6_addrs in there. We have a tradeoff here between future compatibility (un, ipx, atmpvc, ax25, irda, rose, tipc, ash, ec), which requires sockaddr, and saving space for multiple IP addresses (in6addr). > it bugs me a little bit that there's a port field in there, since HIP is > a layer on top of IP, and there might be IP protocols that don't have > ports. what if someone wants to run SCTP over HIP? This would call for the sockaddr structure and encapsulating the port number inside that when needed? >> The HIT takes 16 bytes. For future extensions purposes, I would >> actually suggest to take the "back-up" locator away and reuse its >> space with 16 bytes of reserved space just after the HIT. This way, we >> could have future expansion space for 256 bit HITs? And the single >> locator would fit nicely to the resolver scheme described above. >> >> What about datagram oriented communications? What should happen when >> the HIT and socket remain the same, but locator changes between two >> sendto() calls? I guess it could be used for enforcing an handover. > > interesting question. actually I think that a HIP association should be > able to exist between two hosts independently of any transport-level > connection, and it might be appropriate to have calls to setup and > discard such associations independently of any connection setup. that > would yield two cases for datagram communications: in one case the HIP > association would exist and the HIT-to-IP mappings would have been > maintained to keep them current. in that case the sendto() would just > work, since the sending host would already know how to route to that > HIT. in the other case either there would be no association or no usable > HIT-to-IP mappings (say there had been a network outage and all of the > mappings had expired). in that case the sendto() would fail with > something like "no route to host" and it would be up to the application > to supply new mappings to the kernel. Yes. >> Does this make sense? I guess this is getting quite specific already, >> so it may be a better idea to move the discussion to HIP mailing lists? > > somehow I think it would be better if the API details were hashed out > here, where they can get wider exposure within the apps area. Ok. -- Miika Komu http://www.iki.fi/miika/ From discuss-bounces@apps.ietf.org Mon May 14 10:57:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnbyw-0005Ad-4U; Mon, 14 May 2007 10:57:02 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hnbyu-00059Z-Lz for discuss-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 10:57:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnbyu-00059F-Bl for discuss@apps.ietf.org; Mon, 14 May 2007 10:57:00 -0400 Received: from sparkle.rodents.montreal.qc.ca ([216.46.5.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnbyq-0008Fj-AJ for discuss@apps.ietf.org; Mon, 14 May 2007 10:57:00 -0400 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id KAA02283; Mon, 14 May 2007 10:56:54 -0400 (EDT) From: der Mouse Message-Id: <200705141456.KAA02283@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Mon, 14 May 2007 10:52:43 -0400 (EDT) To: discuss@apps.ietf.org Subject: Re: sockets APIs extensions for Host Identity Protocol In-Reply-To: <464870A4.7080801@cs.utk.edu> References: <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <4641D94C.9070304@cs.utk.edu> <46436B10.5090706@cs.utk.edu> <4643F873.3000501@cs.utk.edu> <46442588.7020405@cs.utk.edu> <4644779F.60805@cs.utk.edu> <4644CD76.10900@cs.utk.edu> <4644D90B.1020304@cs.utk.edu> <200705122107.RAA01505@Sparkle.Rodents.Montreal.QC.CA> <200705122150.RAA01766@Sparkle.Rodents.Montreal.QC.CA> <464870A4.7080801@cs.utk.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > have to agree - simply making the length field bigger would break > compatibility for binary object files. Yeah; as I mentioned, you just need to version the calls. > however, you might probably move the location of the length field, > leave sa_family where it is, put a "must be zero" field in its place, I really dislike that idea. sockaddr_in effectively has a "must be zero" field now, under at least some OSes, and I think it is a horrible botch. Doing this would also render existing working source broken by fiat (because it doesn't zero this new field), which strikes me as a very bad idea. Unless you mean, do this only for AF_HIT or whatever the new AF_ is, in which case only the MBZ comment applies - which I think is *also* a bad idea, because it means that sockaddr_hit cannot be punned with sockaddr or soackaddr_storage the way all other sockaddr_*s can be. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From discuss-bounces@apps.ietf.org Mon May 14 11:21:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HncMU-0003ie-Nk; Mon, 14 May 2007 11:21:22 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hnc2V-0006Cv-98 for discuss-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 11:00:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnc2U-0006Cn-Vk for discuss@apps.ietf.org; Mon, 14 May 2007 11:00:42 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnc2T-0000ta-HT for discuss@apps.ietf.org; Mon, 14 May 2007 11:00:42 -0400 Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l4EF0dpr027166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 14 May 2007 08:00:40 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 14 May 2007 08:00:37 -0700 To: discuss@apps.ietf.org From: Paul Hoffman Subject: Fwd: Last Call: draft-ietf-hip-applications (Using the Host Identity Protocol with Legacy Applications) to Experimental RFC Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-Mailman-Approved-At: Mon, 14 May 2007 11:21:19 -0400 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >X-test-idtracker: no >To: IETF-Announce >From: The IESG >Date: Mon, 14 May 2007 09:50:07 -0400 >X-Spam-Score: -2.8 (--) >X-Scan-Signature: d6b246023072368de71562c0ab503126 >Cc: hipsec@ietf.org >Subject: Last Call: draft-ietf-hip-applications (Using the Host Identity > Protocol with Legacy Applications) to Experimental RFC >X-BeenThere: ietf-announce@ietf.org >X-Mailman-Version: 2.1.5 >Reply-To: ietf@ietf.org >List-Id: ietf-announce.ietf.org >List-Unsubscribe: , > >List-Post: >List-Help: >List-Subscribe: , > > >The IESG has received a request from the Host Identity Protocol WG (hip) >to consider the following document: > >- 'Using the Host Identity Protocol with Legacy Applications ' > as an Experimental RFC > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send substantive comments to the >ietf@ietf.org mailing lists by 2007-05-28. Exceptionally, >comments may be sent to iesg@ietf.org instead. In either case, please >retain the beginning of the Subject line to allow automated sorting. > >The file can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-hip-applications-01.txt > > >IESG discussion can be tracked via >https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15488&rfc_flag=0 From discuss-bounces@apps.ietf.org Mon May 14 11:21:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HncMU-0003hI-HH; Mon, 14 May 2007 11:21:22 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HnbsF-0000Es-95 for discuss-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 10:50:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnbsE-0000Ek-Sg for discuss@apps.ietf.org; Mon, 14 May 2007 10:50:06 -0400 Received: from ppsw-2.csi.cam.ac.uk ([131.111.8.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnbsC-0005Te-JQ for discuss@apps.ietf.org; Mon, 14 May 2007 10:50:06 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:43073) by ppsw-2.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.152]:25) with esmtpa (EXTERNAL:fanf2) id 1Hnbs7-0001lM-8Y (Exim 4.63) (return-path ); Mon, 14 May 2007 15:49:59 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Hnbs7-0004GE-Jc (Exim 4.54) (return-path ); Mon, 14 May 2007 15:49:59 +0100 Date: Mon, 14 May 2007 15:49:59 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Keith Moore Subject: Re: sockets APIs extensions for Host Identity Protocol In-Reply-To: <464870A4.7080801@cs.utk.edu> Message-ID: References: <4641D94C.9070304@cs.utk.edu> <46436B10.5090706@cs.utk.edu> <4643F873.3000501@cs.utk.edu> <46442588.7020405@cs.utk.edu> <4644779F.60805@cs.utk.edu> <4644CD76.10900@cs.utk.edu> <4644D90B.1020304@cs.utk.edu> <200705122107.RAA01505@Sparkle.Rodents.Montreal.QC.CA> <200705122150.RAA01766@Sparkle.Rodents.Montreal.QC.CA> <464870A4.7080801@cs.utk.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-Mailman-Approved-At: Mon, 14 May 2007 11:21:19 -0400 Cc: der Mouse , discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Mon, 14 May 2007, Keith Moore wrote: > > however, you might probably move the location of the length field, leave > sa_family where it is, put a "must be zero" field in its place, and have > the kernel code distinguish between old and new sockaddr structures by > looking at sa_family. That has already been done for the 4.3BSD -> 4.4BSD sockets API changes. The sockaddr was originally designed to have an external length (as you can see in connect() and other calls) but 4.4BSD messed this up by moving to an embedded length field. Tony. -- f.a.n.finch http://dotat.at/ TYNE DOGGER: CYCLONIC 4 OR 5, OCCASIONALLY 6, BECOMING VARIABLE 3. MODERATE OR ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD. From discuss-bounces@apps.ietf.org Mon May 14 11:53:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hncr7-00049T-RK; Mon, 14 May 2007 11:53:01 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hncr6-00049H-Kc for discuss-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 11:53:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hncr6-000496-Aq for discuss@apps.ietf.org; Mon, 14 May 2007 11:53:00 -0400 Received: from sparkle.rodents.montreal.qc.ca ([216.46.5.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hncr4-0005h1-ST for discuss@apps.ietf.org; Mon, 14 May 2007 11:53:00 -0400 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id LAA02624; Mon, 14 May 2007 11:52:57 -0400 (EDT) From: der Mouse Message-Id: <200705141552.LAA02624@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Mon, 14 May 2007 11:40:49 -0400 (EDT) To: discuss@apps.ietf.org Subject: Re: sockets APIs extensions for Host Identity Protocol In-Reply-To: References: <31BC7A8C1A51004A84E08DEF@[10.1.110.5]> <200705072216.SAA06179@Sparkle.Rodents.Montreal.QC.CA> X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > I am curious. Even though this is irrelevant for the discussion, can > be more specific on what is broken with getaddrinfo? The major annoyance it has for me is the requirement that, to quote the manpage for the version I use, "[i]n this hints structure all members other than ai_flags, ai_family, ai_socktype, and ai_protocol must be zero or a NULL pointer". This requires the app to either have a static struct addrinfo around or to know the complete list of members of the struct - and it's completely unnecessary as far as I can see. (It makes sense to have some kind of extensibility hook, but that could be done with a bit in ai_flags, or at least listing the fields that have to be zeroed rather than requiring it of all except a list.) Not a big problem, true. But annoying. (Apparently the getaddrinfo() I've got used to doesn't suffer from most of the brokennesses outlined in this thread. If I had to deal with them I'd have a lot more to say here, I'm sure.) /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From discuss-bounces@apps.ietf.org Mon May 14 12:28:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HndPV-0007cb-6e; Mon, 14 May 2007 12:28:33 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HndPT-0007cP-OY for discuss-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 12:28:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HndPT-0007cH-Ej for discuss@apps.ietf.org; Mon, 14 May 2007 12:28:31 -0400 Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HndPR-00052J-1N for discuss@apps.ietf.org; Mon, 14 May 2007 12:28:31 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:52340) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1HndPL-0002ne-1a (Exim 4.63) (return-path ); Mon, 14 May 2007 17:28:23 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1HndPL-0006SN-Et (Exim 4.54) (return-path ); Mon, 14 May 2007 17:28:23 +0100 Date: Mon, 14 May 2007 17:28:23 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: der Mouse Subject: Re: sockets APIs extensions for Host Identity Protocol In-Reply-To: <200705141552.LAA02624@Sparkle.Rodents.Montreal.QC.CA> Message-ID: References: <31BC7A8C1A51004A84E08DEF@[10.1.110.5]> <200705072216.SAA06179@Sparkle.Rodents.Montreal.QC.CA> <200705141552.LAA02624@Sparkle.Rodents.Montreal.QC.CA> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Mon, 14 May 2007, der Mouse wrote: > > The major annoyance it has for me is the requirement that, to quote the > manpage for the version I use, "[i]n this hints structure all members > other than ai_flags, ai_family, ai_socktype, and ai_protocol must be > zero or a NULL pointer". This requires the app to either have a static > struct addrinfo around or to know the complete list of members of the > struct - and it's completely unnecessary as far as I can see. You should be able to just memset() it to 0. (I believe POSIX gives you more guarantees than C in this respect.) Tony. -- f.a.n.finch http://dotat.at/ FORTIES: NORTHWESTERLY 5 TO 7, BECOMING CYCLONIC FOR A TIME, DECREASING 4 LATER. MODERATE OCCASIONALLY ROUGH AT FIRST. SHOWERS. MODERATE OR GOOD. From discuss-bounces@apps.ietf.org Mon May 14 15:10:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnfw9-0002CL-GX; Mon, 14 May 2007 15:10:25 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hnfw7-00026F-Vg for discuss-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 15:10:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnfw7-000263-Kl for discuss@apps.ietf.org; Mon, 14 May 2007 15:10:23 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnfw5-0002i3-9q for discuss@apps.ietf.org; Mon, 14 May 2007 15:10:23 -0400 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E8387142200; Mon, 14 May 2007 12:10:20 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFDNKQonIiXg; Mon, 14 May 2007 12:10:18 -0700 (PDT) Received: from [192.168.1.101] (unknown [74.95.2.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 310A9142201; Mon, 14 May 2007 12:10:17 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Use of LWSP in ABNF -- consensus call Date: Mon, 14 May 2007 12:10:03 -0700 To: Apps Discuss , IETF General Discussion Mailing List , ietf-dkim@mipassoc.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Dave Crocker , Paul Overell X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org The IESG reviewed for publication as Internet Standard and would like to know if there is consensus to recommend against the use of LWSP in future specifications, as it has caused problems recently in DKIM and could cause problems in other places. Some discussion on this point already: - http://www1.ietf.org/mail-archive/web/ietf/current/msg46048.html - http://www1.ietf.org/mail-archive/web/discuss/current/msg00463.html - http://mipassoc.org/pipermail/ietf-dkim/2007q1/007295.html - https://datatracker.ietf.org/public/pidtracker.cgi? command=view_comment&id=66440 (in this tracker comment, Chris Newman recommended to remove LWSP, but for backward-compatibility it's probably better to keep it and recommend against use) Thanks for your input, Lisa Dusseault From discuss-bounces@apps.ietf.org Mon May 14 16:56:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnhaQ-0002CH-AG; Mon, 14 May 2007 16:56:06 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HnhaO-0002C5-R1 for discuss-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 16:56:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnhaO-0002Bt-Gu for discuss@apps.ietf.org; Mon, 14 May 2007 16:56:04 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HnhaJ-0001jA-U9 for discuss@apps.ietf.org; Mon, 14 May 2007 16:56:04 -0400 Received: (qmail invoked by alias); 14 May 2007 20:55:58 -0000 Received: from p508fbd44.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.189.68] by mail.gmx.net (mp044) with SMTP; 14 May 2007 22:55:58 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19Wx/1R1QhW1/on4g8pKmMVJzIb0NAhuH6x67SeKu JLdRpojiDIhI68 Message-ID: <4648CCDA.5010907@gmx.de> Date: Mon, 14 May 2007 22:55:54 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: Use of LWSP in ABNF -- consensus call References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Apps Discuss , Paul Overell , Dave Crocker , IETF General Discussion Mailing List , ietf-dkim@mipassoc.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Lisa Dusseault wrote: > > The IESG reviewed > > for publication as Internet Standard and would like to know if there is > consensus to recommend against the use of LWSP in future specifications, > as it has caused problems recently in DKIM and could cause problems in > other places. > > Some discussion on this point already: > - http://www1.ietf.org/mail-archive/web/ietf/current/msg46048.html > - http://www1.ietf.org/mail-archive/web/discuss/current/msg00463.html > - http://mipassoc.org/pipermail/ietf-dkim/2007q1/007295.html > - > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=66440 > (in this tracker comment, Chris Newman recommended to remove LWSP, but > for backward-compatibility it's probably better to keep it and recommend > against use) I agree that LWSP can be problematic. As the LWSP rule only appears in appendix B, the best approach IMHO would be to either leave it in, and have a warning explaining the potential problems close to it, or remove it. The latter sounds simpler, but could cause spec writers that use ABNF to just copy the LWSP rule from RFC4234, ignoring the potential issues with it. The proposed solution to warn about it in the front matter doesn't seem to be a good idea due to locality reasons. If there are reasons to avoud LWSP, they should be stated close to the definition. If this means we need a new revision of the spec, and last-call it again, so be it. No reason to hurry. Best regards, Julian From discuss-bounces@apps.ietf.org Mon May 14 17:46:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HniNX-00084D-Dv; Mon, 14 May 2007 17:46:51 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HniNW-0007vW-5T for discuss-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 17:46:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HniNV-0007rZ-NK for discuss@apps.ietf.org; Mon, 14 May 2007 17:46:49 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HniNU-0006q0-E5 for discuss@apps.ietf.org; Mon, 14 May 2007 17:46:49 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HniNT-0004Zd-85 for discuss@apps.ietf.org; Mon, 14 May 2007 23:46:47 +0200 Received: from 1cust176.tnt9.hbg2.deu.da.uu.net ([149.225.140.176]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 14 May 2007 23:46:47 +0200 Received: from nobody by 1cust176.tnt9.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 14 May 2007 23:46:47 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: discuss@apps.ietf.org From: Frank Ellermann Subject: Re: Use of LWSP in ABNF -- consensus call Date: Mon, 14 May 2007 23:43:02 +0200 Organization: Lines: 16 Message-ID: <4648D7E6.1C7D@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust176.tnt9.hbg2.deu.da.uu.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Lisa Dusseault wrote: [LWSP] > could cause problems in other places. Chris saw it in the 4646bis-05 draft four days ago, Addison fixed it in the 4646bis-06 draft published Friday. It also showed up in an 2821bis draft in one valid ABNF rule, assuming that an apparently empty line contains trailing white space, or an invalid ABNF rule, assuming that the same line is really empty. Frank From discuss-bounces@apps.ietf.org Mon May 14 20:36:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnl1A-000241-K8; Mon, 14 May 2007 20:35:56 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hnl18-00023q-Ab for discuss-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 20:35:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnl18-00023d-0N for discuss@apps.ietf.org; Mon, 14 May 2007 20:35:54 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnl17-00024J-J6 for discuss@apps.ietf.org; Mon, 14 May 2007 20:35:53 -0400 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 27C37142201; Mon, 14 May 2007 17:35:53 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3m2fsvMDxgT; Mon, 14 May 2007 17:35:51 -0700 (PDT) Received: from [192.168.1.101] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 20CE81421FF; Mon, 14 May 2007 17:35:49 -0700 (PDT) In-Reply-To: <4648E8CB.3010502@dcrocker.net> References: <4648E8CB.3010502@dcrocker.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: Use of LWSP in ABNF -- consensus call Date: Mon, 14 May 2007 17:35:46 -0700 To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Apps Discuss , Paul Overell , IETF General Discussion Mailing List , ietf-dkim@mipassoc.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On May 14, 2007, at 3:55 PM, Dave Crocker wrote: > > Lisa Dusseault wrote: >> The IESG reviewed > crocker-rfc4234bis-00.txt> for publication as Internet Standard >> and would like to know if there is consensus to recommend against >> the use of LWSP in future specifications, > > 1 This issue was initially raised in the IESG by Chris Newman, > who changed > his Discuss, with a statement that he recommended inserting a > comment, along > the lines that others are also recommending. Unless I've misread > the record, > all other votes on advancing ABNF from Draft to Full are positive > or neutral,. > except for your own Discuss. Is this correct? The issue was initially raised by Frank Ellerman or by various in the DKIM WG depending on how you look at it -- Frank explicitly suggested possible changes to the draft, in his posting to the IETF list. You're right about the voting situation but here's the background: I took on the DISCUSS myself as a placeholder for an issue that the IESG had consensus to investigate further (consensus to investigate what the consensus is). I could have asked somebody else to hold the DISCUSS but this seemed most convenient as long as the rest of the IESG trusted me to investigate. > > 2. The ABNF is a candidate for moving from Draft to Full. Will > removing a > rule (that is already in use?) or otherwise changing the semantics > of the > specification, at this point, still permit the document to > advance? I had the > impression that moving to Full was based on some serious beliefs > about a > specification's being quite stable. Making this kind of change, > this late in > the game, would seem to run counter to that. Moving to Internet Standard is indeed something we do carefully, and of course that means investigating proposed changes to make sure they're appropriate, and setting a high bar for accepting them. I believe that's what we're doing here, investigating carefully. I share your concerns about removing rules that are already in use -- that would generally be a bad thing. However I'm interested in the consensus around whether a warning or a deprecation statement would be a good thing. Thanks, Lisa From discuss-bounces@apps.ietf.org Mon May 14 22:21:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnmfG-0004ov-FZ; Mon, 14 May 2007 22:21:26 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HnmfF-0004op-IR for discuss-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 22:21:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnmfF-0004oh-8U for discuss@apps.ietf.org; Mon, 14 May 2007 22:21:25 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnmfD-0006VN-SQ for discuss@apps.ietf.org; Mon, 14 May 2007 22:21:25 -0400 Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l4F2LLRN031439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 May 2007 19:21:22 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4648E8CB.3010502@dcrocker.net> Date: Mon, 14 May 2007 19:21:17 -0700 To: Apps Discuss , IETF General Discussion Mailing List , ietf-dkim@mipassoc.org From: Paul Hoffman Subject: Re: Use of LWSP in ABNF -- consensus call Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org At 5:35 PM -0700 5/14/07, Lisa Dusseault wrote: >I share your concerns about removing rules that are already in use >-- that would generally be a bad thing. However I'm interested in >the consensus around whether a warning or a deprecation statement >would be a good thing. A warning would be very useful, and a deprecation or removal would be very bad because either would cause people to go to the earlier documents to see what LWSP meant earlier. From discuss-bounces@apps.ietf.org Mon May 14 23:21:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnnbg-0006TP-0L; Mon, 14 May 2007 23:21:48 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hnnbf-0006TK-2z for discuss-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 23:21:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnnbe-0006TC-PG for discuss@apps.ietf.org; Mon, 14 May 2007 23:21:46 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hnnbb-0003sS-VB for discuss@apps.ietf.org; Mon, 14 May 2007 23:21:46 -0400 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-13.tower-120.messagelabs.com!1179199302!7181970!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 15272 invoked from network); 15 May 2007 03:21:42 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-13.tower-120.messagelabs.com with SMTP; 15 May 2007 03:21:42 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.13.8/8.13.8) with ESMTP id l4F3LflP024545 for ; Mon, 14 May 2007 23:21:42 -0400 Received: from attrh0i.attrh.att.com (attrh0i.attrh.att.com [135.37.94.54]) by mlpi135.enaf.sfdc.sbc.com (8.13.8/8.13.8) with ESMTP id l4F3LNU8024450 for ; Mon, 14 May 2007 23:21:37 -0400 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh0i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l4F3LN1h027893 for ; Mon, 14 May 2007 23:21:23 -0400 (EDT) Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by attrh0i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l4F3L21n027752 for ; Mon, 14 May 2007 23:21:16 -0400 (EDT) Received: from [135.210.40.182] (unknown[135.210.40.182](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20070515032058gw10010gp6e> (Authid: tony); Tue, 15 May 2007 03:20:59 +0000 Message-ID: <464926FC.30109@att.com> Date: Mon, 14 May 2007 23:20:28 -0400 From: Tony Hansen User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Apps Discuss , IETF General Discussion Mailing List , ietf-dkim@mipassoc.org Subject: Re: Use of LWSP in ABNF -- consensus call References: <4648E8CB.3010502@dcrocker.net> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Lisa Dusseault wrote: > I share your concerns about removing rules that are already in use -- > that would generally be a bad thing. However I'm interested in the > consensus around whether a warning or a deprecation statement would be a > good thing. LWSP has a valid meaning and use, and its being misapplied somewhere doesn't make that meaning and usage invalid. I could see a note being added. However, anything more than that is totally inappropriate. Tony Hansen tony@att.com From discuss-bounces@apps.ietf.org Tue May 15 04:10:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hns7Q-00050V-6g; Tue, 15 May 2007 04:10:52 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hns7P-00050G-9w for discuss-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 04:10:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hns7O-000507-UP for discuss@apps.ietf.org; Tue, 15 May 2007 04:10:50 -0400 Received: from ppsw-7.csi.cam.ac.uk ([131.111.8.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hns7K-0007BL-JX for discuss@apps.ietf.org; Tue, 15 May 2007 04:10:50 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:49029) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1Hns7F-0004WX-NX (Exim 4.63) (return-path ); Tue, 15 May 2007 09:10:41 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Hns7F-0007T8-8D (Exim 4.54) (return-path ); Tue, 15 May 2007 09:10:41 +0100 Date: Tue, 15 May 2007 09:10:41 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: dcrocker@bbiw.net Subject: Re: Use of LWSP in ABNF -- consensus call In-Reply-To: <4648E8CB.3010502@dcrocker.net> Message-ID: References: <4648E8CB.3010502@dcrocker.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ietf-dkim@mipassoc.org, Apps Discuss , IETF General Discussion Mailing List , Paul Overell X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Mon, 14 May 2007, Dave Crocker wrote: > > "Could cause problems in other places"... The DKIM hiccup was the first > one I'd heard about. > > By contrast, "linear-white-space" was defined in RFC733, in 1977, with > RFC822 retaining that definition. It is defined in those places as > essentially the same as LWSP in the current ABNF Draft Standard specification. The LWSP defined in ABNF is more like the one in HTTP than the message format one, in that 4234 allows space-only lines (it allows multiple CRLFs in LWSP) whereas 2822 does not (at most one CRLF in FWS). There is some documentation of the interoperability problems arising from the implied-LWS rule in HTTP here: http://www.and.org/texts/server-http#implicit-lws Tony. -- f.a.n.finch http://dotat.at/ GERMAN BIGHT HUMBER THAMES: NORTHWEST BACKING SOUTHWEST 4 OR 5, OCCASIONALLY 6 OR 7 AT FIRST. MODERATE, OCCASIONALLY ROUGH IN GERMAN BIGHT. RAIN OR SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. From discuss-bounces@apps.ietf.org Tue May 15 04:11:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hns8T-0005Sq-0X; Tue, 15 May 2007 04:11:57 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hns8S-0005Qw-0v for discuss-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 04:11:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hns8R-0005Qo-NC for discuss@apps.ietf.org; Tue, 15 May 2007 04:11:55 -0400 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hns8P-0007xg-9w for discuss@apps.ietf.org; Tue, 15 May 2007 04:11:55 -0400 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTPœ id l4F8BpfU000135Tue, 15 May 2007 08:11:52 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1Hns7R-0009Iy-00; Tue, 15 May 2007 09:10:53 +0100 Date: Tue, 15 May 2007 09:10:53 +0100 From: "Clive D.W. Feather" To: Tony Hansen Subject: Re: Use of LWSP in ABNF -- consensus call Message-ID: <20070515081053.GG33188@finch-staff-1.thus.net> References: <4648E8CB.3010502@dcrocker.net> <464926FC.30109@att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <464926FC.30109@att.com> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Apps Discuss , IETF General Discussion Mailing List , ietf-dkim@mipassoc.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Tony Hansen said: >> I share your concerns about removing rules that are already in use -- >> that would generally be a bad thing. However I'm interested in the >> consensus around whether a warning or a deprecation statement would be a >> good thing. > > LWSP has a valid meaning and use, and its being misapplied somewhere > doesn't make that meaning and usage invalid. I could see a note being > added. However, anything more than that is totally inappropriate. +1 Frank's text in would be fine: Authors intending to use the LWSP (linear white space) construct should note that it allows apparently empty lines consisting only of trailing white space, semantically different from really empty lines. Some text editors and other tools are known to remove any trailing white space silently, and therefore the use of LWSP in syntax is not recommended. However, it doesn't belong in "security considerations". What about moving LSWP, and this text, to a separate section of Annex B: "B.3 Deprecated constructs"? -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | From discuss-bounces@apps.ietf.org Tue May 15 11:54:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnzLp-0007aU-Qq; Tue, 15 May 2007 11:54:13 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HnzLo-0007aP-D2 for discuss-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 11:54:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnzLo-0007aH-3R for discuss@apps.ietf.org; Tue, 15 May 2007 11:54:12 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnzLm-0006p3-TD for discuss@apps.ietf.org; Tue, 15 May 2007 11:54:12 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 206FB1EE1B4; Tue, 15 May 2007 11:54:08 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJJWEXvrMNBM; Tue, 15 May 2007 11:53:52 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 498DD1EE1F7; Tue, 15 May 2007 11:53:48 -0400 (EDT) Message-ID: <4649D787.30601@cs.utk.edu> Date: Tue, 15 May 2007 11:53:43 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: Use of LWSP in ABNF -- consensus call References: In-Reply-To: X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Apps Discuss , Dave Crocker , Paul Overell X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org I think it's appropriate to include a note to - explain the problem caused by LWSP - suggest that it's included for backward compatibility and it's probably not something that should be used in new specifications I'd stop short of removing LWSP (for backward compatibility reasons) or forbidding its use in new specifications. ABNF is just a notation for describing a syntax, and the spec shouldn't try to artificially constrain what kind of syntax can be defined. From discuss-bounces@apps.ietf.org Tue May 15 14:21:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho1eB-0007jF-0i; Tue, 15 May 2007 14:21:19 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ho1e8-0007j4-V0 for discuss-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 14:21:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho1e8-0007iq-L5 for discuss@apps.ietf.org; Tue, 15 May 2007 14:21:16 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ho1e7-0003wF-B1 for discuss@apps.ietf.org; Tue, 15 May 2007 14:21:16 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6914A25970D; Tue, 15 May 2007 20:21:14 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00447-02; Tue, 15 May 2007 20:21:09 +0200 (CEST) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4041F25817F; Tue, 15 May 2007 20:21:09 +0200 (CEST) Message-ID: <4649FA12.30909@alvestrand.no> Date: Tue, 15 May 2007 20:21:06 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.7 (X11/20060921) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: Use of LWSP in ABNF -- consensus call References: <4648E8CB.3010502@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ietf-dkim@mipassoc.org, Apps Discuss , IETF General Discussion Mailing List , dcrocker@bbiw.net, Paul Overell X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Lisa Dusseault wrote: > >> >> 2. The ABNF is a candidate for moving from Draft to Full. Will >> removing a >> rule (that is already in use?) or otherwise changing the semantics of >> the >> specification, at this point, still permit the document to advance? I >> had the >> impression that moving to Full was based on some serious beliefs about a >> specification's being quite stable. Making this kind of change, this >> late in >> the game, would seem to run counter to that. > > Moving to Internet Standard is indeed something we do carefully, and > of course that means investigating proposed changes to make sure > they're appropriate, and setting a high bar for accepting them. I > believe that's what we're doing here, investigating carefully. > > I share your concerns about removing rules that are already in use -- > that would generally be a bad thing. However I'm interested in the > consensus around whether a warning or a deprecation statement would be > a good thing. Removing features that have proved to be a Bad Idea has always been listed as one of the possible changes from Proposed to Draft - Draft to Full happens so rarely that I would be hesitant to claim that there's tradition for such changes there. Despite this, I agree with the people who think that a warning comment, rather than removal of the rule, is the Right Way. Harald From discuss-bounces@apps.ietf.org Tue May 15 14:48:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho241-0007Am-79; Tue, 15 May 2007 14:48:01 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ho23x-00076y-37 for discuss-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 14:47:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho23w-00075J-8q for discuss@apps.ietf.org; Tue, 15 May 2007 14:47:56 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ho23u-0004pK-SD for discuss@apps.ietf.org; Tue, 15 May 2007 14:47:56 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ho23f-0006cX-Tg for discuss@apps.ietf.org; Tue, 15 May 2007 20:47:39 +0200 Received: from 1cust82.tnt6.hbg2.deu.da.uu.net ([149.225.18.82]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 May 2007 20:47:39 +0200 Received: from nobody by 1cust82.tnt6.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 May 2007 20:47:39 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: discuss@apps.ietf.org From: Frank Ellermann Subject: Re: Use of LWSP in ABNF -- consensus call Date: Tue, 15 May 2007 20:46:09 +0200 Organization: Lines: 25 Message-ID: <4649FFF1.196@xyzzy.claranet.de> References: <4648E8CB.3010502@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust82.tnt6.hbg2.deu.da.uu.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ietf@ietf.org, ietf-dkim@mipassoc.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Lisa Dusseault wrote: > The issue was initially raised by Frank Hi, a short explanation, initially I hoped that 4234 can be promoted to STD "as is". I missed the (now listed) errata in the "pending errata mbox". Some months later 4234bis-00 was posted, and if 4234 can't be promoted as is, then that's an opportunity to address this (known) LWSP issue. Just removing it is an idea, but for the reasons stated by Dave I felt that "just deprecating it" is good enough with less undesirable side-effects. After all it's simple to implement LWSP as specified. But unfortunately it's also simple to destroy critical white space in an apparently empty line. Sorry for the confusion, I should have checked the pending errata mbox before the proposal to promote RFC 4234 to STD. Frank From discuss-bounces@apps.ietf.org Tue May 15 15:03:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho2Ix-0007sJ-7s; Tue, 15 May 2007 15:03:27 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ho2Iv-0007s8-Gg for discuss-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 15:03:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho2Iv-0007s0-6y for discuss@apps.ietf.org; Tue, 15 May 2007 15:03:25 -0400 Received: from dsl-66-59-230-40.static.linkline.com ([66.59.230.40] helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ho2It-0001tc-Tk for discuss@apps.ietf.org; Tue, 15 May 2007 15:03:25 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MGM4D89GTC0060HU@mauve.mrochek.com> for discuss@apps.ietf.org; Tue, 15 May 2007 12:03:19 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MGL6WMKMPC000053@mauve.mrochek.com>; Tue, 15 May 2007 12:03:17 -0700 (PDT) Message-id: <01MGM4D77428000053@mauve.mrochek.com> Date: Tue, 15 May 2007 12:03:04 -0700 (PDT) From: Ned Freed Subject: Re: Use of LWSP in ABNF -- consensus call In-reply-to: "Your message dated Mon, 14 May 2007 23:20:28 -0400" <464926FC.30109@att.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=ISO-8859-1 References: <4648E8CB.3010502@dcrocker.net> <464926FC.30109@att.com> To: Tony Hansen X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Apps Discuss , IETF General Discussion Mailing List , ietf-dkim@mipassoc.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > Lisa Dusseault wrote: > > I share your concerns about removing rules that are already in use -- > > that would generally be a bad thing. However I'm interested in the > > consensus around whether a warning or a deprecation statement would be a > > good thing. > LWSP has a valid meaning and use, and its being misapplied somewhere > doesn't make that meaning and usage invalid. I could see a note being > added. However, anything more than that is totally inappropriate. Full agreement with Tony here. Ned From discuss-bounces@apps.ietf.org Tue May 15 15:49:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho31h-0007Pa-E1; Tue, 15 May 2007 15:49:41 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ho31g-0007PV-Ss for discuss-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 15:49:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho31g-0007OL-Il for discuss@apps.ietf.org; Tue, 15 May 2007 15:49:40 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ho31e-0001Ik-7q for discuss@apps.ietf.org; Tue, 15 May 2007 15:49:40 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Ho2Yw-0003xx-FL; Tue, 15 May 2007 15:19:58 -0400 Date: Tue, 15 May 2007 15:19:57 -0400 From: John C Klensin To: Ned Freed , Tony Hansen Subject: Re: Use of LWSP in ABNF -- consensus call Message-ID: In-Reply-To: <01MGM4D77428000053@mauve.mrochek.com> References: <4648E8CB.3010502@dcrocker.net> <464926FC.30109@att.com> <01MGM4D77428000053@mauve.mrochek.com> 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-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Apps Discuss , IETF General Discussion Mailing List , ietf-dkim@mipassoc.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --On Tuesday, 15 May, 2007 12:03 -0700 Ned Freed wrote: >> Lisa Dusseault wrote: >> > I share your concerns about removing rules that are already >> > in use -- that would generally be a bad thing. However I'm >> > interested in the consensus around whether a warning or a >> > deprecation statement would be a good thing. > >> LWSP has a valid meaning and use, and its being misapplied >> somewhere doesn't make that meaning and usage invalid. I >> could see a note being added. However, anything more than >> that is totally inappropriate. > > Full agreement with Tony here. +1 ABNF is simply a tool, a grammar, and a set of definitions. I'd almost favor a separate applicability statement that encourages the use of some features and discourages others as appropriate if that is really needed. But a particular element should be removed from the standard only if there is a case to be made that the definition is inadequate or consistent with other parts of the model or grammar. If such inconsistencies actually existed, ABNF should, IMO, be bounced back to Proposed and fixed. Fortunately, that doesn't seem to be the case here, but I would really question what we are doing to ourselves if our grammatical definitions start needing profiles john From discuss-bounces@apps.ietf.org Tue May 15 17:54:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho4yU-0002iZ-Tg; Tue, 15 May 2007 17:54:30 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ho4yT-0002i8-Jd for discuss-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 17:54:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho4yT-0002hc-9M for discuss@apps.ietf.org; Tue, 15 May 2007 17:54:29 -0400 Received: from ppsw-9.csi.cam.ac.uk ([131.111.8.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ho4yP-00032d-0D for discuss@apps.ietf.org; Tue, 15 May 2007 17:54:29 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:42108) by ppsw-9.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1Ho4yI-0008B2-Tq (Exim 4.63) (return-path ); Tue, 15 May 2007 22:54:18 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Ho4yI-0005e7-6q (Exim 4.54) (return-path ); Tue, 15 May 2007 22:54:18 +0100 Date: Tue, 15 May 2007 22:54:18 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Dave Crocker Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call In-Reply-To: <4649FB9A.9000107@bbiw.net> Message-ID: References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> <4649FB9A.9000107@bbiw.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: IETF General Discussion Mailing List , Apps Discuss , Harald Alvestrand , Paul Overell , ietf-dkim@mipassoc.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Tue, 15 May 2007, Dave Crocker wrote: > > So that is a total of at most 2 documented cases in 10-30 years. > And keep in mind that the issue is not that the rule "does not work" but that > it is very rarely mis-used. Did you miss my post linking to a description of LWSP-related interop problems in HTTP? http://www.and.org/texts/server-http#implicit-lws Tony. -- f.a.n.finch http://dotat.at/ FORTH TYNE DOGGER: WEST 4 OR 5, BECOMING VARIABLE 2, THEN SOUTHERLY 3 OR 4. SLIGHT OR MODERATE. SHOWERS THEN MAINLY FAIR. GOOD OCCASIONALLY MODERATE AT FIRST. From discuss-bounces@apps.ietf.org Wed May 16 13:24:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoNEv-0001fL-3P; Wed, 16 May 2007 13:24:41 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HoNEt-0001fD-G4 for discuss-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 13:24:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoNEt-0001eo-63 for discuss@apps.ietf.org; Wed, 16 May 2007 13:24:39 -0400 Received: from sparkle.rodents.montreal.qc.ca ([216.46.5.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoNEr-0003C5-Nl for discuss@apps.ietf.org; Wed, 16 May 2007 13:24:39 -0400 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id NAA03539; Wed, 16 May 2007 13:24:35 -0400 (EDT) From: der Mouse Message-Id: <200705161724.NAA03539@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Wed, 16 May 2007 13:21:23 -0400 (EDT) To: discuss@apps.ietf.org Subject: Re: sockets APIs extensions for Host Identity Protocol In-Reply-To: References: <31BC7A8C1A51004A84E08DEF@[10.1.110.5]> <200705072216.SAA06179@Sparkle.Rodents.Montreal.QC.CA> <200705141552.LAA02624@Sparkle.Rodents.Montreal.QC.CA> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >> The major annoyance [getaddrinfo] has for me is the requirement >> that, to quote the manpage for the version I use, "[i]n this hints >> structure all members other than ai_flags, ai_family, ai_socktype, >> and ai_protocol must be zero or a NULL pointer". > You should be able to just memset() it to 0. (I believe POSIX gives > you more guarantees than C in this respect.) POSIX requires nil pointers to be all-bits-zero? That's..bizarre. Must be rather crippling for anyone trying to work with oddball architectures. I'd also recommend against depending on it when designing interfaces; these interfaces get used in not-quite-POSIX and sometimes even not-even-close-to-POSIX systems, and I think it would be good if they didn't depend on POSIX features unnecessarily - and I see this as a totally unnecessary dependency. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From discuss-bounces@apps.ietf.org Thu May 17 11:58:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoiNE-0001Qx-Br; Thu, 17 May 2007 11:58:40 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HnjRu-0008JS-30 for discuss-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 18:55:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnjRt-0008JK-Oz for discuss@apps.ietf.org; Mon, 14 May 2007 18:55:25 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnjRs-0003A5-CH for discuss@apps.ietf.org; Mon, 14 May 2007 18:55:25 -0400 Received: from [10.2.2.93] (207.47.11.9.static.nextweb.net [207.47.11.9]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l4EMt5Kl005914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 May 2007 15:55:05 -0700 Message-ID: <4648E8CB.3010502@dcrocker.net> Date: Mon, 14 May 2007 15:55:07 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: Use of LWSP in ABNF -- consensus call References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-Mailman-Approved-At: Thu, 17 May 2007 11:58:36 -0400 Cc: Apps Discuss , Paul Overell , IETF General Discussion Mailing List , ietf-dkim@mipassoc.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Lisa Dusseault wrote: > The IESG reviewed > for > publication as Internet Standard and would like to know if there is > consensus to recommend against the use of LWSP in future specifications, Lisa, Process: 1 This issue was initially raised in the IESG by Chris Newman, who changed his Discuss, with a statement that he recommended inserting a comment, along the lines that others are also recommending. Unless I've misread the record, all other votes on advancing ABNF from Draft to Full are positive or neutral,. except for your own Discuss. Is this correct? 2. The ABNF is a candidate for moving from Draft to Full. Will removing a rule (that is already in use?) or otherwise changing the semantics of the specification, at this point, still permit the document to advance? I had the impression that moving to Full was based on some serious beliefs about a specification's being quite stable. Making this kind of change, this late in the game, would seem to run counter to that. > as it has caused problems recently in DKIM and could cause problems in > other places. Semantics: "Could cause problems in other places"... The DKIM hiccup was the first one I'd heard about. By contrast, "linear-white-space" was defined in RFC733, in 1977, with RFC822 retaining that definition. It is defined in those places as essentially the same as LWSP in the current ABNF Draft Standard specification. This seems to be one LWSP problem in 30 years. Is this really a sufficient basis for changing the semantics of something that has been stable and widely used for 10-30 years (depending upon how you count)? Are we reasonably comfortable that making the change will not create new and different problems, such as for other uses of ABNF? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From discuss-bounces@apps.ietf.org Thu May 17 11:58:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoiNE-0001Qs-8P; Thu, 17 May 2007 11:58:40 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HngVq-00055P-8m for discuss-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 15:47:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HngVp-00055H-VG for discuss@apps.ietf.org; Mon, 14 May 2007 15:47:17 -0400 Received: from dsl081-247-036.sfo1.dsl.speakeasy.net ([64.81.247.36] helo=knecht.neophilic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HngVo-0003Tb-Hp for discuss@apps.ietf.org; Mon, 14 May 2007 15:47:17 -0400 Received: from [10.210.202.34] (natted.sendmail.com [63.211.143.38]) by knecht.neophilic.com (8.13.8/8.13.6) with ESMTP id l4EJl2Cu007188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 May 2007 12:47:03 -0700 (PDT) (envelope-from eric+dkim@sendmail.org) DKIM-Signature: v=0.5; a=rsa-sha256; c=relaxed/relaxed; d=sendmail.org; s=default; t=1179172024; bh=lex3dV7mkWrzF5nERo4FdZBF47loFs9iP7gu3Qd j3Xs=; h=Date:From:To:cc:Subject:Message-ID:In-Reply-To:References: X-Mailer:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-Disposition:X-Spam-Status:X-Spam-Checker-Version; b=RSU4qv bJgEl2fD3Avt95kHB0NvGQLCCWqubYciH4RU+agOB7ov55Skh7NyvE7ByWQ7TJ11SZp 63w4KLgSSpo1g== Date: Mon, 14 May 2007 12:46:54 -0700 From: Eric Allman To: Lisa Dusseault , Apps Discuss , IETF General Discussion Mailing List , ietf-dkim@mipassoc.org Subject: Re: Use of LWSP in ABNF -- consensus call Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, score=-2.0 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, DATE_IN_FUTURE_96_XX autolearn=no version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on knecht.neophilic.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea X-Mailman-Approved-At: Thu, 17 May 2007 11:58:36 -0400 Cc: Dave Crocker , Paul Overell X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org I'm inclined to agree that there is a problem, and your proposed solution of keeping LWSP but depreciating it is probably correct. However, I recommended also adding a new, correct definition (for DKIM we used FWS from RFC 2822) and a discussion of the differences. eric From discuss-bounces@apps.ietf.org Thu May 17 11:58:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoiNE-0001R2-FP; Thu, 17 May 2007 11:58:40 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HnmKQ-0002g2-Ax for discuss-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 21:59:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnmKP-0002fk-P2 for discuss@apps.ietf.org; Mon, 14 May 2007 21:59:53 -0400 Received: from tls.sendmail.com ([209.246.26.40] helo=foon.sendmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnmKG-0006g1-K9 for discuss@apps.ietf.org; Mon, 14 May 2007 21:59:52 -0400 Received: from [10.201.0.39] (adsl-64-58-1-252.mho.net [64.58.1.252] (may be forged)) (authenticated bits=0) by foon.sendmail.com (Switch-3.2.5/Switch-3.2.0) with ESMTP id l4F22HRj032281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 May 2007 19:02:19 -0700 X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com l4F22HRj032281 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1179194544; bh=4lZNDHAGX1FHMxFKwuxT36khep8=; h=X-DomainKeys: DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type; b=laBjwWr9Cnn+4I0u DFCxLBwfOPmAySwJYRpJxZfq234tfeLpdGF20XXQAaY7eQ2TIa6RvUfNMzU05upHAOP Spf/H1jiL+9OLMqUba+WPrKe4EG8iAGM2MaTTXjJA9Qe5Q2t3quNbBpin5DSYgR2s6n FeLt4lv87dbhVRfnb9Lyw= X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com l4F22HRj032281 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=ZFI4RJxG/NB9A4rO9B/sEvpKdv8jK11JJllpzdvycTktgM0A7w6NRZR1g5rqJ5EeM cuSKUd39nkerDxdvTam3WD1o/Sq1nI6qHkp86XF65SxINQn5nxVIC74N6V9zIifG+lh 4g+MzbwyRc3mhBeFPrJqXmfak0SVenEfQ7cGl2Y= Date: Mon, 14 May 2007 19:59:29 -0600 From: Philip Guenther X-X-Sender: guenther@vanye.mho.net To: Lisa Dusseault Subject: Re: Use of LWSP in ABNF -- consensus call In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Thu, 17 May 2007 11:58:36 -0400 Cc: Apps Discuss , Paul Overell , IETF General Discussion Mailing List , Dave Crocker X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Mon, 14 May 2007, Lisa Dusseault wrote: > The IESG reviewed > for > publication as Internet Standard and would like to know if there is consensus > to recommend against the use of LWSP in future specifications, as it has > caused problems recently in DKIM and could cause problems in other places. LWSP was one of the factors in the SASL WG's abandoning of the DIGEST-MD5 revision. To be precise, the complexity inherent in the 822-style n#rule syntax (the emulation of which in modern ABNF uses LWSP) was found to be a source of implementation errors and interoperability issues. Part of the discussion can be seen at: http://www.imc.org/ietf-sasl/mail-archive/msg02752.html While I don't think removing LWSP from the ABNF RFC is good idea, adding a comment to its definition in section B.1 that warns protocol designers to consider carefully whether they really need or want "LWSP" instead of "*WSP" does seem appropriate. Calling out that LWSP permits lines containing just whitespace may help drive home the issue. Philip Guenther Sendmail, Inc From discuss-bounces@apps.ietf.org Thu May 17 11:58:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoiNE-0001S3-NY; Thu, 17 May 2007 11:58:40 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ho1kY-0003Lq-QD for discuss-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 14:27:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho1kY-0003Li-Ga for discuss@apps.ietf.org; Tue, 15 May 2007 14:27:54 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ho1kX-0006AO-4m for discuss@apps.ietf.org; Tue, 15 May 2007 14:27:54 -0400 Received: from [10.2.2.93] (207.47.11.9.static.nextweb.net [207.47.11.9]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l4FIRbZc005368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 May 2007 11:27:38 -0700 Message-ID: <4649FB9A.9000107@bbiw.net> Date: Tue, 15 May 2007 11:27:38 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Harald Alvestrand Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> In-Reply-To: <4649FA12.30909@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dcrocker@bbiw.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-Mailman-Approved-At: Thu, 17 May 2007 11:58:36 -0400 Cc: Apps Discuss , Paul Overell , ietf-dkim@mipassoc.org, IETF General Discussion Mailing List X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Harald Alvestrand wrote: > Removing features that have proved to be a Bad Idea has always been > listed as one of the possible changes from Proposed to Draft - Draft to > Full happens so rarely that I would be hesitant to claim that there's > tradition for such changes there. The question is the "proved to be" criterion. The consensus call was triggered by one documented problem in 10 years. We've had a posting claiming one additional problem (although my own recollection of that bit of history was the the list construct was the issue, rather than LWSP.) So that is a total of at most 2 documented cases in 10-30 years. And keep in mind that the issue is not that the rule "does not work" but that it is very rarely mis-used. Were we to deprecate every feature in IETF specifications that get mis-implemented a couple of times over 10 years, I suspect much of our technology would be deprecated... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From discuss-bounces@apps.ietf.org Thu May 17 11:58:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoiNE-0001Qx-Br; Thu, 17 May 2007 11:58:40 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HnjRu-0008JS-30 for discuss-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 18:55:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnjRt-0008JK-Oz for discuss@apps.ietf.org; Mon, 14 May 2007 18:55:25 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnjRs-0003A5-CH for discuss@apps.ietf.org; Mon, 14 May 2007 18:55:25 -0400 Received: from [10.2.2.93] (207.47.11.9.static.nextweb.net [207.47.11.9]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l4EMt5Kl005914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 May 2007 15:55:05 -0700 Message-ID: <4648E8CB.3010502@dcrocker.net> Date: Mon, 14 May 2007 15:55:07 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: Use of LWSP in ABNF -- consensus call References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-Mailman-Approved-At: Thu, 17 May 2007 11:58:36 -0400 Cc: Apps Discuss , Paul Overell , IETF General Discussion Mailing List , ietf-dkim@mipassoc.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Lisa Dusseault wrote: > The IESG reviewed > for > publication as Internet Standard and would like to know if there is > consensus to recommend against the use of LWSP in future specifications, Lisa, Process: 1 This issue was initially raised in the IESG by Chris Newman, who changed his Discuss, with a statement that he recommended inserting a comment, along the lines that others are also recommending. Unless I've misread the record, all other votes on advancing ABNF from Draft to Full are positive or neutral,. except for your own Discuss. Is this correct? 2. The ABNF is a candidate for moving from Draft to Full. Will removing a rule (that is already in use?) or otherwise changing the semantics of the specification, at this point, still permit the document to advance? I had the impression that moving to Full was based on some serious beliefs about a specification's being quite stable. Making this kind of change, this late in the game, would seem to run counter to that. > as it has caused problems recently in DKIM and could cause problems in > other places. Semantics: "Could cause problems in other places"... The DKIM hiccup was the first one I'd heard about. By contrast, "linear-white-space" was defined in RFC733, in 1977, with RFC822 retaining that definition. It is defined in those places as essentially the same as LWSP in the current ABNF Draft Standard specification. This seems to be one LWSP problem in 30 years. Is this really a sufficient basis for changing the semantics of something that has been stable and widely used for 10-30 years (depending upon how you count)? Are we reasonably comfortable that making the change will not create new and different problems, such as for other uses of ABNF? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From discuss-bounces@apps.ietf.org Thu May 17 11:58:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoiNE-0001Qs-8P; Thu, 17 May 2007 11:58:40 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HngVq-00055P-8m for discuss-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 15:47:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HngVp-00055H-VG for discuss@apps.ietf.org; Mon, 14 May 2007 15:47:17 -0400 Received: from dsl081-247-036.sfo1.dsl.speakeasy.net ([64.81.247.36] helo=knecht.neophilic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HngVo-0003Tb-Hp for discuss@apps.ietf.org; Mon, 14 May 2007 15:47:17 -0400 Received: from [10.210.202.34] (natted.sendmail.com [63.211.143.38]) by knecht.neophilic.com (8.13.8/8.13.6) with ESMTP id l4EJl2Cu007188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 May 2007 12:47:03 -0700 (PDT) (envelope-from eric+dkim@sendmail.org) DKIM-Signature: v=0.5; a=rsa-sha256; c=relaxed/relaxed; d=sendmail.org; s=default; t=1179172024; bh=lex3dV7mkWrzF5nERo4FdZBF47loFs9iP7gu3Qd j3Xs=; h=Date:From:To:cc:Subject:Message-ID:In-Reply-To:References: X-Mailer:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-Disposition:X-Spam-Status:X-Spam-Checker-Version; b=RSU4qv bJgEl2fD3Avt95kHB0NvGQLCCWqubYciH4RU+agOB7ov55Skh7NyvE7ByWQ7TJ11SZp 63w4KLgSSpo1g== Date: Mon, 14 May 2007 12:46:54 -0700 From: Eric Allman To: Lisa Dusseault , Apps Discuss , IETF General Discussion Mailing List , ietf-dkim@mipassoc.org Subject: Re: Use of LWSP in ABNF -- consensus call Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, score=-2.0 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, DATE_IN_FUTURE_96_XX autolearn=no version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on knecht.neophilic.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea X-Mailman-Approved-At: Thu, 17 May 2007 11:58:36 -0400 Cc: Dave Crocker , Paul Overell X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org I'm inclined to agree that there is a problem, and your proposed solution of keeping LWSP but depreciating it is probably correct. However, I recommended also adding a new, correct definition (for DKIM we used FWS from RFC 2822) and a discussion of the differences. eric From discuss-bounces@apps.ietf.org Thu May 17 11:58:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoiNE-0001Qs-8P; Thu, 17 May 2007 11:58:40 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HngVq-00055P-8m for discuss-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 15:47:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HngVp-00055H-VG for discuss@apps.ietf.org; Mon, 14 May 2007 15:47:17 -0400 Received: from dsl081-247-036.sfo1.dsl.speakeasy.net ([64.81.247.36] helo=knecht.neophilic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HngVo-0003Tb-Hp for discuss@apps.ietf.org; Mon, 14 May 2007 15:47:17 -0400 Received: from [10.210.202.34] (natted.sendmail.com [63.211.143.38]) by knecht.neophilic.com (8.13.8/8.13.6) with ESMTP id l4EJl2Cu007188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 May 2007 12:47:03 -0700 (PDT) (envelope-from eric+dkim@sendmail.org) DKIM-Signature: v=0.5; a=rsa-sha256; c=relaxed/relaxed; d=sendmail.org; s=default; t=1179172024; bh=lex3dV7mkWrzF5nERo4FdZBF47loFs9iP7gu3Qd j3Xs=; h=Date:From:To:cc:Subject:Message-ID:In-Reply-To:References: X-Mailer:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-Disposition:X-Spam-Status:X-Spam-Checker-Version; b=RSU4qv bJgEl2fD3Avt95kHB0NvGQLCCWqubYciH4RU+agOB7ov55Skh7NyvE7ByWQ7TJ11SZp 63w4KLgSSpo1g== Date: Mon, 14 May 2007 12:46:54 -0700 From: Eric Allman To: Lisa Dusseault , Apps Discuss , IETF General Discussion Mailing List , ietf-dkim@mipassoc.org Subject: Re: Use of LWSP in ABNF -- consensus call Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, score=-2.0 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, DATE_IN_FUTURE_96_XX autolearn=no version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on knecht.neophilic.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea X-Mailman-Approved-At: Thu, 17 May 2007 11:58:36 -0400 Cc: Dave Crocker , Paul Overell X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org I'm inclined to agree that there is a problem, and your proposed solution of keeping LWSP but depreciating it is probably correct. However, I recommended also adding a new, correct definition (for DKIM we used FWS from RFC 2822) and a discussion of the differences. eric From discuss-bounces@apps.ietf.org Thu May 17 11:58:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoiNE-0001S3-NY; Thu, 17 May 2007 11:58:40 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ho1kY-0003Lq-QD for discuss-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 14:27:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho1kY-0003Li-Ga for discuss@apps.ietf.org; Tue, 15 May 2007 14:27:54 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ho1kX-0006AO-4m for discuss@apps.ietf.org; Tue, 15 May 2007 14:27:54 -0400 Received: from [10.2.2.93] (207.47.11.9.static.nextweb.net [207.47.11.9]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l4FIRbZc005368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 May 2007 11:27:38 -0700 Message-ID: <4649FB9A.9000107@bbiw.net> Date: Tue, 15 May 2007 11:27:38 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Harald Alvestrand Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> In-Reply-To: <4649FA12.30909@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dcrocker@bbiw.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-Mailman-Approved-At: Thu, 17 May 2007 11:58:36 -0400 Cc: Apps Discuss , Paul Overell , ietf-dkim@mipassoc.org, IETF General Discussion Mailing List X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Harald Alvestrand wrote: > Removing features that have proved to be a Bad Idea has always been > listed as one of the possible changes from Proposed to Draft - Draft to > Full happens so rarely that I would be hesitant to claim that there's > tradition for such changes there. The question is the "proved to be" criterion. The consensus call was triggered by one documented problem in 10 years. We've had a posting claiming one additional problem (although my own recollection of that bit of history was the the list construct was the issue, rather than LWSP.) So that is a total of at most 2 documented cases in 10-30 years. And keep in mind that the issue is not that the rule "does not work" but that it is very rarely mis-used. Were we to deprecate every feature in IETF specifications that get mis-implemented a couple of times over 10 years, I suspect much of our technology would be deprecated... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net specification. This seems to be one LWSP problem in 30 years. Is this really a sufficient basis for changing the semantics of something that has been stable and widely used for 10-30 years (depending upon how you count)? Are we reasonably comfortable that making the change will not create new and different problems, such as for other uses of ABNF? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From discuss-bounces@apps.ietf.org Thu May 17 11:58:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoiNE-0001Qs-8P; Thu, 17 May 2007 11:58:40 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HngVq-00055P-8m for discuss-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 15:47:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HngVp-00055H-VG for discuss@apps.ietf.org; Mon, 14 May 2007 15:47:17 -0400 Received: from dsl081-247-036.sfo1.dsl.speakeasy.net ([64.81.247.36] helo=knecht.neophilic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HngVo-0003Tb-Hp for discuss@apps.ietf.org; Mon, 14 May 2007 15:47:17 -0400 Received: from [10.210.202.34] (natted.sendmail.com [63.211.143.38]) by knecht.neophilic.com (8.13.8/8.13.6) with ESMTP id l4EJl2Cu007188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 May 2007 12:47:03 -0700 (PDT) (envelope-from eric+dkim@sendmail.org) DKIM-Signature: v=0.5; a=rsa-sha256; c=relaxed/relaxed; d=sendmail.org; s=default; t=1179172024; bh=lex3dV7mkWrzF5nERo4FdZBF47loFs9iP7gu3Qd j3Xs=; h=Date:From:To:cc:Subject:Message-ID:In-Reply-To:References: X-Mailer:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-Disposition:X-Spam-Status:X-Spam-Checker-Version; b=RSU4qv bJgEl2fD3Avt95kHB0NvGQLCCWqubYciH4RU+agOB7ov55Skh7NyvE7ByWQ7TJ11SZp 63w4KLgSSpo1g== Date: Mon, 14 May 2007 12:46:54 -0700 From: Eric Allman To: Lisa Dusseault , Apps Discuss , IETF General Discussion Mailing List , ietf-dkim@mipassoc.org Subject: Re: Use of LWSP in ABNF -- consensus call Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, score=-2.0 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, DATE_IN_FUTURE_96_XX autolearn=no version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on knecht.neophilic.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea X-Mailman-Approved-At: Thu, 17 May 2007 11:58:36 -0400 Cc: Dave Crocker , Paul Overell X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org I'm inclined to agree that there is a problem, and your proposed solution of keeping LWSP but depreciating it is probably correct. However, I recommended also adding a new, correct definition (for DKIM we used FWS from RFC 2822) and a discussion of the differences. eric From discuss-bounces@apps.ietf.org Thu May 17 11:58:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoiNE-0001R2-FP; Thu, 17 May 2007 11:58:40 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HnmKQ-0002g2-Ax for discuss-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 21:59:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnmKP-0002fk-P2 for discuss@apps.ietf.org; Mon, 14 May 2007 21:59:53 -0400 Received: from tls.sendmail.com ([209.246.26.40] helo=foon.sendmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnmKG-0006g1-K9 for discuss@apps.ietf.org; Mon, 14 May 2007 21:59:52 -0400 Received: from [10.201.0.39] (adsl-64-58-1-252.mho.net [64.58.1.252] (may be forged)) (authenticated bits=0) by foon.sendmail.com (Switch-3.2.5/Switch-3.2.0) with ESMTP id l4F22HRj032281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 May 2007 19:02:19 -0700 X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com l4F22HRj032281 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1179194544; bh=4lZNDHAGX1FHMxFKwuxT36khep8=; h=X-DomainKeys: DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type; b=laBjwWr9Cnn+4I0u DFCxLBwfOPmAySwJYRpJxZfq234tfeLpdGF20XXQAaY7eQ2TIa6RvUfNMzU05upHAOP Spf/H1jiL+9OLMqUba+WPrKe4EG8iAGM2MaTTXjJA9Qe5Q2t3quNbBpin5DSYgR2s6n FeLt4lv87dbhVRfnb9Lyw= X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com l4F22HRj032281 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=ZFI4RJxG/NB9A4rO9B/sEvpKdv8jK11JJllpzdvycTktgM0A7w6NRZR1g5rqJ5EeM cuSKUd39nkerDxdvTam3WD1o/Sq1nI6qHkp86XF65SxINQn5nxVIC74N6V9zIifG+lh 4g+MzbwyRc3mhBeFPrJqXmfak0SVenEfQ7cGl2Y= Date: Mon, 14 May 2007 19:59:29 -0600 From: Philip Guenther X-X-Sender: guenther@vanye.mho.net To: Lisa Dusseault Subject: Re: Use of LWSP in ABNF -- consensus call In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Thu, 17 May 2007 11:58:36 -0400 Cc: Apps Discuss , Paul Overell , IETF General Discussion Mailing List , Dave Crocker X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Mon, 14 May 2007, Lisa Dusseault wrote: > The IESG reviewed > for > publication as Internet Standard and would like to know if there is consensus > to recommend against the use of LWSP in future specifications, as it has > caused problems recently in DKIM and could cause problems in other places. LWSP was one of the factors in the SASL WG's abandoning of the DIGEST-MD5 revision. To be precise, the complexity inherent in the 822-style n#rule syntax (the emulation of which in modern ABNF uses LWSP) was found to be a source of implementation errors and interoperability issues. Part of the discussion can be seen at: http://www.imc.org/ietf-sasl/mail-archive/msg02752.html While I don't think removing LWSP from the ABNF RFC is good idea, adding a comment to its definition in section B.1 that warns protocol designers to consider carefully whether they really need or want "LWSP" instead of "*WSP" does seem appropriate. Calling out that LWSP permits lines containing just whitespace may help drive home the issue. Philip Guenther Sendmail, Inc From discuss-bounces@apps.ietf.org Thu May 17 11:58:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoiNE-0001S3-NY; Thu, 17 May 2007 11:58:40 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ho1kY-0003Lq-QD for discuss-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 14:27:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho1kY-0003Li-Ga for discuss@apps.ietf.org; Tue, 15 May 2007 14:27:54 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ho1kX-0006AO-4m for discuss@apps.ietf.org; Tue, 15 May 2007 14:27:54 -0400 Received: from [10.2.2.93] (207.47.11.9.static.nextweb.net [207.47.11.9]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l4FIRbZc005368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 May 2007 11:27:38 -0700 Message-ID: <4649FB9A.9000107@bbiw.net> Date: Tue, 15 May 2007 11:27:38 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Harald Alvestrand Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> In-Reply-To: <4649FA12.30909@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dcrocker@bbiw.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-Mailman-Approved-At: Thu, 17 May 2007 11:58:36 -0400 Cc: Apps Discuss , Paul Overell , ietf-dkim@mipassoc.org, IETF General Discussion Mailing List X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Harald Alvestrand wrote: > Removing features that have proved to be a Bad Idea has always been > listed as one of the possible changes from Proposed to Draft - Draft to > Full happens so rarely that I would be hesitant to claim that there's > tradition for such changes there. The question is the "proved to be" criterion. The consensus call was triggered by one documented problem in 10 years. We've had a posting claiming one additional problem (although my own recollection of that bit of history was the the list construct was the issue, rather than LWSP.) So that is a total of at most 2 documented cases in 10-30 years. And keep in mind that the issue is not that the rule "does not work" but that it is very rarely mis-used. Were we to deprecate every feature in IETF specifications that get mis-implemented a couple of times over 10 years, I suspect much of our technology would be deprecated... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From discuss-bounces@apps.ietf.org Thu May 17 11:58:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoiNE-0001S3-NY; Thu, 17 May 2007 11:58:40 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ho1kY-0003Lq-QD for discuss-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 14:27:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho1kY-0003Li-Ga for discuss@apps.ietf.org; Tue, 15 May 2007 14:27:54 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ho1kX-0006AO-4m for discuss@apps.ietf.org; Tue, 15 May 2007 14:27:54 -0400 Received: from [10.2.2.93] (207.47.11.9.static.nextweb.net [207.47.11.9]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l4FIRbZc005368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 May 2007 11:27:38 -0700 Message-ID: <4649FB9A.9000107@bbiw.net> Date: Tue, 15 May 2007 11:27:38 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Harald Alvestrand Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> In-Reply-To: <4649FA12.30909@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dcrocker@bbiw.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-Mailman-Approved-At: Thu, 17 May 2007 11:58:36 -0400 Cc: Apps Discuss , Paul Overell , ietf-dkim@mipassoc.org, IETF General Discussion Mailing List X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Harald Alvestrand wrote: > Removing features that have proved to be a Bad Idea has always been > listed as one of the possible changes from Proposed to Draft - Draft to > Full happens so rarely that I would be hesitant to claim that there's > tradition for such changes there. The question is the "proved to be" criterion. The consensus call was triggered by one documented problem in 10 years. We've had a posting claiming one additional problem (although my own recollection of that bit of history was the the list construct was the issue, rather than LWSP.) So that is a total of at most 2 documented cases in 10-30 years. And keep in mind that the issue is not that the rule "does not work" but that it is very rarely mis-used. Were we to deprecate every feature in IETF specifications that get mis-implemented a couple of times over 10 years, I suspect much of our technology would be deprecated... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From discuss-bounces@apps.ietf.org Thu May 17 11:58:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoiNF-0001Sd-3i; Thu, 17 May 2007 11:58:41 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ho5yd-00083t-53 for discuss-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 18:58:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho5u1-00066j-GX for discuss@apps.ietf.org; Tue, 15 May 2007 18:53:57 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ho5tq-0003sF-SJ for discuss@apps.ietf.org; Tue, 15 May 2007 18:53:57 -0400 Received: from [192.168.0.4] (adsl-67-127-191-83.dsl.pltn13.pacbell.net [67.127.191.83]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l4FMrP6R026222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 May 2007 15:53:26 -0700 Message-ID: <464A39B8.4030702@bbiw.net> Date: Tue, 15 May 2007 15:52:40 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Tony Finch Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> <4649FB9A.9000107@bbiw.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dcrocker@bbiw.net X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-Mailman-Approved-At: Thu, 17 May 2007 11:58:36 -0400 Cc: ietf-dkim@mipassoc.org, Apps Discuss , IETF General Discussion Mailing List , Paul Overell X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Tony Finch wrote: > On Tue, 15 May 2007, Dave Crocker wrote: >> So that is a total of at most 2 documented cases in 10-30 years. >> And keep in mind that the issue is not that the rule "does not work" but that >> it is very rarely mis-used. > > Did you miss my post linking to a description of LWSP-related interop > problems in HTTP? http://www.and.org/texts/server-http#implicit-lws No. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From discuss-bounces@apps.ietf.org Thu May 17 11:58:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoiNF-0001Sv-8n; Thu, 17 May 2007 11:58:41 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HoMKH-0004Xg-1V for discuss-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 12:26:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoMKG-0004XQ-Nq for discuss@apps.ietf.org; Wed, 16 May 2007 12:26:08 -0400 Received: from harry.mail-abuse.org ([168.61.5.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoMKF-0000Fx-DI for discuss@apps.ietf.org; Wed, 16 May 2007 12:26:08 -0400 Received: from [168.61.10.150] (SJC-Office-DHCP-150.Mail-Abuse.ORG [168.61.10.150]) by harry.mail-abuse.org (Postfix) with ESMTP id DA6EC4142D; Wed, 16 May 2007 09:26:01 -0700 (PDT) In-Reply-To: <20070515081053.GG33188@finch-staff-1.thus.net> References: <4648E8CB.3010502@dcrocker.net> <464926FC.30109@att.com> <20070515081053.GG33188@finch-staff-1.thus.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <27CD7D06-BEC7-4442-838C-76E4612C7E8B@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: Use of LWSP in ABNF -- consensus call Date: Wed, 16 May 2007 09:25:56 -0700 To: Clive D.W. Feather X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-Mailman-Approved-At: Thu, 17 May 2007 11:58:36 -0400 Cc: Apps Discuss , Tony Hansen , IETF General Discussion Mailing List , ietf-dkim@mipassoc.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On May 15, 2007, at 1:10 AM, Clive D.W. Feather wrote: > Tony Hansen said: >>> I share your concerns about removing rules that are already in >>> use -- >>> that would generally be a bad thing. However I'm interested in the >>> consensus around whether a warning or a deprecation statement >>> would be a >>> good thing. >> >> LWSP has a valid meaning and use, and its being misapplied somewhere >> doesn't make that meaning and usage invalid. I could see a note being >> added. However, anything more than that is totally inappropriate. > > +1 > > Frank's text in > > would be fine: > > Authors intending to use the LWSP (linear white space) construct > should note that it allows apparently empty lines consisting only > of trailing white space, semantically different from really empty > lines. Some text editors and other tools are known to remove any > trailing white space silently, and therefore the use of LWSP in > syntax is not recommended. > > However, it doesn't belong in "security considerations". Discarding of lines is likely in response to some type of exploit. The consideration for not using LWSP would be in regard with how security requirements may create incompatibilities. This is the correct section. > What about moving LSWP, and this text, to a separate section of > Annex B: > "B.3 Deprecated constructs"? Agreed. That would also be appropriate. Another problem regarding LWSP is in regard to _many_ differing definitions. A profusion of differing definitions alone becomes a valid reason to deprecate the mnemonic. This definition represents a poor practice as related to security which should not be facilitated through standardization. By removing this problematic construct, better solutions are more likely to be found. At least (ab)use of the mnemonic will have been discouraged. Any continued use of this mnemonic should be discouraged and the note added should clarify one of the reasons for this mnemonic being deprecated is specifically due to its varied and checkered meanings in other drafts. -Doug From discuss-bounces@apps.ietf.org Thu May 17 11:58:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoiNE-0001R8-J7; Thu, 17 May 2007 11:58:40 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HnwdZ-00062l-N3 for discuss-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 09:00:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnwdZ-00062c-DH for discuss@apps.ietf.org; Tue, 15 May 2007 09:00:21 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnwdV-0006rR-Sp for discuss@apps.ietf.org; Tue, 15 May 2007 09:00:21 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 15 May 2007 14:00:14 +0100 Message-ID: <4648E788.30907@isode.com> Date: Mon, 14 May 2007 23:49:44 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: Use of LWSP in ABNF -- consensus call References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-Mailman-Approved-At: Thu, 17 May 2007 11:58:36 -0400 Cc: Apps Discuss , Paul Overell , Dave Crocker , IETF General Discussion Mailing List , ietf-dkim@mipassoc.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Lisa Dusseault wrote: > The IESG reviewed rfc4234bis-00.txt> for publication as Internet Standard and would > like to know if there is consensus to recommend against the use of > LWSP in future specifications, as it has caused problems recently in > DKIM and could cause problems in other places. > > Some discussion on this point already: > - http://www1.ietf.org/mail-archive/web/ietf/current/msg46048.html > - http://www1.ietf.org/mail-archive/web/discuss/current/msg00463.html > - http://mipassoc.org/pipermail/ietf-dkim/2007q1/007295.html > - https://datatracker.ietf.org/public/pidtracker.cgi? > command=view_comment&id=66440 (in this tracker comment, Chris Newman > recommended to remove LWSP, but for backward-compatibility it's > probably better to keep it and recommend against use) I think it would be better to keep LWSP and recommending against its use. Running grep on various RFCs shows that this production is referenced in several RFCs, even in some recent ones. I don't object to Chris' idea to add FWS to the ABNF document. From discuss-bounces@apps.ietf.org Thu May 17 11:58:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoiNE-0001SL-UN; Thu, 17 May 2007 11:58:40 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ho31o-0007SK-PZ for discuss-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 15:49:48 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ho31o-0007SC-G6 for discuss@apps.ietf.org; Tue, 15 May 2007 15:49:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho2zY-00077k-65 for discuss@apps.ietf.org; Tue, 15 May 2007 15:47:28 -0400 Received: from post4.cox.com ([24.248.72.37] helo=cox.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ho2zW-00009f-OC for discuss@apps.ietf.org; Tue, 15 May 2007 15:47:28 -0400 Received: from ([192.168.72.254]) by post4.cox.com with ESMTP id KP-VXH63.248442692; Tue, 15 May 2007 15:32:09 -0400 Received: from CATL0MS21.CORP.COX.COM ([10.64.210.21]) by catl0ms22.CORP.COX.COM with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 May 2007 15:32:09 -0400 Received: from CATL0MS02.corp.cox.com ([10.62.210.88]) by CATL0MS21.CORP.COX.COM with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 May 2007 15:32:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call Date: Tue, 15 May 2007 15:32:08 -0400 Message-ID: In-Reply-To: <01MGM4D77428000053@mauve.mrochek.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call thread-index: AceXJL/p+nLURLiDSHCnoolTKHn08QAAvKtg References: "Your message dated Mon, 14 May 2007 23:20:28 -0400"<464926FC.30109@att.com> <01MGM4D77428000053@mauve.mrochek.com> From: To: , X-OriginalArrivalTime: 15 May 2007 19:32:09.0097 (UTC) FILETIME=[BA730F90:01C79727] X-Spam-Score: 0.2 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-TMDA-Confirmed: Tue, 15 May 2007 15:49:48 -0400 X-Mailman-Approved-At: Thu, 17 May 2007 11:58:36 -0400 Cc: discuss@apps.ietf.org, ietf@ietf.org, ietf-dkim@mipassoc.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Add a warning note Bill Oxley Messaging Engineer Cox Communications 404-847-6397 -----Original Message----- From: ietf-dkim-bounces@mipassoc.org [mailto:ietf-dkim-bounces@mipassoc.org] On Behalf Of ned+dkim@mauve.mrochek.com Sent: Tuesday, May 15, 2007 3:03 PM To: Tony Hansen Cc: Apps Discuss; IETF General Discussion Mailing List; ietf-dkim@mipassoc.org Subject: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call > Lisa Dusseault wrote: > > I share your concerns about removing rules that are already in use -- > > that would generally be a bad thing. However I'm interested in the > > consensus around whether a warning or a deprecation statement would be a > > good thing. > LWSP has a valid meaning and use, and its being misapplied somewhere > doesn't make that meaning and usage invalid. I could see a note being > added. However, anything more than that is totally inappropriate. Full agreement with Tony here. Ned _______________________________________________ NOTE WELL: This list operates according to=20 http://mipassoc.org/dkim/ietf-list-rules.html From discuss-bounces@apps.ietf.org Thu May 17 12:17:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoifi-0006eT-7g; Thu, 17 May 2007 12:17:46 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hoifh-0006eO-8Q for discuss-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 12:17:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoifg-0006eG-Us for discuss@apps.ietf.org; Thu, 17 May 2007 12:17:44 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hoiff-00043r-Ik for discuss@apps.ietf.org; Thu, 17 May 2007 12:17:44 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HoifY-0005yk-HD; Thu, 17 May 2007 12:17:36 -0400 Date: Thu, 17 May 2007 12:17:35 -0400 From: John C Klensin To: Dave Crocker , Harald Alvestrand Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call Message-ID: <1504A69099CF1B62F66FE576@p3.JCK.COM> In-Reply-To: <4649FB9A.9000107@bbiw.net> References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> <4649FB9A.9000107@bbiw.net> 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-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Apps Discuss , IETF General Discussion Mailing List , ietf-dkim@mipassoc.org, Paul Overell X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --On Tuesday, 15 May, 2007 11:27 -0700 Dave Crocker wrote: > Were we to deprecate every feature in IETF specifications that > get mis-implemented a couple of times over 10 years, I suspect > much of our technology would be deprecated... IMO, and at the risk of again agreeing with Dave, this is the issue for me. If we have inconsistent uses of terminology across documents that are supposed to be using the same, standardized, term, then that is a problem with our review process. If the term is explicitly standardized in one of the documents, that is the definition; things that use the term incorrectly should be candidates for fixing. By contrast, if we consider "misused sometimes" or "ambiguous with other uses" as a sufficient condition for deprecating the term itself, then we have a long list of terms to deprecate in front of us, almost certainly starting with "IP", which refers to several different protocols, a protocol layer, and something that often involves lawyers. I think some warning language about safe and unsafe contexts may be in order for this construction but I expect that everyone who is arguing for deprecating it entirely (or inserting a strong "don't use this" statement) will be making a case for similar language the next time an IPv6 document comes up for review. john From discuss-bounces@apps.ietf.org Thu May 17 13:35:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hojt3-00062T-C3; Thu, 17 May 2007 13:35:37 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hojt3-00062O-04 for discuss-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 13:35:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hojt2-00062G-Mh for discuss@apps.ietf.org; Thu, 17 May 2007 13:35:36 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hojt2-0002Pj-61 for discuss@apps.ietf.org; Thu, 17 May 2007 13:35:36 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Hojsy-00073V-Qn; Thu, 17 May 2007 13:35:33 -0400 Date: Thu, 17 May 2007 13:35:31 -0400 From: John C Klensin To: Sam Hartman Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call Message-ID: In-Reply-To: References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> <4649FB9A.9000107@bbiw.net> <1504A69099CF1B62F66FE576@p3.JCK.COM> 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-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: ietf-dkim@mipassoc.org, Apps Discuss , Harald Alvestrand , Dave Crocker , Paul Overell , IETF General Discussion Mailing List X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --On Thursday, 17 May, 2007 12:42 -0400 Sam Hartman wrote: > I don't see why the standardized definition is the obvious > right place to fix things. I thought we were committed to > running code. To me, one implication of that commitment is > that sometimes the right fix is for the spec to change rather > than the implementations. > > In a terminology conflict, this often involves moving away > from the term that has two conflicting uses to terms that are > more clear. > > Ultimately cases like this should be evaluated based on > whether the final result is more clear overall. Sam, Two observations; I hope you don't think they are contradictory. (1) We regularly get ourselves into intellectual and procedural difficulties by treating specifications about how protocol specifications are written as if they were protocol specifications. When we try to avoid that, we get ourselves into worse problems. Using rules that are more or less arbitrary, we make some of these documents Proposed Standards and then try to progress them, we make others into BCPs and, now, we make still others into IONs. If we are going to standardize a definitional requirement or method -- whether it is ABNF or IPR boilerplate or something -- we need to get it right as a self-contained definition and then live with it. We should certainly revise and replace it if it turns out to be unworkable (as has happened with IPR work) or if the definition turns out to be inadequate to permit an unambiguous interpretation (that issue spills over into my second observation, below). But, once other specifications start to depend on the definitions that are there, and show those definitions to be adequate, we should not be talking about deprecating definitions unless we are prepared to "that was wrong, we need to start over (even though some of the older material may still be useful)". Again, please note the similarity to the IPR work. (2) If we pretend that the ABNF metalanguage and definitions are actually a protocol specification, then we need to evaluate it as one. Then, we have the following criteria (which we usually don't state quite this precisely): (i) Is the definition good enough that interoperable implementations are possible? (ii) Do people care enough about the construct to actually use it in ways that show it is useful? Now, neither of those rules prevents non-conforming "implementations". We may notice that those exist, but our concern is only about implementations that appear to conform to the spec and are (or are not) interoperable. If non-conforming implementations happen by accident because the text isn't clear enough, we try to clarify the text. But we don't say "well, there are non-conforming implementations, so the spec is broken". That would make no sense at all, at least to me. The answer to (i) appears to be "yes". There are lots of conforming cases. And the answer to (ii) is, as Dave as pointed out repeatedly, "about 30 years worth". Is this construction dangerous if used in inappropriate contexts? Sure. Does that justify a warning note to the unwary? Probably. Is it possible to implement other things and call them by the same name (i.e., create a non-conforming implementation)? Of course. Should that invalidate the definition? Not if we want to have anything left if the principle were applied broadly. john From discuss-bounces@apps.ietf.org Thu May 17 13:36:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hojtb-0006QQ-IG; Thu, 17 May 2007 13:36:11 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HojtZ-0006Pr-JQ for discuss-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 13:36:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HojtZ-0006PU-92 for discuss@apps.ietf.org; Thu, 17 May 2007 13:36:09 -0400 Received: from [207.97.230.49] (helo=inbound.appriver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HojtX-0002Y7-Tl for discuss@apps.ietf.org; Thu, 17 May 2007 13:36:09 -0400 Received: by inbound.appriver.com (CommuniGate Pro PIPE 5.1.4) with PIPE id 24453975; Thu, 17 May 2007 13:36:11 -0400 Received: from [156.154.16.145] (HELO megatron.ietf.org) by inbound.appriver.com (CommuniGate Pro SMTP 5.1.4) with ESMTPS id 24453920 for dsummers@marbaugh.com; Thu, 17 May 2007 13:36:06 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hojt4-00063b-Pi; Thu, 17 May 2007 13:35:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hojt3-00062l-JR for ietf@ietf.org; Thu, 17 May 2007 13:35:37 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hojt2-0002QJ-Rk for ietf@ietf.org; Thu, 17 May 2007 13:35:37 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Hojsy-00073V-Qn; Thu, 17 May 2007 13:35:33 -0400 Date: Thu, 17 May 2007 13:35:31 -0400 From: John C Klensin To: Sam Hartman Message-ID: In-Reply-To: References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> <4649FB9A.9000107@bbiw.net> <1504A69099CF1B62F66FE576@p3.JCK.COM> 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-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Policy: marbaugh.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: Spam Tests Failed: X-Country-Path: LOCAL->UNITED STATES->PRIVATE->LOCAL->UNITED STATES->UNITED STATES X-Note-Sending-IP: 156.154.16.145 X-Note-Reverse-DNS: lists.ietf.ORG X-Note-WHTLIST: ietf-bounces@ietf.org X-Note: User Rule Hits: X-Note: Mail Class: VALID Cc: IETF General Discussion Mailing List , Harald Alvestrand , Apps Discuss , Dave Crocker , Paul Overell , ietf-dkim@mipassoc.org X-BeenThere: discuss@apps.ietf.org List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org : X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 --On Thursday, 17 May, 2007 12:42 -0400 Sam Hartman wrote: > I don't see why the standardized definition is the obvious > right place to fix things. I thought we were committed to > running code. To me, one implication of that commitment is > that sometimes the right fix is for the spec to change rather > than the implementations. > > In a terminology conflict, this often involves moving away > from the term that has two conflicting uses to terms that are > more clear. > > Ultimately cases like this should be evaluated based on > whether the final result is more clear overall. Sam, Two observations; I hope you don't think they are contradictory. (1) We regularly get ourselves into intellectual and procedural difficulties by treating specifications about how protocol specifications are written as if they were protocol specifications. When we try to avoid that, we get ourselves into worse problems. Using rules that are more or less arbitrary, we make some of these documents Proposed Standards and then try to progress them, we make others into BCPs and, now, we make still others into IONs. If we are going to standardize a definitional requirement or method -- whether it is ABNF or IPR boilerplate or something -- we need to get it right as a self-contained definition and then live with it. We should certainly revise and replace it if it turns out to be unworkable (as has happened with IPR work) or if the definition turns out to be inadequate to permit an unambiguous interpretation (that issue spills over into my second observation, below). But, once other specifications start to depend on the definitions that are there, and show those definitions to be adequate, we should not be talking about deprecating definitions unless we are prepared to "that was wrong, we need to start over (even though some of the older material may still be useful)". Again, please note the similarity to the IPR work. (2) If we pretend that the ABNF metalanguage and definitions are actually a protocol specification, then we need to evaluate it as one. Then, we have the following criteria (which we usually don't state quite this precisely): (i) Is the definition good enough that interoperable implementations are possible? (ii) Do people care enough about the construct to actually use it in ways that show it is useful? Now, neither of those rules prevents non-conforming "implementations". We may notice that those exist, but our concern is only about implementations that appear to conform to the spec and are (or are not) interoperable. If non-conforming implementations happen by accident because the text isn't clear enough, we try to clarify the text. But we don't say "well, there are non-conforming implementations, so the spec is broken". That would make no sense at all, at least to me. The answer to (i) appears to be "yes". There are lots of conforming cases. And the answer to (ii) is, as Dave as pointed out repeatedly, "about 30 years worth". Is this construction dangerous if used in inappropriate contexts? Sure. Does that justify a warning note to the unwary? Probably. Is it possible to implement other things and call them by the same name (i.e., create a non-conforming implementation)? Of course. Should that invalidate the definition? Not if we want to have anything left if the principle were applied broadly. john _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From discuss-bounces@apps.ietf.org Thu May 17 13:36:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HojuM-0007Aa-Rt; Thu, 17 May 2007 13:36:58 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HojuL-0007AV-Gq for discuss-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 13:36:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HojuL-0007A1-6r for discuss@apps.ietf.org; Thu, 17 May 2007 13:36:57 -0400 Received: from [69.20.68.131] (helo=inbound.appriver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HojuJ-00036Z-S5 for discuss@apps.ietf.org; Thu, 17 May 2007 13:36:57 -0400 Received: by inbound.appriver.com (CommuniGate Pro PIPE 5.1.4) with PIPE id 305740047; Thu, 17 May 2007 13:36:53 -0400 Received: from megatron.ietf.org ([156.154.16.145] verified) by inbound.appriver.com (CommuniGate Pro SMTP 5.1.4) with ESMTPS id 305739743 for davez@pesystems.com; Thu, 17 May 2007 13:36:50 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hojt4-00063b-Vb; Thu, 17 May 2007 13:35:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hojt3-00062l-JR for ietf@ietf.org; Thu, 17 May 2007 13:35:37 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hojt2-0002QJ-Rk for ietf@ietf.org; Thu, 17 May 2007 13:35:37 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Hojsy-00073V-Qn; Thu, 17 May 2007 13:35:33 -0400 Date: Thu, 17 May 2007 13:35:31 -0400 From: John C Klensin To: Sam Hartman Message-ID: In-Reply-To: References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> <4649FB9A.9000107@bbiw.net> <1504A69099CF1B62F66FE576@p3.JCK.COM> 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-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Policy: pesystems.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: Spam Tests Failed: X-Country-Path: LOCAL->UNITED STATES->PRIVATE->LOCAL->UNITED STATES->UNITED STATES X-Note-Sending-IP: 156.154.16.145 X-Note-Reverse-DNS: megatron.ietf.ORG X-Note-WHTLIST: ietf-bounces@ietf.org X-Note: User Rule Hits: X-Note: Mail Class: VALID Cc: IETF General Discussion Mailing List , Harald Alvestrand , Apps Discuss , Dave Crocker , Paul Overell , ietf-dkim@mipassoc.org X-BeenThere: discuss@apps.ietf.org List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org : X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 --On Thursday, 17 May, 2007 12:42 -0400 Sam Hartman wrote: > I don't see why the standardized definition is the obvious > right place to fix things. I thought we were committed to > running code. To me, one implication of that commitment is > that sometimes the right fix is for the spec to change rather > than the implementations. > > In a terminology conflict, this often involves moving away > from the term that has two conflicting uses to terms that are > more clear. > > Ultimately cases like this should be evaluated based on > whether the final result is more clear overall. Sam, Two observations; I hope you don't think they are contradictory. (1) We regularly get ourselves into intellectual and procedural difficulties by treating specifications about how protocol specifications are written as if they were protocol specifications. When we try to avoid that, we get ourselves into worse problems. Using rules that are more or less arbitrary, we make some of these documents Proposed Standards and then try to progress them, we make others into BCPs and, now, we make still others into IONs. If we are going to standardize a definitional requirement or method -- whether it is ABNF or IPR boilerplate or something -- we need to get it right as a self-contained definition and then live with it. We should certainly revise and replace it if it turns out to be unworkable (as has happened with IPR work) or if the definition turns out to be inadequate to permit an unambiguous interpretation (that issue spills over into my second observation, below). But, once other specifications start to depend on the definitions that are there, and show those definitions to be adequate, we should not be talking about deprecating definitions unless we are prepared to "that was wrong, we need to start over (even though some of the older material may still be useful)". Again, please note the similarity to the IPR work. (2) If we pretend that the ABNF metalanguage and definitions are actually a protocol specification, then we need to evaluate it as one. Then, we have the following criteria (which we usually don't state quite this precisely): (i) Is the definition good enough that interoperable implementations are possible? (ii) Do people care enough about the construct to actually use it in ways that show it is useful? Now, neither of those rules prevents non-conforming "implementations". We may notice that those exist, but our concern is only about implementations that appear to conform to the spec and are (or are not) interoperable. If non-conforming implementations happen by accident because the text isn't clear enough, we try to clarify the text. But we don't say "well, there are non-conforming implementations, so the spec is broken". That would make no sense at all, at least to me. The answer to (i) appears to be "yes". There are lots of conforming cases. And the answer to (ii) is, as Dave as pointed out repeatedly, "about 30 years worth". Is this construction dangerous if used in inappropriate contexts? Sure. Does that justify a warning note to the unwary? Probably. Is it possible to implement other things and call them by the same name (i.e., create a non-conforming implementation)? Of course. Should that invalidate the definition? Not if we want to have anything left if the principle were applied broadly. john _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From discuss-bounces@apps.ietf.org Thu May 17 13:48:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hok5I-00081N-7K; Thu, 17 May 2007 13:48:16 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hok5G-00081I-KA for discuss-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 13:48:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hok5G-000815-AK for discuss@apps.ietf.org; Thu, 17 May 2007 13:48:14 -0400 Received: from ppsw-9.csi.cam.ac.uk ([131.111.8.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hok5E-000587-15 for discuss@apps.ietf.org; Thu, 17 May 2007 13:48:14 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:42650) by ppsw-9.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1Hok59-0001CC-U8 (Exim 4.63) (return-path ); Thu, 17 May 2007 18:48:07 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Hok59-00017A-9z (Exim 4.54) (return-path ); Thu, 17 May 2007 18:48:07 +0100 Date: Thu, 17 May 2007 18:48:07 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: John C Klensin Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call In-Reply-To: Message-ID: References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> <4649FB9A.9000107@bbiw.net> <1504A69099CF1B62F66FE576@p3.JCK.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ietf-dkim@mipassoc.org, Harald Alvestrand , Apps Discuss , Dave Crocker , Paul Overell , Sam Hartman , IETF General Discussion Mailing List X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Thu, 17 May 2007, John C Klensin wrote: > > Is this construction dangerous if used in inappropriate > contexts? Sure. Does that justify a warning note to the > unwary? Probably. Is it possible to implement other things and > call them by the same name (i.e., create a non-conforming > implementation)? Of course. Should that invalidate the > definition? Not if we want to have anything left if the > principle were applied broadly. +1 Tony. -- f.a.n.finch http://dotat.at/ ROCKALL: SOUTHWEST 6 TO GALE 8, INCREASING SEVERE GALE 9, PERHAPS STORM 10 LATER. VERY ROUGH OR HIGH. SHOWERS. GOOD. From discuss-bounces@apps.ietf.org Thu May 17 13:48:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hok5v-0008N6-Jp; Thu, 17 May 2007 13:48:55 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hok5u-0008N1-9F for discuss-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 13:48:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hok5t-0008MB-Uf for discuss@apps.ietf.org; Thu, 17 May 2007 13:48:53 -0400 Received: from [207.97.230.49] (helo=inbound.appriver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hok5t-0005MA-M1 for discuss@apps.ietf.org; Thu, 17 May 2007 13:48:53 -0400 Received: by inbound.appriver.com (CommuniGate Pro PIPE 5.1.4) with PIPE id 24463082; Thu, 17 May 2007 13:48:56 -0400 Received: from [156.154.16.145] (HELO megatron.ietf.org) by inbound.appriver.com (CommuniGate Pro SMTP 5.1.4) with ESMTPS id 24462946 for dsummers@marbaugh.com; Thu, 17 May 2007 13:48:53 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hok5L-00082z-KE; Thu, 17 May 2007 13:48:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hok5J-00082r-K1 for ietf@ietf.org; Thu, 17 May 2007 13:48:17 -0400 Received: from ppsw-9.csi.cam.ac.uk ([131.111.8.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hok5I-00058F-AH for ietf@ietf.org; Thu, 17 May 2007 13:48:17 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:42650) by ppsw-9.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1Hok59-0001CC-U8 (Exim 4.63) (return-path ); Thu, 17 May 2007 18:48:07 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Hok59-00017A-9z (Exim 4.54) (return-path ); Thu, 17 May 2007 18:48:07 +0100 Date: Thu, 17 May 2007 18:48:07 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: John C Klensin In-Reply-To: Message-ID: References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> <4649FB9A.9000107@bbiw.net> <1504A69099CF1B62F66FE576@p3.JCK.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Policy: marbaugh.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: Spam Tests Failed: X-Country-Path: ->UNITED KINGDOM->UNITED KINGDOM->PRIVATE->LOCAL->UNITED STATES->UNITED STATES X-Note-Sending-IP: 156.154.16.145 X-Note-Reverse-DNS: lists.ietf.ORG X-Note-WHTLIST: ietf-bounces@ietf.org X-Note: User Rule Hits: X-Note: Mail Class: VALID Cc: ietf-dkim@mipassoc.org, Apps Discuss , Harald Alvestrand , Dave Crocker , Paul Overell , Sam Hartman , IETF General Discussion Mailing List X-BeenThere: discuss@apps.ietf.org List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org : X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On Thu, 17 May 2007, John C Klensin wrote: > > Is this construction dangerous if used in inappropriate > contexts? Sure. Does that justify a warning note to the > unwary? Probably. Is it possible to implement other things and > call them by the same name (i.e., create a non-conforming > implementation)? Of course. Should that invalidate the > definition? Not if we want to have anything left if the > principle were applied broadly. +1 Tony. -- f.a.n.finch http://dotat.at/ ROCKALL: SOUTHWEST 6 TO GALE 8, INCREASING SEVERE GALE 9, PERHAPS STORM 10 LATER. VERY ROUGH OR HIGH. SHOWERS. GOOD. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From discuss-bounces@apps.ietf.org Thu May 17 14:02:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HokJE-0004wE-8O; Thu, 17 May 2007 14:02:40 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HokJC-0004w4-JA for discuss-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 14:02:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HokJC-0004vr-9H for discuss@apps.ietf.org; Thu, 17 May 2007 14:02:38 -0400 Received: from [74.205.4.62] (helo=inbound.appriver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HokJA-00038n-Tn for discuss@apps.ietf.org; Thu, 17 May 2007 14:02:38 -0400 Received: by inbound.appriver.com (CommuniGate Pro PIPE 5.1.5) with PIPE id 141157229; Thu, 17 May 2007 13:59:48 -0400 Received: from megatron.ietf.org ([156.154.16.145] verified) by inbound.appriver.com (CommuniGate Pro SMTP 5.1.5) with ESMTPS id 141157049 for davez@pesystems.com; Thu, 17 May 2007 13:59:41 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hok5L-00082z-PU; Thu, 17 May 2007 13:48:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hok5J-00082r-K1 for ietf@ietf.org; Thu, 17 May 2007 13:48:17 -0400 Received: from ppsw-9.csi.cam.ac.uk ([131.111.8.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hok5I-00058F-AH for ietf@ietf.org; Thu, 17 May 2007 13:48:17 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:42650) by ppsw-9.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1Hok59-0001CC-U8 (Exim 4.63) (return-path ); Thu, 17 May 2007 18:48:07 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Hok59-00017A-9z (Exim 4.54) (return-path ); Thu, 17 May 2007 18:48:07 +0100 Date: Thu, 17 May 2007 18:48:07 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: John C Klensin In-Reply-To: Message-ID: References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> <4649FB9A.9000107@bbiw.net> <1504A69099CF1B62F66FE576@p3.JCK.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Policy: pesystems.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: Spam Tests Failed: X-Country-Path: ->UNITED KINGDOM->UNITED KINGDOM->PRIVATE->LOCAL->UNITED STATES->UNITED STATES X-Note-Sending-IP: 156.154.16.145 X-Note-Reverse-DNS: megatron.ietf.ORG X-Note-WHTLIST: ietf-bounces@ietf.org X-Note: User Rule Hits: X-Note: Mail Class: VALID Cc: ietf-dkim@mipassoc.org, Apps Discuss , Harald Alvestrand , Dave Crocker , Paul Overell , Sam Hartman , IETF General Discussion Mailing List X-BeenThere: discuss@apps.ietf.org List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org : X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On Thu, 17 May 2007, John C Klensin wrote: > > Is this construction dangerous if used in inappropriate > contexts? Sure. Does that justify a warning note to the > unwary? Probably. Is it possible to implement other things and > call them by the same name (i.e., create a non-conforming > implementation)? Of course. Should that invalidate the > definition? Not if we want to have anything left if the > principle were applied broadly. +1 Tony. -- f.a.n.finch http://dotat.at/ ROCKALL: SOUTHWEST 6 TO GALE 8, INCREASING SEVERE GALE 9, PERHAPS STORM 10 LATER. VERY ROUGH OR HIGH. SHOWERS. GOOD. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From discuss-bounces@apps.ietf.org Thu May 17 14:05:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HokMD-0006yy-Pa; Thu, 17 May 2007 14:05:45 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HokMD-0006yt-5y for discuss-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 14:05:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HokMC-0006yl-SY for discuss@apps.ietf.org; Thu, 17 May 2007 14:05:44 -0400 Received: from [74.205.4.62] (helo=inbound.appriver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HokM9-0004Pu-Jf for discuss@apps.ietf.org; Thu, 17 May 2007 14:05:44 -0400 Received: by inbound.appriver.com (CommuniGate Pro PIPE 5.1.5) with PIPE id 141157229; Thu, 17 May 2007 13:59:48 -0400 Received: from megatron.ietf.org ([156.154.16.145] verified) by inbound.appriver.com (CommuniGate Pro SMTP 5.1.5) with ESMTPS id 141157049 for davez@pesystems.com; Thu, 17 May 2007 13:59:41 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hok5L-00082z-PU; Thu, 17 May 2007 13:48:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hok5J-00082r-K1 for ietf@ietf.org; Thu, 17 May 2007 13:48:17 -0400 Received: from ppsw-9.csi.cam.ac.uk ([131.111.8.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hok5I-00058F-AH for ietf@ietf.org; Thu, 17 May 2007 13:48:17 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:42650) by ppsw-9.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1Hok59-0001CC-U8 (Exim 4.63) (return-path ); Thu, 17 May 2007 18:48:07 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Hok59-00017A-9z (Exim 4.54) (return-path ); Thu, 17 May 2007 18:48:07 +0100 Date: Thu, 17 May 2007 18:48:07 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: John C Klensin In-Reply-To: Message-ID: References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> <4649FB9A.9000107@bbiw.net> <1504A69099CF1B62F66FE576@p3.JCK.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Policy: pesystems.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: Spam Tests Failed: X-Country-Path: ->UNITED KINGDOM->UNITED KINGDOM->PRIVATE->LOCAL->UNITED STATES->UNITED STATES X-Note-Sending-IP: 156.154.16.145 X-Note-Reverse-DNS: megatron.ietf.ORG X-Note-WHTLIST: ietf-bounces@ietf.org X-Note: User Rule Hits: X-Note: Mail Class: VALID Cc: ietf-dkim@mipassoc.org, Apps Discuss , Harald Alvestrand , Dave Crocker , Paul Overell , Sam Hartman , IETF General Discussion Mailing List X-BeenThere: discuss@apps.ietf.org List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org : X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On Thu, 17 May 2007, John C Klensin wrote: > > Is this construction dangerous if used in inappropriate > contexts? Sure. Does that justify a warning note to the > unwary? Probably. Is it possible to implement other things and > call them by the same name (i.e., create a non-conforming > implementation)? Of course. Should that invalidate the > definition? Not if we want to have anything left if the > principle were applied broadly. +1 Tony. -- f.a.n.finch http://dotat.at/ ROCKALL: SOUTHWEST 6 TO GALE 8, INCREASING SEVERE GALE 9, PERHAPS STORM 10 LATER. VERY ROUGH OR HIGH. SHOWERS. GOOD. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From discuss-bounces@apps.ietf.org Thu May 17 15:50:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HolzK-0000Uq-5w; Thu, 17 May 2007 15:50:14 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HolzI-0000Sr-DU for discuss-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 15:50:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HolzH-0000SS-RZ for discuss@apps.ietf.org; Thu, 17 May 2007 15:50:11 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HolzH-0001Tg-BW for discuss@apps.ietf.org; Thu, 17 May 2007 15:50:11 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HolzE-0008Th-HM; Thu, 17 May 2007 15:50:08 -0400 Date: Thu, 17 May 2007 15:50:07 -0400 From: John C Klensin To: Sam Hartman Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call Message-ID: In-Reply-To: References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> <4649FB9A.9000107@bbiw.net> <1504A69099CF1B62F66FE576@p3.JCK.COM> 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-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: IETF General Discussion Mailing List , Harald Alvestrand , Apps Discuss , Dave Crocker , Paul Overell , ietf-dkim@mipassoc.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Sam, with one small exception, I think we are in complete agreement. The exception is noted below... --On Thursday, 17 May, 2007 15:32 -0400 Sam Hartman wrote: > Right. Here, I don't think the definition is wrong, I just > think the term being defined is wrong. We proposed a > definition for a useful concept. The word we chose (LWSP) > stuck in some places but not in others. IN fact other people > used the same word for a different although related concept. > sufficiently so that the definition we proposed in ABNF is not > the most common definition in our standards. Counting uses in this way so as to determine what is or is not the "most common definition" is as tricky in our environment as counting votes. For the same reason, I'd rather that we avoid it when we can. However, if we do need to count, I think we have to use some sort of system that attributes more weight to documents that use the terminology that have been, effectively, at full standard before some of the specifications that use different definitions were even dreamt of. I don't know how to assign those weights, which, recursively, is why I don't like counting. But I don't think you can count up a handful of recent misuses and then make an inference that the base definition needs to be retired (which you haven't done, but several others have), or even that it is not appropriately "common". > I think that in this instance, the value of future clarity > justifies coming up with a new term that will unambiguously > mean what LWSP means in ABNF today. That term will have to > start at proposed standard. Pragmatically, perhaps yes. But what I keep coming back to is that it appears to me to be perfectly clear and unambiguous "what LWSP means in ABNF today". That is what is written into the spec. As far as I can tell, we are having a discussion about two other things: (1) Other specifications that use the term "LWSP" to refer to something different from what is unambiguously defined in the ABNF spec. (2) Places where people might be tempted to use LWSP but where they have discovered that LWSP is either inappropriate or risky. The second group clearly needs new and appropriate terminology for what they do need and use. The first group is, IMO, just broken. > LWSP will need to continue in ABNF. > > I see a desire to document our operational experience with the > word: many people took this word and used it to mean something > else. Perhaps to avoid confusion you should consider whether > your use of the word is a good idea. I think there is > significant harm in choosing not to document this operational > experience when advancing standards. After all, we both agree > that it is this experience with running code that gives the > IETF value. Again, I have no problems with making carefully-considered comments about use and misuse. I think it is a fine idea as long as those comments do not imply that the misuses are a failure in the base specification. And I think everyone should consider a stopping rule, lest, as I indicated in my deliberately extreme example, we discover that we want to retire, replace, or update "IP" because of some use in the legal community that precedes the use in network protocols by many years. john From discuss-bounces@apps.ietf.org Thu May 17 15:50:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Holzw-0001d8-HW; Thu, 17 May 2007 15:50:52 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Holzh-0000tW-BU for discuss-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 15:50:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Holzg-0000sg-Sw for discuss@apps.ietf.org; Thu, 17 May 2007 15:50:36 -0400 Received: from [207.97.230.61] (helo=inbound.appriver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Holzg-0001XQ-Hw for discuss@apps.ietf.org; Thu, 17 May 2007 15:50:36 -0400 Received: by inbound.appriver.com (CommuniGate Pro PIPE 5.1.5) with PIPE id 42084; Thu, 17 May 2007 15:50:39 -0400 Received: from megatron.ietf.org ([156.154.16.145] verified) by inbound.appriver.com (CommuniGate Pro SMTP 5.1.5) with ESMTPS id 41925 for dsummers@marbaugh.com; Thu, 17 May 2007 15:50:36 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HolzP-0000Yo-HG; Thu, 17 May 2007 15:50:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HolzO-0000Xr-2i for ietf@ietf.org; Thu, 17 May 2007 15:50:18 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HolzN-0001UF-Ia for ietf@ietf.org; Thu, 17 May 2007 15:50:18 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HolzE-0008Th-HM; Thu, 17 May 2007 15:50:08 -0400 Date: Thu, 17 May 2007 15:50:07 -0400 From: John C Klensin To: Sam Hartman Message-ID: In-Reply-To: References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> <4649FB9A.9000107@bbiw.net> <1504A69099CF1B62F66FE576@p3.JCK.COM> 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-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Policy: marbaugh.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: Spam Tests Failed: X-Country-Path: LOCAL->UNITED STATES->PRIVATE->LOCAL->UNITED STATES->UNITED STATES X-Note-Sending-IP: 156.154.16.145 X-Note-Reverse-DNS: stiedprmman1.ietf.ORG X-Note-WHTLIST: ietf-bounces@ietf.org X-Note: User Rule Hits: X-Note: Mail Class: VALID Cc: ietf-dkim@mipassoc.org, Apps Discuss , Harald Alvestrand , Dave Crocker , Paul Overell , IETF General Discussion Mailing List X-BeenThere: discuss@apps.ietf.org List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org : X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Sam, with one small exception, I think we are in complete agreement. The exception is noted below... --On Thursday, 17 May, 2007 15:32 -0400 Sam Hartman wrote: > Right. Here, I don't think the definition is wrong, I just > think the term being defined is wrong. We proposed a > definition for a useful concept. The word we chose (LWSP) > stuck in some places but not in others. IN fact other people > used the same word for a different although related concept. > sufficiently so that the definition we proposed in ABNF is not > the most common definition in our standards. Counting uses in this way so as to determine what is or is not the "most common definition" is as tricky in our environment as counting votes. For the same reason, I'd rather that we avoid it when we can. However, if we do need to count, I think we have to use some sort of system that attributes more weight to documents that use the terminology that have been, effectively, at full standard before some of the specifications that use different definitions were even dreamt of. I don't know how to assign those weights, which, recursively, is why I don't like counting. But I don't think you can count up a handful of recent misuses and then make an inference that the base definition needs to be retired (which you haven't done, but several others have), or even that it is not appropriately "common". > I think that in this instance, the value of future clarity > justifies coming up with a new term that will unambiguously > mean what LWSP means in ABNF today. That term will have to > start at proposed standard. Pragmatically, perhaps yes. But what I keep coming back to is that it appears to me to be perfectly clear and unambiguous "what LWSP means in ABNF today". That is what is written into the spec. As far as I can tell, we are having a discussion about two other things: (1) Other specifications that use the term "LWSP" to refer to something different from what is unambiguously defined in the ABNF spec. (2) Places where people might be tempted to use LWSP but where they have discovered that LWSP is either inappropriate or risky. The second group clearly needs new and appropriate terminology for what they do need and use. The first group is, IMO, just broken. > LWSP will need to continue in ABNF. > > I see a desire to document our operational experience with the > word: many people took this word and used it to mean something > else. Perhaps to avoid confusion you should consider whether > your use of the word is a good idea. I think there is > significant harm in choosing not to document this operational > experience when advancing standards. After all, we both agree > that it is this experience with running code that gives the > IETF value. Again, I have no problems with making carefully-considered comments about use and misuse. I think it is a fine idea as long as those comments do not imply that the misuses are a failure in the base specification. And I think everyone should consider a stopping rule, lest, as I indicated in my deliberately extreme example, we discover that we want to retire, replace, or update "IP" because of some use in the legal community that precedes the use in network protocols by many years. john _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From discuss-bounces@apps.ietf.org Thu May 17 15:53:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hom2X-0006tB-47; Thu, 17 May 2007 15:53:33 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hom2S-0006iq-T7 for discuss-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 15:53:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hom2R-0006eB-0V for discuss@apps.ietf.org; Thu, 17 May 2007 15:53:27 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hom2H-0002RR-JG for discuss@apps.ietf.org; Thu, 17 May 2007 15:53:26 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E02C52596DC; Thu, 17 May 2007 21:53:16 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24494-04; Thu, 17 May 2007 21:53:11 +0200 (CEST) Received: from [192.168.1.119] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 809612596DA; Thu, 17 May 2007 21:53:11 +0200 (CEST) Date: Thu, 17 May 2007 21:52:45 +0200 From: Harald Tveit Alvestrand To: Sam Hartman , John C Klensin Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call Message-ID: In-Reply-To: References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> <4649FB9A.9000107@bbiw.net> <1504A69099CF1B62F66FE576@p3.JCK.COM> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Apps Discuss , IETF General Discussion Mailing List , ietf-dkim@mipassoc.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --On 17. mai 2007 15:32 -0400 Sam Hartman wrote: > > Right. Here, I don't think the definition is wrong, I just think the > term being defined is wrong. We proposed a definition for a useful > concept. Actually we defined a concept (LWSP) in a way that turned out to be much more troublesome in several contexts than we thought it would be (because it allowed two different versions of "blank" lines to have different semantics). > The word we chose (LWSP) stuck in some places but not in > others. IN fact other people used the same word for a different > although related concept. sufficiently so that the definition we > proposed in ABNF is not the most common definition in our standards. > > Clearly we should not invalidate existing uses of that term. Clearly > we do need a definition for the term: it is being used usefully. I don't agree with the meaning I get from this statement. The problem is that the construct that ABNF calls "LWSP" causes problems in protocols that use it. This problem is independent of the name of the construct; the problem is in defining a grammar where the sequence has a different meaning than . Some protocols have addressed this problem by defining their own construct, and have used the term "LWSP" to refer to it - something that is legal by ABNF rules, but can cause people who read multiple specs to become confused. There seems to be some reason to think that it's useful to warn people that there's reasons not to use the construct that is defined as "LWSP" in the ABNF spec. The revised version of the ABNF spec is one possible place to put that warning. > I think that in this instance, the value of future clarity justifies > coming up with a new term that will unambiguously mean what LWSP > means in ABNF today. That term will have to start at proposed > standard. > > LWSP will need to continue in ABNF. I agree with the last statement. > I see a desire to document our operational experience with the word: > many people took this word and used it to mean something else. > Perhaps to avoid confusion you should consider whether your use of the > word is a good idea. I think there is significant harm in choosing > not to document this operational experience when advancing standards. > After all, we both agree that it is this experience with running code > that gives the IETF value. Fully agree with this statement too, but since I don't agree with your interpretation (as given above) of what the problem is, I can't be sure that my agreement with this statement means anything.... Harald From discuss-bounces@apps.ietf.org Thu May 17 15:59:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hom8K-000501-A9; Thu, 17 May 2007 15:59:32 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hom8J-0004zu-0E for discuss-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 15:59:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hom8I-0004zk-Ma for discuss@apps.ietf.org; Thu, 17 May 2007 15:59:30 -0400 Received: from server41d.appriver.com ([74.205.4.36] helo=inbound.appriver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hom7v-0003rX-Q3 for discuss@apps.ietf.org; Thu, 17 May 2007 15:59:30 -0400 Received: by inbound.appriver.com (CommuniGate Pro PIPE 5.1.7) with PIPE id 10318; Thu, 17 May 2007 15:55:07 -0400 Received: from megatron.ietf.org ([156.154.16.145] verified) by inbound.appriver.com (CommuniGate Pro SMTP 5.1.7) with ESMTPS id 10300 for davez@pesystems.com; Thu, 17 May 2007 15:55:00 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HolzP-0000Yo-Mx; Thu, 17 May 2007 15:50:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HolzO-0000Xr-2i for ietf@ietf.org; Thu, 17 May 2007 15:50:18 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HolzN-0001UF-Ia for ietf@ietf.org; Thu, 17 May 2007 15:50:18 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HolzE-0008Th-HM; Thu, 17 May 2007 15:50:08 -0400 Date: Thu, 17 May 2007 15:50:07 -0400 From: John C Klensin To: Sam Hartman Message-ID: In-Reply-To: References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> <4649FB9A.9000107@bbiw.net> <1504A69099CF1B62F66FE576@p3.JCK.COM> 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-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Policy: pesystems.com X-Note: This Email was scanned by AppRiver SecureTide X-Warn: HELOBOGUS HELO command domain megatron.ietf.org has no A or MX records. X-Note: Spam Tests Failed: HELOBOGUS X-Country-Path: LOCAL->UNITED STATES->PRIVATE->LOCAL->UNITED STATES->UNITED STATES X-Note-Sending-IP: 156.154.16.145 X-Note-Reverse-DNS: odin.ietf.ORG X-Note-WHTLIST: ietf-bounces@ietf.org X-Note: User Rule Hits: X-Note: Mail Class: VALID Cc: ietf-dkim@mipassoc.org, Apps Discuss , Harald Alvestrand , Dave Crocker , Paul Overell , IETF General Discussion Mailing List X-BeenThere: discuss@apps.ietf.org List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org : X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Sam, with one small exception, I think we are in complete agreement. The exception is noted below... --On Thursday, 17 May, 2007 15:32 -0400 Sam Hartman wrote: > Right. Here, I don't think the definition is wrong, I just > think the term being defined is wrong. We proposed a > definition for a useful concept. The word we chose (LWSP) > stuck in some places but not in others. IN fact other people > used the same word for a different although related concept. > sufficiently so that the definition we proposed in ABNF is not > the most common definition in our standards. Counting uses in this way so as to determine what is or is not the "most common definition" is as tricky in our environment as counting votes. For the same reason, I'd rather that we avoid it when we can. However, if we do need to count, I think we have to use some sort of system that attributes more weight to documents that use the terminology that have been, effectively, at full standard before some of the specifications that use different definitions were even dreamt of. I don't know how to assign those weights, which, recursively, is why I don't like counting. But I don't think you can count up a handful of recent misuses and then make an inference that the base definition needs to be retired (which you haven't done, but several others have), or even that it is not appropriately "common". > I think that in this instance, the value of future clarity > justifies coming up with a new term that will unambiguously > mean what LWSP means in ABNF today. That term will have to > start at proposed standard. Pragmatically, perhaps yes. But what I keep coming back to is that it appears to me to be perfectly clear and unambiguous "what LWSP means in ABNF today". That is what is written into the spec. As far as I can tell, we are having a discussion about two other things: (1) Other specifications that use the term "LWSP" to refer to something different from what is unambiguously defined in the ABNF spec. (2) Places where people might be tempted to use LWSP but where they have discovered that LWSP is either inappropriate or risky. The second group clearly needs new and appropriate terminology for what they do need and use. The first group is, IMO, just broken. > LWSP will need to continue in ABNF. > > I see a desire to document our operational experience with the > word: many people took this word and used it to mean something > else. Perhaps to avoid confusion you should consider whether > your use of the word is a good idea. I think there is > significant harm in choosing not to document this operational > experience when advancing standards. After all, we both agree > that it is this experience with running code that gives the > IETF value. Again, I have no problems with making carefully-considered comments about use and misuse. I think it is a fine idea as long as those comments do not imply that the misuses are a failure in the base specification. And I think everyone should consider a stopping rule, lest, as I indicated in my deliberately extreme example, we discover that we want to retire, replace, or update "IP" because of some use in the legal community that precedes the use in network protocols by many years. john _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From discuss-bounces@apps.ietf.org Thu May 17 17:16:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HonKu-0005eN-OZ; Thu, 17 May 2007 17:16:36 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HojDF-0006qm-0a for discuss-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 12:52:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HojDE-0006qe-NB for discuss@apps.ietf.org; Thu, 17 May 2007 12:52:24 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HojDC-0003Np-1t for discuss@apps.ietf.org; Thu, 17 May 2007 12:52:24 -0400 Received: from [10.200.96.202] ([216.168.240.140]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l4HGpn01017203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 May 2007 09:51:50 -0700 Message-ID: <464C8822.7020503@dcrocker.net> Date: Thu, 17 May 2007 09:51:46 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Sam Hartman Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> <4649FB9A.9000107@bbiw.net> <1504A69099CF1B62F66FE576@p3.JCK.COM> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-Mailman-Approved-At: Thu, 17 May 2007 17:16:34 -0400 Cc: Apps Discuss , Paul Overell , IETF General Discussion Mailing List , ietf-dkim@mipassoc.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Sam, > Ultimately cases like this should be evaluated based on whether the > final result is more clear overall. What about protecting the installed base for the existing spec? In other words, your "based on" contains a single criterion, for an environment that typically requires multiple. And the current situation is certainly one of those. Changing the specification makes sense when it does not yet have much momentum, or when the problem is basic and severe. For technology that has been in widespread use for 10-30 years, and an extremely small number of problem reports, changing the specification looks like exactly the wrong decision. -- Dave Crocker Brandenburg InternetWorking bbiw.net From discuss-bounces@apps.ietf.org Thu May 17 17:16:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HonKu-0005ef-T9; Thu, 17 May 2007 17:16:36 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HojDi-0007Tq-Jm for discuss-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 12:52:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HojDi-0007S2-7W for discuss@apps.ietf.org; Thu, 17 May 2007 12:52:54 -0400 Received: from [207.97.230.49] (helo=inbound.appriver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HojDh-0003Ve-LE for discuss@apps.ietf.org; Thu, 17 May 2007 12:52:54 -0400 Received: by inbound.appriver.com (CommuniGate Pro PIPE 5.1.4) with PIPE id 24421757; Thu, 17 May 2007 12:52:56 -0400 Received: from [156.154.16.145] (HELO megatron.ietf.org) by inbound.appriver.com (CommuniGate Pro SMTP 5.1.4) with ESMTPS id 24421719 for dsummers@marbaugh.com; Thu, 17 May 2007 12:52:54 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HojDO-0006uK-Ao; Thu, 17 May 2007 12:52:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HojDL-0006qv-VR for ietf@ietf.org; Thu, 17 May 2007 12:52:31 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HojDI-0003Pc-6m for ietf@ietf.org; Thu, 17 May 2007 12:52:31 -0400 Received: from [10.200.96.202] ([216.168.240.140]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l4HGpn01017203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 May 2007 09:51:50 -0700 Message-ID: <464C8822.7020503@dcrocker.net> Date: Thu, 17 May 2007 09:51:46 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Sam Hartman References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> <4649FB9A.9000107@bbiw.net> <1504A69099CF1B62F66FE576@p3.JCK.COM> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Policy: marbaugh.com X-Note: This Email was scanned by AppRiver SecureTide X-Warn: BADCHARSET This message uses an unknown Charset. X-Warn: NONENGLISH This message uses a non english Charset. X-Warn: WEIGHT10 X-Note: Spam Tests Failed: BADCHARSET, NONENGLISH, WEIGHT10 X-Country-Path: PRIVATE->UNITED STATES->PRIVATE->LOCAL->UNITED STATES->UNITED STATES X-Note-Sending-IP: 156.154.16.145 X-Note-Reverse-DNS: optimus.ietf.ORG X-Note-WHTLIST: ietf-bounces@ietf.org X-Note: User Rule Hits: X-Note: Mail Class: VALID X-Mailman-Approved-At: Thu, 17 May 2007 17:16:34 -0400 Cc: ietf-dkim@mipassoc.org, Apps Discuss , IETF General Discussion Mailing List , Paul Overell X-BeenThere: discuss@apps.ietf.org Reply-To: dcrocker@bbiw.net List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org : X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Sam, > Ultimately cases like this should be evaluated based on whether the > final result is more clear overall. What about protecting the installed base for the existing spec? In other words, your "based on" contains a single criterion, for an environment that typically requires multiple. And the current situation is certainly one of those. Changing the specification makes sense when it does not yet have much momentum, or when the problem is basic and severe. For technology that has been in widespread use for 10-30 years, and an extremely small number of problem reports, changing the specification looks like exactly the wrong decision. -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From discuss-bounces@apps.ietf.org Thu May 17 17:16:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HonKv-0005gS-48; Thu, 17 May 2007 17:16:37 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HojEW-0000iL-3D for discuss-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 12:53:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HojEV-0000fr-OZ for discuss@apps.ietf.org; Thu, 17 May 2007 12:53:43 -0400 Received: from [69.20.68.131] (helo=inbound.appriver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HojER-0003ef-3b for discuss@apps.ietf.org; Thu, 17 May 2007 12:53:43 -0400 Received: by inbound.appriver.com (CommuniGate Pro PIPE 5.1.4) with PIPE id 305684385; Thu, 17 May 2007 12:53:37 -0400 Received: from megatron.ietf.org ([156.154.16.145] verified) by inbound.appriver.com (CommuniGate Pro SMTP 5.1.4) with ESMTPS id 305684373 for davez@pesystems.com; Thu, 17 May 2007 12:53:36 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HojDO-0006uK-GA; Thu, 17 May 2007 12:52:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HojDL-0006qv-VR for ietf@ietf.org; Thu, 17 May 2007 12:52:31 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HojDI-0003Pc-6m for ietf@ietf.org; Thu, 17 May 2007 12:52:31 -0400 Received: from [10.200.96.202] ([216.168.240.140]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l4HGpn01017203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 May 2007 09:51:50 -0700 Message-ID: <464C8822.7020503@dcrocker.net> Date: Thu, 17 May 2007 09:51:46 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Sam Hartman References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> <4649FB9A.9000107@bbiw.net> <1504A69099CF1B62F66FE576@p3.JCK.COM> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Policy: pesystems.com X-Note: This Email was scanned by AppRiver SecureTide X-Warn: BADCHARSET This message uses an unknown Charset. X-Warn: NONENGLISH This message uses a non english Charset. X-Warn: WEIGHT10 X-Note: Spam Tests Failed: BADCHARSET, NONENGLISH, WEIGHT10 X-Country-Path: PRIVATE->UNITED STATES->PRIVATE->LOCAL->UNITED STATES->UNITED STATES X-Note-Sending-IP: 156.154.16.145 X-Note-Reverse-DNS: odin.ietf.ORG X-Note-WHTLIST: ietf-bounces@ietf.org X-Note: User Rule Hits: X-Note: Mail Class: VALID X-Mailman-Approved-At: Thu, 17 May 2007 17:16:34 -0400 Cc: ietf-dkim@mipassoc.org, Apps Discuss , IETF General Discussion Mailing List , Paul Overell X-BeenThere: discuss@apps.ietf.org Reply-To: dcrocker@bbiw.net List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org : X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Sam, > Ultimately cases like this should be evaluated based on whether the > final result is more clear overall. What about protecting the installed base for the existing spec? In other words, your "based on" contains a single criterion, for an environment that typically requires multiple. And the current situation is certainly one of those. Changing the specification makes sense when it does not yet have much momentum, or when the problem is basic and severe. For technology that has been in widespread use for 10-30 years, and an extremely small number of problem reports, changing the specification looks like exactly the wrong decision. -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From discuss-bounces@apps.ietf.org Thu May 17 17:16:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HonKv-0005hV-A4; Thu, 17 May 2007 17:16:37 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hojyv-0004uo-OZ for discuss-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 13:41:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hojyv-0004ue-Ep for discuss@apps.ietf.org; Thu, 17 May 2007 13:41:41 -0400 Received: from elasmtp-curtail.atl.sa.earthlink.net ([209.86.89.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hojyu-0003cm-4G for discuss@apps.ietf.org; Thu, 17 May 2007 13:41:41 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=HZJdGaCyeVdmVtair3LEvSmj7Krt2gyO51X7/nVkEcwEM8IvWe/DYwwniP4y0Xgx; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.125.79.23] (helo=gw) by elasmtp-curtail.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Hojyp-0000Cg-8q; Thu, 17 May 2007 13:41:35 -0400 Message-ID: <004401c798aa$a08e6fa0$174f7d40@home.glassey.com> From: "todd glassey" To: "John C Klensin" , "Sam Hartman" References: <4648E8CB.3010502@dcrocker.net><4649FA12.30909@alvestrand.no><4649FB9A.9000107@bbiw.net> <1504A69099CF1B62F66FE576@p3.JCK.COM> Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call Date: Thu, 17 May 2007 10:41:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec796f43bd5d69a97acc7cf0b054c683efad350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 X-Mailman-Approved-At: Thu, 17 May 2007 17:16:34 -0400 Cc: IETF General Discussion Mailing List , Harald Alvestrand , Apps Discuss , Dave Crocker , Paul Overell , ietf-dkim@mipassoc.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org John - I would call this post of yours "Nothing but net" ... more commentary inline below. T. > > Sam, > > Two observations; I hope you don't think they are contradictory. > > (1) We regularly get ourselves into intellectual and procedural > difficulties by treating specifications about how protocol > specifications are written as if they were protocol > specifications. WOW - talk about being 'right on the money'! > When we try to avoid that, we get ourselves > into worse problems. Using rules that are more or less > arbitrary, And this is the operable term here, that being 'arbitrary' > we make some of these documents Proposed Standards > and then try to progress them, we make others into BCPs and, > now, we make still others into IONs. AMEN! > > If we are going to standardize a definitional requirement or > method -- whether it is ABNF or IPR boilerplate or something -- > we need to get it right as a self-contained definition and then > live with it. RIGHT! > We should certainly revise and replace it if it > turns out to be unworkable (as has happened with IPR work) or if > the definition turns out to be inadequate to permit an > unambiguous interpretation (that issue spills over into my > second observation, below) Or its also brought to our attention that law and process is being violated by our methods per those works > . But, once other specifications > start to depend on the definitions that are there, and show > those definitions to be adequate, we should not be talking about > deprecating definitions unless we are prepared to "that was > wrong, we need to start over (even though some of the older > material may still be useful)". Again, please note the > similarity to the IPR work. AMEN! > > (2) If we pretend that the ABNF metalanguage and definitions are > actually a protocol specification, then we need to evaluate it > as one. Then, we have the following criteria (which we usually > don't state quite this precisely): > > (i) Is the definition good enough that interoperable > implementations are possible? > > (ii) Do people care enough about the construct to > actually use it in ways that show it is useful? > > Now, neither of those rules prevents non-conforming > "implementations". We may notice that those exist, but our > concern is only about implementations that appear to conform to > the spec and are (or are not) interoperable. If non-conforming > implementations happen by accident because the text isn't clear > enough, we try to clarify the text. But we don't say "well, > there are non-conforming implementations, so the spec is > broken". That would make no sense at all, at least to me. > > The answer to (i) appears to be "yes". There are lots of > conforming cases. And the answer to (ii) is, as Dave as pointed > out repeatedly, "about 30 years worth". > > Is this construction dangerous if used in inappropriate > contexts? Sure. Does that justify a warning note to the > unwary? Probably. Is it possible to implement other things and > call them by the same name (i.e., create a non-conforming > implementation)? Of course. Should that invalidate the > definition? Not if we want to have anything left if the > principle were applied broadly. > > john > > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf From discuss-bounces@apps.ietf.org Thu May 17 17:16:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HonKv-0005iZ-HR; Thu, 17 May 2007 17:16:37 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Holhu-0002q2-Ha for discuss-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 15:32:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Holhu-0002pq-7g for discuss@apps.ietf.org; Thu, 17 May 2007 15:32:14 -0400 Received: from dhcp-18-188-10-61.dyn.mit.edu ([18.188.10.61] helo=carter-zimmerman.suchdamage.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Holhr-00088m-V5 for discuss@apps.ietf.org; Thu, 17 May 2007 15:32:14 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8CF14400F; Thu, 17 May 2007 15:32:11 -0400 (EDT) From: Sam Hartman To: John C Klensin Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> <4649FB9A.9000107@bbiw.net> <1504A69099CF1B62F66FE576@p3.JCK.COM> Date: Thu, 17 May 2007 15:32:11 -0400 In-Reply-To: (John C. Klensin's message of "Thu, 17 May 2007 13:35:31 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-Mailman-Approved-At: Thu, 17 May 2007 17:16:34 -0400 Cc: ietf-dkim@mipassoc.org, Apps Discuss , Harald Alvestrand , Dave Crocker , Paul Overell , IETF General Discussion Mailing List X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >>>>> "John" == John C Klensin writes: John> If we are going to standardize a definitional requirement or John> method -- whether it is ABNF or IPR boilerplate or something John> -- we need to get it right as a self-contained definition John> and then live with it. We should certainly revise and John> replace it if it turns out to be unworkable (as has happened John> with IPR work) or if the definition turns out to be John> inadequate to permit an unambiguous interpretation (that John> issue spills over into my second observation, below). But, John> once other specifications start to depend on the definitions John> that are there, and show those definitions to be adequate, John> we should not be talking about deprecating definitions John> unless we are prepared to "that was wrong, we need to start John> over (even though some of the older material may still be John> useful)". Again, please note the similarity to the IPR John> work. Right. Here, I don't think the definition is wrong, I just think the term being defined is wrong. We proposed a definition for a useful concept. The word we chose (LWSP) stuck in some places but not in others. IN fact other people used the same word for a different although related concept. sufficiently so that the definition we proposed in ABNF is not the most common definition in our standards. Clearly we should not invalidate existing uses of that term. Clearly we do need a definition for the term: it is being used usefully. I think that in this instance, the value of future clarity justifies coming up with a new term that will unambiguously mean what LWSP means in ABNF today. That term will have to start at proposed standard. LWSP will need to continue in ABNF. I see a desire to document our operational experience with the word: many people took this word and used it to mean something else. Perhaps to avoid confusion you should consider whether your use of the word is a good idea. I think there is significant harm in choosing not to document this operational experience when advancing standards. After all, we both agree that it is this experience with running code that gives the IETF value. From discuss-bounces@apps.ietf.org Thu May 17 17:16:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HonKw-0005n0-Aa; Thu, 17 May 2007 17:16:38 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HoliP-00035I-RJ for discuss-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 15:32:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoliP-000354-HF for discuss@apps.ietf.org; Thu, 17 May 2007 15:32:45 -0400 Received: from [207.97.230.81] (helo=inbound.appriver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoliP-0008CQ-8I for discuss@apps.ietf.org; Thu, 17 May 2007 15:32:45 -0400 Received: by inbound.appriver.com (CommuniGate Pro PIPE 5.1.4) with PIPE id 25928; Thu, 17 May 2007 15:32:47 -0400 Received: from megatron.ietf.org ([156.154.16.145] verified) by inbound.appriver.com (CommuniGate Pro SMTP 5.1.4) with ESMTPS id 25891 for dsummers@marbaugh.com; Thu, 17 May 2007 15:32:45 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Holhv-0002q9-JW; Thu, 17 May 2007 15:32:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Holhu-0002pp-7d for ietf@ietf.org; Thu, 17 May 2007 15:32:14 -0400 Received: from dhcp-18-188-10-61.dyn.mit.edu ([18.188.10.61] helo=carter-zimmerman.suchdamage.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Holhr-00088n-V5 for ietf@ietf.org; Thu, 17 May 2007 15:32:14 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8CF14400F; Thu, 17 May 2007 15:32:11 -0400 (EDT) From: Sam Hartman To: John C Klensin References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> <4649FB9A.9000107@bbiw.net> <1504A69099CF1B62F66FE576@p3.JCK.COM> Date: Thu, 17 May 2007 15:32:11 -0400 In-Reply-To: (John C. Klensin's message of "Thu, 17 May 2007 13:35:31 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Policy: marbaugh.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->PRIVATE->LOCAL->UNITED STATES->UNITED STATES X-Note-Sending-IP: 156.154.16.145 X-Note-Reverse-DNS: megatron.ietf.ORG X-Note-WHTLIST: ietf-bounces@ietf.org X-Note: User Rule Hits: X-Note: Mail Class: VALID X-Mailman-Approved-At: Thu, 17 May 2007 17:16:34 -0400 Cc: IETF General Discussion Mailing List , Harald Alvestrand , Apps Discuss , Dave Crocker , Paul Overell , ietf-dkim@mipassoc.org X-BeenThere: discuss@apps.ietf.org List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org : X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 >>>>> "John" == John C Klensin writes: John> If we are going to standardize a definitional requirement or John> method -- whether it is ABNF or IPR boilerplate or something John> -- we need to get it right as a self-contained definition John> and then live with it. We should certainly revise and John> replace it if it turns out to be unworkable (as has happened John> with IPR work) or if the definition turns out to be John> inadequate to permit an unambiguous interpretation (that John> issue spills over into my second observation, below). But, John> once other specifications start to depend on the definitions John> that are there, and show those definitions to be adequate, John> we should not be talking about deprecating definitions John> unless we are prepared to "that was wrong, we need to start John> over (even though some of the older material may still be John> useful)". Again, please note the similarity to the IPR John> work. Right. Here, I don't think the definition is wrong, I just think the term being defined is wrong. We proposed a definition for a useful concept. The word we chose (LWSP) stuck in some places but not in others. IN fact other people used the same word for a different although related concept. sufficiently so that the definition we proposed in ABNF is not the most common definition in our standards. Clearly we should not invalidate existing uses of that term. Clearly we do need a definition for the term: it is being used usefully. I think that in this instance, the value of future clarity justifies coming up with a new term that will unambiguously mean what LWSP means in ABNF today. That term will have to start at proposed standard. LWSP will need to continue in ABNF. I see a desire to document our operational experience with the word: many people took this word and used it to mean something else. Perhaps to avoid confusion you should consider whether your use of the word is a good idea. I think there is significant harm in choosing not to document this operational experience when advancing standards. After all, we both agree that it is this experience with running code that gives the IETF value. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From discuss-bounces@apps.ietf.org Thu May 17 17:16:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HonKx-0005r7-0T; Thu, 17 May 2007 17:16:39 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hom7w-0004Uh-5p for discuss-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 15:59:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hom7v-0004TZ-HS for discuss@apps.ietf.org; Thu, 17 May 2007 15:59:07 -0400 Received: from server41a.appriver.com ([74.205.4.42] helo=inbound.appriver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hom7v-0003rR-0A for discuss@apps.ietf.org; Thu, 17 May 2007 15:59:07 -0400 Received: by inbound.appriver.com (CommuniGate Pro PIPE 5.1.4) with PIPE id 11777; Thu, 17 May 2007 15:56:08 -0400 Received: from [156.154.16.145] (HELO megatron.ietf.org) by inbound.appriver.com (CommuniGate Pro SMTP 5.1.4) with ESMTPS id 11704 for davez@pesystems.com; Thu, 17 May 2007 15:56:06 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Holhv-0002q9-PQ; Thu, 17 May 2007 15:32:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Holhu-0002pp-7d for ietf@ietf.org; Thu, 17 May 2007 15:32:14 -0400 Received: from dhcp-18-188-10-61.dyn.mit.edu ([18.188.10.61] helo=carter-zimmerman.suchdamage.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Holhr-00088n-V5 for ietf@ietf.org; Thu, 17 May 2007 15:32:14 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8CF14400F; Thu, 17 May 2007 15:32:11 -0400 (EDT) From: Sam Hartman To: John C Klensin References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> <4649FB9A.9000107@bbiw.net> <1504A69099CF1B62F66FE576@p3.JCK.COM> Date: Thu, 17 May 2007 15:32:11 -0400 In-Reply-To: (John C. Klensin's message of "Thu, 17 May 2007 13:35:31 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Policy: pesystems.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->PRIVATE->LOCAL->UNITED STATES->UNITED STATES X-Note-Sending-IP: 156.154.16.145 X-Note-Reverse-DNS: odin.ietf.ORG X-Note-WHTLIST: ietf-bounces@ietf.org X-Note: User Rule Hits: X-Note: Mail Class: VALID X-Mailman-Approved-At: Thu, 17 May 2007 17:16:34 -0400 Cc: IETF General Discussion Mailing List , Harald Alvestrand , Apps Discuss , Dave Crocker , Paul Overell , ietf-dkim@mipassoc.org X-BeenThere: discuss@apps.ietf.org List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org : X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 >>>>> "John" == John C Klensin writes: John> If we are going to standardize a definitional requirement or John> method -- whether it is ABNF or IPR boilerplate or something John> -- we need to get it right as a self-contained definition John> and then live with it. We should certainly revise and John> replace it if it turns out to be unworkable (as has happened John> with IPR work) or if the definition turns out to be John> inadequate to permit an unambiguous interpretation (that John> issue spills over into my second observation, below). But, John> once other specifications start to depend on the definitions John> that are there, and show those definitions to be adequate, John> we should not be talking about deprecating definitions John> unless we are prepared to "that was wrong, we need to start John> over (even though some of the older material may still be John> useful)". Again, please note the similarity to the IPR John> work. Right. Here, I don't think the definition is wrong, I just think the term being defined is wrong. We proposed a definition for a useful concept. The word we chose (LWSP) stuck in some places but not in others. IN fact other people used the same word for a different although related concept. sufficiently so that the definition we proposed in ABNF is not the most common definition in our standards. Clearly we should not invalidate existing uses of that term. Clearly we do need a definition for the term: it is being used usefully. I think that in this instance, the value of future clarity justifies coming up with a new term that will unambiguously mean what LWSP means in ABNF today. That term will have to start at proposed standard. LWSP will need to continue in ABNF. I see a desire to document our operational experience with the word: many people took this word and used it to mean something else. Perhaps to avoid confusion you should consider whether your use of the word is a good idea. I think there is significant harm in choosing not to document this operational experience when advancing standards. After all, we both agree that it is this experience with running code that gives the IETF value. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From discuss-bounces@apps.ietf.org Thu May 17 17:16:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HonKx-0005sc-8M; Thu, 17 May 2007 17:16:39 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HomQE-0003fh-RR for discuss-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 16:18:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HomQE-0003fT-Hc for discuss@apps.ietf.org; Thu, 17 May 2007 16:18:02 -0400 Received: from dhcp-18-188-10-61.dyn.mit.edu ([18.188.10.61] helo=carter-zimmerman.suchdamage.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HomQD-0006Ma-BP for discuss@apps.ietf.org; Thu, 17 May 2007 16:18:02 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id DF394400F; Thu, 17 May 2007 16:18:00 -0400 (EDT) From: Sam Hartman To: Harald Tveit Alvestrand Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> <4649FB9A.9000107@bbiw.net> <1504A69099CF1B62F66FE576@p3.JCK.COM> Date: Thu, 17 May 2007 16:18:00 -0400 In-Reply-To: (Harald Tveit Alvestrand's message of "Thu, 17 May 2007 21:52:45 +0200") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed X-Mailman-Approved-At: Thu, 17 May 2007 17:16:34 -0400 Cc: Apps Discuss , IETF General Discussion Mailing List , ietf-dkim@mipassoc.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Harald, I'm happy to accept your interpretation of the problem. However it also leads me to the conclusion that documenting possible reasons not to use ABNF's LWSP concept, or documenting implications of that rule would be a good idea. I also believe that documenting experience with a spec in future versions of that spec as it advances is reasonable. From discuss-bounces@apps.ietf.org Thu May 17 17:16:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HonKx-0005ud-O5; Thu, 17 May 2007 17:16:39 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HomQa-0003qe-U9 for discuss-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 16:18:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HomQa-0003qL-K6 for discuss@apps.ietf.org; Thu, 17 May 2007 16:18:24 -0400 Received: from [207.97.230.61] (helo=inbound.appriver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HomQZ-0006Tu-CH for discuss@apps.ietf.org; Thu, 17 May 2007 16:18:24 -0400 Received: by inbound.appriver.com (CommuniGate Pro PIPE 5.1.5) with PIPE id 28706; Thu, 17 May 2007 16:18:26 -0400 Received: from megatron.ietf.org ([156.154.16.145] verified) by inbound.appriver.com (CommuniGate Pro SMTP 5.1.5) with ESMTPS id 28665 for dsummers@marbaugh.com; Thu, 17 May 2007 16:18:25 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HomQG-0003ft-6M; Thu, 17 May 2007 16:18:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HomQE-0003fU-Ho for ietf@ietf.org; Thu, 17 May 2007 16:18:02 -0400 Received: from dhcp-18-188-10-61.dyn.mit.edu ([18.188.10.61] helo=carter-zimmerman.suchdamage.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HomQD-0006Mb-BN for ietf@ietf.org; Thu, 17 May 2007 16:18:02 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id DF394400F; Thu, 17 May 2007 16:18:00 -0400 (EDT) From: Sam Hartman To: Harald Tveit Alvestrand References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> <4649FB9A.9000107@bbiw.net> <1504A69099CF1B62F66FE576@p3.JCK.COM> Date: Thu, 17 May 2007 16:18:00 -0400 In-Reply-To: (Harald Tveit Alvestrand's message of "Thu, 17 May 2007 21:52:45 +0200") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Policy: marbaugh.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->PRIVATE->LOCAL->UNITED STATES->UNITED STATES X-Note-Sending-IP: 156.154.16.145 X-Note-Reverse-DNS: optimus.ietf.ORG X-Note-WHTLIST: ietf-bounces@ietf.org X-Note: User Rule Hits: X-Note: Mail Class: VALID X-Mailman-Approved-At: Thu, 17 May 2007 17:16:34 -0400 Cc: Apps Discuss , IETF General Discussion Mailing List , ietf-dkim@mipassoc.org X-BeenThere: discuss@apps.ietf.org List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org : X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Harald, I'm happy to accept your interpretation of the problem. However it also leads me to the conclusion that documenting possible reasons not to use ABNF's LWSP concept, or documenting implications of that rule would be a good idea. I also believe that documenting experience with a spec in future versions of that spec as it advances is reasonable. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From discuss-bounces@apps.ietf.org Thu May 17 17:28:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HonW3-0006bN-5w; Thu, 17 May 2007 17:28:07 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HonW1-0006bD-Og for discuss-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 17:28:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HonW1-0006b5-F4 for discuss@apps.ietf.org; Thu, 17 May 2007 17:28:05 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HonVy-0000v1-TA for discuss@apps.ietf.org; Thu, 17 May 2007 17:28:05 -0400 Received: from [10.200.96.163] ([216.168.240.140]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l4HLRpCH013775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 May 2007 14:27:52 -0700 Message-ID: <464CC8D3.2000700@dcrocker.net> Date: Thu, 17 May 2007 14:27:47 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Sam Hartman Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> <4649FB9A.9000107@bbiw.net> <1504A69099CF1B62F66FE576@p3.JCK.COM> <464C8822.7020503@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Apps Discuss , Paul Overell , IETF General Discussion Mailing List , ietf-dkim@mipassoc.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Sam Hartman wrote: > >> Ultimately cases like this should be evaluated based on whether > >> the final result is more clear overall. > > Dave> What about protecting the installed base for the existing > Dave> spec? > > I think that is not a useful criteria when we are talking about an > informative note. I think that criteria matters somewhat more when we > are talking about depricating a feature but retaining it, although > even then I think the bar would be reasonably low. The installed base > will continue to work. I think you are assuming a more constrained discussion than what I've been seeing on this thread. The thread has discussed everything from removing the rule, to redefining it, to declaring it "deprecated", to adding some commentary text. It appears you are only talking about the last, although I for one missed that. (For reference, when I said "change the specification" I mean normative change.) Although I've seen some postings against even having a comment added to the text, my own reading of the postings is that there is a reasonable consensus that it would be ok. My own view is that comments can be helpful and are, at worst, typically rather benign. Indeed, the IETF approach towards specification writing is rather friendly towards including whatever comments folk feel might be helpful, modulo the obvious danger that too many comments can wind up obscuring a document. (And, no, I do not think that that is a danger here.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From discuss-bounces@apps.ietf.org Thu May 17 19:38:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HopY9-0007wO-JV; Thu, 17 May 2007 19:38:25 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HopY8-0007wD-7I for discuss-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 19:38:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HopY7-0007w5-Tp for discuss@apps.ietf.org; Thu, 17 May 2007 19:38:23 -0400 Received: from ppsw-7.csi.cam.ac.uk ([131.111.8.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HopY3-0006hb-Gt for discuss@apps.ietf.org; Thu, 17 May 2007 19:38:23 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:35757) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1HopXz-0006P3-Om (Exim 4.63) (return-path ); Fri, 18 May 2007 00:38:15 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1HopXz-0006tK-L2 (Exim 4.54) (return-path ); Fri, 18 May 2007 00:38:15 +0100 Date: Fri, 18 May 2007 00:38:15 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: John C Klensin Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call In-Reply-To: Message-ID: References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> <4649FB9A.9000107@bbiw.net> <1504A69099CF1B62F66FE576@p3.JCK.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ietf-dkim@mipassoc.org, Apps Discuss , Paul Overell , IETF General Discussion Mailing List , Dave Crocker X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Thu, 17 May 2007, John C Klensin wrote: > > (1) Other specifications that use the term "LWSP" to > refer to something different from what is unambiguously > defined in the ABNF spec. > > [This] group is, IMO, just broken. I agree with your sentiment but sadly there's a lot of old stuff that's broken by this criterion. RFC 733 defined to mean what RFC 2234 calls , and to mean what is now . Fortunately these old definitions have fallen out of use. There's also HTTP and SIP which call the problematic production instead of . MEGACO uses ABNF with its own terminal definitions instead of referring to ABNF appendix B. CGI uses its own ABNF variant. It would be nice if the progression of ABNF to a full standard reduces this Babel. This implies that (a) ABNF should be used to describe syntax in preference to any other BNF-alike, to avoid anomalies like CGI; (b) specifications should not define a production with the same name as one in appendix B but with a different expansion, to avoid anomalies like MEGACO; (c) specifications should not define a production with the same expansion as one in appendix B but with a different name, to avoid anomalies like HTTP and SIP; (d) any production like LWSP should be discouraged because of problems with lossage related to trailing whitespace. Tony. -- f.a.n.finch http://dotat.at/ ROCKALL: SOUTHWEST 6 TO GALE 8, INCREASING SEVERE GALE 9, PERHAPS STORM 10 LATER. VERY ROUGH OR HIGH. SHOWERS. GOOD. From discuss-bounces@apps.ietf.org Thu May 17 21:14:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hor34-0007Ai-D1; Thu, 17 May 2007 21:14:26 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hor33-0007AY-H0 for discuss-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 21:14:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hor33-0007AQ-7I for discuss@apps.ietf.org; Thu, 17 May 2007 21:14:25 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hor31-0006PZ-T3 for discuss@apps.ietf.org; Thu, 17 May 2007 21:14:25 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Hor30-000Bq7-Cg; Thu, 17 May 2007 21:14:22 -0400 Date: Thu, 17 May 2007 21:14:21 -0400 From: John C Klensin To: Harald Tveit Alvestrand , Sam Hartman Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call Message-ID: <4512BF1B1B2C8C4A9487E733@p3.JCK.COM> In-Reply-To: References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> <4649FB9A.9000107@bbiw.net> <1504A69099CF1B62F66FE576@p3.JCK.COM> 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-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Apps Discuss , IETF General Discussion Mailing List , ietf-dkim@mipassoc.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --On Thursday, 17 May, 2007 21:52 +0200 Harald Tveit Alvestrand wrote: > I don't agree with the meaning I get from this statement. The > problem is that the construct that ABNF calls "LWSP" causes > problems in protocols that use it. > This problem is independent of the name of the construct; the > problem is in defining a grammar where the sequence > has a different meaning than . >... Interesting. I don't think that is a problem with the grammar, and think it would be rather hard to define a grammar that would not permit that situation. After all Thing could case similar problems if some construction permitted it and defining a grammar that would prohibit any construction isn't easy in ABNF for reasons that have nothing to do with LWSP. Instead, I see the problem as using the grammar to define situations equivalent to LWSP [ optional-stuff ] CRLF as compared to LWSP AtLeastOneRequiredThing CRLF or [ LWSP optional-stuff ] CRLF I don't see either of the latter as problematic. john From discuss-bounces@apps.ietf.org Thu May 17 21:36:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HorNy-0006JG-Kb; Thu, 17 May 2007 21:36:02 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HorNx-0006J5-TI for discuss-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 21:36:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HorNx-0006Is-JZ for discuss@apps.ietf.org; Thu, 17 May 2007 21:36:01 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HorNw-0004Tn-8y for discuss@apps.ietf.org; Thu, 17 May 2007 21:36:01 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 2A1791EE1E5; Thu, 17 May 2007 21:35:59 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2sahLWcl+Gm; Thu, 17 May 2007 21:35:52 -0400 (EDT) Received: from lust.indecency.org (dialup-4.154.53.75.Dial1.Atlanta1.Level3.net [4.154.53.75]) by shu.cs.utk.edu (Postfix) with ESMTP id 70B521EE1D9; Thu, 17 May 2007 21:35:49 -0400 (EDT) Message-ID: <464D02EF.6070607@cs.utk.edu> Date: Thu, 17 May 2007 21:35:43 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Sam Hartman Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> <4649FB9A.9000107@bbiw.net> <1504A69099CF1B62F66FE576@p3.JCK.COM> <464C8822.7020503@dcrocker.net> <464CC8D3.2000700@dcrocker.net> In-Reply-To: X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ietf-dkim@mipassoc.org, Apps Discuss , IETF General Discussion Mailing List , dcrocker@bbiw.net, Paul Overell X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org it could be argued that the best thing to do is to remove ALL of the rules from the ABNF spec, leaving only the language definition and examples. (actually I think I did argue this sometime around 1996, but I'm too lazy to search through old email to find it. I'm actually surprised that a problem with one of those definitions has taken this long to crop up.) the rules could then be moved to a separate document, probably with status informational. I don't personally see any problem with an informational document being used to define terms that are referenced in standards track publications - so long as the document being referenced is not subject to change. the referencing document should be evaluated as if the definitions were incorporated into that document. IMHO, sometimes we try too hard to make things fit into the standards track. application of the proposed/draft/full criteria to ABNF has always been a bit odd, because ABNF defines a notation rather than a protocol. at one time we thought about evaluating interoperability of ABNF by seeing if there were multiple implementations (i.e. parser generators) that when given the same grammar, recognized the same language. but this would be kind of meaningless given that ABNF is (in my experience) almost never used as input to a parser generator for the purpose of generating a protocol implementation. which might be quite unfortunate. > I think redefining the rule would require recycling at proposed. I > think it would be confusing and harmful to do so. > > I think removing the rule would is allowed by the process (and would > require updates in referencing specs as they advance but would not > break anything). I think doing so would be harmful and is not > supported by consensus. > > I do not object to deprecating the rule although I'm not completely > convinced doing so is a great idea.I think it is clearly allowed if > there is consensus. > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > From discuss-bounces@apps.ietf.org Thu May 17 22:39:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HosNg-0000fe-9f; Thu, 17 May 2007 22:39:48 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HosNe-0000fO-Bc for discuss-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 22:39:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HosNe-0000fE-1W for discuss@apps.ietf.org; Thu, 17 May 2007 22:39:46 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HosNc-0003gv-LJ for discuss@apps.ietf.org; Thu, 17 May 2007 22:39:46 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HosNa-0000GA-OL for discuss@apps.ietf.org; Fri, 18 May 2007 04:39:42 +0200 Received: from 1cust45.tnt5.hbg2.deu.da.uu.net ([149.225.16.45]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 18 May 2007 04:39:42 +0200 Received: from nobody by 1cust45.tnt5.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 18 May 2007 04:39:42 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: discuss@apps.ietf.org From: Frank Ellermann Subject: Re: Use of LWSP in ABNF -- consensus call Date: Fri, 18 May 2007 04:35:59 +0200 Organization: Lines: 23 Message-ID: <464D110F.7C17@xyzzy.claranet.de> References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> <4649FB9A.9000107@bbiw.net> <1504A69099CF1B62F66FE576@p3.JCK.COM> <4512BF1B1B2C8C4A9487E733@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust45.tnt5.hbg2.deu.da.uu.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.2 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ietf@ietf.org, ietf-dkim@mipassoc.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org John C Klensin wrote: > LWSP AtLeastOneRequiredThing CRLF > or > [ LWSP optional-stuff ] CRLF > I don't see either of the latter as problematic. Depends on the protocol. Your constructs match SP CRLF SP CRLF SP AtLeastOneRequiredThing CRLF SP CRLF SP CRLF SP optional-stuff CRLF .........^^^^^^^^^^^^ If you do this e.g. in a mail or HHTP header, where CRLF CRLF means "end of header", then any tool like a text editor or other UA trying to reuse the header field "as is" while silently removing trailing white space would end up with CRLF CRLF SP AtLeastOneRequiredThing CRLF CRLF CRLF SP optional-stuff CRLF ......^^^^^^^^^ Frank From discuss-bounces@apps.ietf.org Fri May 18 04:00:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoxOL-00056y-F9; Fri, 18 May 2007 04:00:49 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HoxOK-00056o-Le for discuss-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 04:00:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoxOK-00056g-7W for discuss@apps.ietf.org; Fri, 18 May 2007 04:00:48 -0400 Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoxOI-00018N-U9 for discuss@apps.ietf.org; Fri, 18 May 2007 04:00:48 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:35736) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1HoxOF-0005ws-1I (Exim 4.63) (return-path ); Fri, 18 May 2007 09:00:43 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1HoxOF-000169-By (Exim 4.54) (return-path ); Fri, 18 May 2007 09:00:43 +0100 Date: Fri, 18 May 2007 09:00:43 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: John C Klensin Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call In-Reply-To: <4512BF1B1B2C8C4A9487E733@p3.JCK.COM> Message-ID: References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> <4649FB9A.9000107@bbiw.net> <1504A69099CF1B62F66FE576@p3.JCK.COM> <4512BF1B1B2C8C4A9487E733@p3.JCK.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Apps Discuss , IETF General Discussion Mailing List , ietf-dkim@mipassoc.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Thu, 17 May 2007, John C Klensin wrote: > > After all Thing could case similar problems if > some construction permitted it ... This is not news. There have for a long time been problems with significant trailing space, which is why CRLF 1*WSP CRLF in a header is part of the obs- syntax of 2822, and why quoted-printable encodes WSP at the end of a line. > ... and defining a grammar that would prohibit any > construction isn't easy in ABNF for reasons that have nothing to > do with LWSP. This is simply incorrect. It's trivial to define a whitespace construction that only allows CRLF at the beginning of a sequence: NTWSP = [CRLF] 1*WSP ; non-trailing white space Tony. -- f.a.n.finch http://dotat.at/ SHANNON: SOUTHWEST VEERING WEST 7 TO SEVERE GALE 9, PERHAPS STORM 10 LATER. VERY ROUGH OR HIGH. RAIN OR SQUALLY SHOWERS. MODERATE OR GOOD. From discuss-bounces@apps.ietf.org Fri May 18 09:47:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp2nU-0007Ma-Gb; Fri, 18 May 2007 09:47:08 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hp2nS-0007H3-Tf for discuss-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 09:47:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp2nS-0007G0-9l for discuss@apps.ietf.org; Fri, 18 May 2007 09:47:06 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp2nQ-00087o-4N for discuss@apps.ietf.org; Fri, 18 May 2007 09:47:05 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4CB104011; Thu, 17 May 2007 17:36:08 -0400 (EDT) From: Sam Hartman To: dcrocker@bbiw.net Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> <4649FB9A.9000107@bbiw.net> <1504A69099CF1B62F66FE576@p3.JCK.COM> <464C8822.7020503@dcrocker.net> <464CC8D3.2000700@dcrocker.net> Date: Thu, 17 May 2007 17:36:08 -0400 In-Reply-To: <464CC8D3.2000700@dcrocker.net> (Dave Crocker's message of "Thu, 17 May 2007 14:27:47 -0700") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Apps Discuss , Paul Overell , IETF General Discussion Mailing List , ietf-dkim@mipassoc.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org I think redefining the rule would require recycling at proposed. I think it would be confusing and harmful to do so. I think removing the rule would is allowed by the process (and would require updates in referencing specs as they advance but would not break anything). I think doing so would be harmful and is not supported by consensus. I do not object to deprecating the rule although I'm not completely convinced doing so is a great idea.I think it is clearly allowed if there is consensus. From discuss-bounces@apps.ietf.org Fri May 18 09:47:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp2nU-0007LW-Ag; Fri, 18 May 2007 09:47:08 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hp2nS-0007H5-U1 for discuss-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 09:47:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp2nS-0007G3-A4 for discuss@apps.ietf.org; Fri, 18 May 2007 09:47:06 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp2nQ-00087p-4T for discuss@apps.ietf.org; Fri, 18 May 2007 09:47:05 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E0307400F; Thu, 17 May 2007 17:16:12 -0400 (EDT) From: Sam Hartman To: dcrocker@bbiw.net Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> <4649FB9A.9000107@bbiw.net> <1504A69099CF1B62F66FE576@p3.JCK.COM> <464C8822.7020503@dcrocker.net> Date: Thu, 17 May 2007 17:16:12 -0400 In-Reply-To: <464C8822.7020503@dcrocker.net> (Dave Crocker's message of "Thu, 17 May 2007 09:51:46 -0700") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Apps Discuss , Paul Overell , IETF General Discussion Mailing List , ietf-dkim@mipassoc.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >>>>> "Dave" == Dave Crocker writes: Dave> Sam, >> Ultimately cases like this should be evaluated based on whether >> the final result is more clear overall. Dave> What about protecting the installed base for the existing Dave> spec? I think that is not a useful criteria when we are talking about an informative note. I think that criteria matters somewhat more when we are talking about depricating a feature but retaining it, although even then I think the bar would be reasonably low. The installed base will continue to work. I think that criterian is very important if we were talking about removing a rule. For that reason I do not favor removing the LWSP rule. From discuss-bounces@apps.ietf.org Fri May 18 10:03:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp33U-0003z5-2k; Fri, 18 May 2007 10:03:40 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hp33T-0003ys-10 for discuss-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 10:03:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp33S-0003yk-Nb for discuss@apps.ietf.org; Fri, 18 May 2007 10:03:38 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp33Q-00023t-BY for discuss@apps.ietf.org; Fri, 18 May 2007 10:03:38 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Hp33M-000IqQ-50; Fri, 18 May 2007 10:03:32 -0400 Date: Fri, 18 May 2007 10:03:31 -0400 From: John C Klensin To: Tony Finch Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call Message-ID: <4EB341F4BEA39A01B2F9C84D@p3.JCK.COM> In-Reply-To: References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> <4649FB9A.9000107@bbiw.net> <1504A69099CF1B62F66FE576@p3.JCK.COM> <4512BF1B1B2C8C4A9487E733@p3.JCK.COM> 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-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Apps Discuss , IETF General Discussion Mailing List , ietf-dkim@mipassoc.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --On Friday, 18 May, 2007 09:00 +0100 Tony Finch wrote: > On Thu, 17 May 2007, John C Klensin wrote: >> >> After all Thing could case similar >> problems if some construction permitted it ... > > This is not news. There have for a long time been problems with > significant trailing space, which is why CRLF 1*WSP CRLF in a > header is part of the obs- syntax of 2822, and why > quoted-printable encodes WSP at the end of a line. > >> ... and defining a grammar that would prohibit any >> construction isn't easy in ABNF for reasons >> that have nothing to do with LWSP. > > This is simply incorrect. It's trivial to define a whitespace > construction that only allows CRLF at the beginning of a > sequence: > > NTWSP = [CRLF] 1*WSP ; non-trailing white space Sure. Except that much, if not most, of our textual descriptions of these protocols describes lines, and line-like, constructions as _ending_ in CRLF. Moving to "starting in CRLF" creates a conceptual difference between prose definition and formal syntax, which strikes me as a bad idea. Of course, in the above, since [CRLF] is optional, "1*WSP" alone satisfies the production as written and still does not prevent space space space unless _all_ productions are written CRLF first... or one relies on the comment as a restriction. And a comment as the restriction --in the prose-- is exactly what has been suggested, IMO. john From discuss-bounces@apps.ietf.org Fri May 18 10:23:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp3MT-0006we-8M; Fri, 18 May 2007 10:23:17 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hp3MS-0006wZ-SD for discuss-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 10:23:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp3MS-0006wR-IZ for discuss@apps.ietf.org; Fri, 18 May 2007 10:23:16 -0400 Received: from ppsw-7.csi.cam.ac.uk ([131.111.8.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp3MQ-0004HI-5m for discuss@apps.ietf.org; Fri, 18 May 2007 10:23:16 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:50580) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1Hp3MO-0003io-Mj (Exim 4.63) (return-path ); Fri, 18 May 2007 15:23:12 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Hp3MO-0001Ul-0e (Exim 4.54) (return-path ); Fri, 18 May 2007 15:23:12 +0100 Date: Fri, 18 May 2007 15:23:12 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: John C Klensin Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call In-Reply-To: <4EB341F4BEA39A01B2F9C84D@p3.JCK.COM> Message-ID: References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> <4649FB9A.9000107@bbiw.net> <1504A69099CF1B62F66FE576@p3.JCK.COM> <4512BF1B1B2C8C4A9487E733@p3.JCK.COM> <4EB341F4BEA39A01B2F9C84D@p3.JCK.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Apps Discuss , IETF General Discussion Mailing List , ietf-dkim@mipassoc.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Fri, 18 May 2007, John C Klensin wrote: > On Friday, 18 May, 2007 09:00 +0100 Tony Finch > wrote: > > > > NTWSP = [CRLF] 1*WSP ; non-trailing white space > > Sure. Except that much, if not most, of our textual > descriptions of these protocols describes lines, and line-like, > constructions as _ending_ in CRLF. Moving to "starting in > CRLF" creates a conceptual difference between prose definition > and formal syntax, which strikes me as a bad idea. Don't do that then. The suggestion I made above was for a no-trailing- whitespace variant of 2822's FWS, and as such it would be used in a grammar inside a logical line, not at either end. You seem to be inventing problems that might occur in badly-designed grammars, and as such these are bugs in the grammars and not due to limitations of ABNF (which, after all, is equivalent to any other notation for describing context-free grammars). > Of course, in the above, since [CRLF] is optional, "1*WSP" alone > satisfies the production as written and still does not prevent > space space space > Um, no, because WSP = SP / HTAB Tony. -- f.a.n.finch http://dotat.at/ SOUTHEAST ICELAND: CYCLONIC, BECOMING NORTHERLY GALE 8 OR SEVERE GALE 9, DECREASING 6 OR 7. ROUGH OR VERY ROUGH, OCCASIONALLY HIGH. SHOWERS. MODERATE OR GOOD. From discuss-bounces@apps.ietf.org Fri May 18 10:59:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp3vv-0004eT-3k; Fri, 18 May 2007 10:59:55 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hp3vt-0004eI-Ma for discuss-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 10:59:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp3vt-0004e5-CE for discuss@apps.ietf.org; Fri, 18 May 2007 10:59:53 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp3vs-0002wn-3r for discuss@apps.ietf.org; Fri, 18 May 2007 10:59:53 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 74AFC400F; Fri, 18 May 2007 10:59:51 -0400 (EDT) From: Sam Hartman To: Keith Moore Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call References: <4648E8CB.3010502@dcrocker.net> <4649FA12.30909@alvestrand.no> <4649FB9A.9000107@bbiw.net> <1504A69099CF1B62F66FE576@p3.JCK.COM> <464C8822.7020503@dcrocker.net> <464CC8D3.2000700@dcrocker.net> <464D02EF.6070607@cs.utk.edu> Date: Fri, 18 May 2007 10:59:51 -0400 In-Reply-To: <464D02EF.6070607@cs.utk.edu> (Keith Moore's message of "Thu, 17 May 2007 21:35:43 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ietf-dkim@mipassoc.org, Apps Discuss , IETF General Discussion Mailing List , dcrocker@bbiw.net, Paul Overell X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >>>>> "Keith" == Keith Moore writes: Keith> it could be argued that the best thing to do is to remove Keith> ALL of the rules from the ABNF spec, leaving only the Keith> language definition and examples. (actually I think I did Keith> argue this sometime around 1996, but I'm too lazy to search Keith> through old email to find it. I think this would be too big of a change going from draft to full given our experience. If we had huge tracts of problems with the rules, it might be a different situation. From discuss-bounces@apps.ietf.org Fri May 18 19:55:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpCIW-0005x2-Ks; Fri, 18 May 2007 19:55:48 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HpCIV-0005ww-J2 for discuss-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 19:55:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpCIV-0005wh-9A for discuss@apps.ietf.org; Fri, 18 May 2007 19:55:47 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HpCIT-0007Pp-Qf for discuss@apps.ietf.org; Fri, 18 May 2007 19:55:47 -0400 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CE56D142207; Fri, 18 May 2007 16:55:44 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBxnCOVdyC8K; Fri, 18 May 2007 16:55:43 -0700 (PDT) Received: from [192.168.1.101] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 46EF7142206; Fri, 18 May 2007 16:55:40 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) To: HTTP Working Group , Message Notifications interest group discussion list , morg@ietf.org, wax@ietf.org, Apps Discuss , HTTP authentication list Message-Id: Content-Type: multipart/alternative; boundary=Apple-Mail-8--638126391 From: Lisa Dusseault Subject: BOF request deadline Monday Date: Fri, 18 May 2007 16:55:36 -0700 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-8--638126391 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I've noticed some confusion around the deadlines for requesting BOFs and checked the dates myself. The cutoff date for "preliminary BOF proposals" is May 21. Between May 21 and June 11 the IESG and IAB discuss those proposals (we have a call scheduled May 29), and by June 11 we have *our* cutoff for scheduling a BOF that we've decided to put on the schedule. So we're supposed to know *something* about proposed BOFs by Monday, and have more details filled in by May 29. Hope this reaches people in time, Lisa On Apr 25, 2007, at 10:10 PM, Mark wrote: > > See ; the hard > cutoff for scheduling a BoF is June 11. > --Apple-Mail-8--638126391 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

I've noticed some confusion = around the deadlines for requesting BOFs and checked the dates myself.=A0 = =A0The cutoff date for "preliminary BOF proposals"=A0 is May 21.=A0 = Between May 21 and June 11 the IESG and IAB discuss those proposals (we = have a call scheduled May 29), and by June 11 we have *our* cutoff for = scheduling a BOF that we've decided to put on the schedule.=A0 So we're = supposed to know *something* about proposed BOFs by Monday, and have = more details filled in by May 29.

Hope this reaches people in = time,
Lisa

On Apr 25, 2007, at 10:10 PM, = Mark wrote:

See <http://www.ietf= .org/meetings/69-cutoff_dates.html>; the hard cutoff for = scheduling a BoF is June 11.




= --Apple-Mail-8--638126391-- From discuss-bounces@apps.ietf.org Sun May 20 18:57:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpuL3-0006Qw-Iv; Sun, 20 May 2007 18:57:21 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HpuL1-0006Qj-Q6 for discuss-confirm+ok@megatron.ietf.org; Sun, 20 May 2007 18:57:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpuKz-0006Qb-Mp for discuss@apps.ietf.org; Sun, 20 May 2007 18:57:18 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HpuKz-0004v3-9W for discuss@apps.ietf.org; Sun, 20 May 2007 18:57:17 -0400 Received: from fe-amer-10.sun.com ([192.18.108.184]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4KMvGK4010630 for ; Sun, 20 May 2007 22:57:16 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JID00M013OH2E00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for discuss@apps.ietf.org; Sun, 20 May 2007 16:57:16 -0600 (MDT) Received: from [10.0.1.21] (216-165-236-126.championbroadband.com [216.165.236.126]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JID00D933RD4H00@mail-amer.sun.com>; Sun, 20 May 2007 16:57:16 -0600 (MDT) Date: Sun, 20 May 2007 15:57:10 -0700 From: Chris Newman Subject: vCard and CardDAV strawman Charter To: discuss@apps.ietf.org Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: Cyrus Daboo X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Given the upcoming BOF deadline, I wanted to get this proposal circulating now. I've had several people contact me interested in work on vCard and CardDAV. So I'm contemplating a BOF on the topic at the Chicago IETF. I'm interested in volunteers for the following roles: 1. BOF chair / co-chair (responsible for charter editing and running a BOF) 2. WG chair / co-chair (responsible for running the WG) 3. vCard revision document editor Volunteers for 1 & 2 may be the same or different people. A BOF will not happen unless I get volunteers to do the work. I've written a first strawman for the charter to get discussion going (very much subject to change). - Chris Newman Applications Area Director --- vCard and CardDAV strawman charter (vcarddav) A personal address book (PAB) contains a read/write copy of attributes describing a user's interpersonal contacts. This is distinct from a directory which contains a primarily read-only copy of users within an organization. While these two data objects share a large number of common attributes, their use and access patterns are fundamentally different. The IETF has a standards-track data format (vCard) which has been successfully used to interchange both personal-address-book and user directory entry data objects. However, due to the lack of a standard access control model for LDAP, the lack of a standard LDAP schema and DIT-model for vCard PAB objects, and the different access patterns for PAB data (as opposed to directory data), the use of LDAP as an access protocol for PABs has had mixed results in practice. If the deployed protocols related to interpersonal communication are viewed as a component-based system, there are a number of points in the system that would benefit from a standards track access protocol for personal address book data. This includes: * Mail User Agents use PAB data to assist outgoing email addressing and may use vCard attachments to transport PAB data between users. * Calendar User Agents use PAB data to invite attendees to events * Instant Messaging User Agents can provide additional information about a user's buddies if they can be associated with a user's PAB entry. * A server-side Sieve engine with the spamtest/virustest extension would benefit from access to a user's PAB to provide per-user white list capabilities. * Various deployed challenge-response mechanisms for email present in Mail Transfer Agents, such as TMDA, would be improved by a PAB-based white list. * Mobile device synchronization software might be simplified by a single cross-platform PAB access protocol. * A voice conference or IP telephony system could access a user's PAB to provide name-based or nickname-based dialing. This WG will produce the following two primary outputs: * A revision of the vCard spec (RFC 2426) likely at proposed standard status. The WG will attempt to avoid adding new features, with two exceptions: 1. The WG may consider including other proposed standard vCard extensions (e.g., RFC 4770, RFC 2739). 2. The WG may evaluate extensions that would assist synchronization technologies (for example, a per-entry UUID or per-attribute sequence number). * An address book access protocol leveraging the vCard data format. The Internet-draft draft-daboo-carddav will be the starting point. The WG is explicitly cautioned to keep the base specification feature set small with an adequate extension mechanism, as failure to do so was a problem for previous PAB efforts (ACAP). The WG will consider arguments of the form "feature X must be in the base feature set because ..." with great skepticism. These documents will consider security implications carefully. The WG will consider developing a mechanism that provides the ability to check if an email address (or im address, etc) is in the user's PAB without providing unrestricted access to all of the user's PAB data. The WG should also consider developing a mechanism that allows the user to grant this limited permission to a third-party service (such as a server-based Sieve engine) for white-list purposes. Once the primary outputs are complete, the WG may consider the following secondary outputs: * An XML schema which is semantically identical to vCard in all ways and can be mechanically translated to and from vCard format without loss of data. While vCard has deployed successfully and will remain the preferred interchange format, a standard XML schema which preserves vCard semantics might make vCard data more accessible to XML-centric technologies such as AJAX and XSLT. Such a standard format would be preferable to multiple proprietary XML schemas, particularly if vCard semantics were lost by some of them and a lossy gateway problem resulted. * Identifying useful deployed vCard vendor extensions and creating standards track versions of those extensions. * Cooperate with the Sieve WG to produce a Sieve extension for address book Sieve tests. ----- From discuss-bounces@apps.ietf.org Mon May 21 20:48:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqIYG-0002bK-3E; Mon, 21 May 2007 20:48:36 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HqIYE-0002bE-Ts for discuss-confirm+ok@megatron.ietf.org; Mon, 21 May 2007 20:48:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqIYE-0002b1-K4 for discuss@apps.ietf.org; Mon, 21 May 2007 20:48:34 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqIY2-0000so-Qv for discuss@apps.ietf.org; Mon, 21 May 2007 20:48:34 -0400 Received: from [192.168.0.4] (adsl-68-122-34-133.dsl.pltn13.pacbell.net [68.122.34.133]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l4M0lsLe009562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 21 May 2007 17:47:55 -0700 Message-ID: <46523D89.70905@dcrocker.net> Date: Mon, 21 May 2007 17:47:05 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: discuss@apps.ietf.org Subject: Seeking clarification of ABNF "name formation" reference Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Folks, In the ABNF document, there is a precedence chart: >
> > The various mechanisms described above have the following > precedence, from highest (binding tightest) at the top, to > lowest (loosest) at the bottom: > > Strings, Names formation > Comment > Value range > Repetition > Grouping, Optional > Concatenation > Alternative > > > The reference to "Name formation" has been in this form since RFC 2234. Oddly, we can't figure out what it is supposed to mean, exactly. We could make some guesses, but I'd rather check with the group. Comments? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From discuss-bounces@apps.ietf.org Tue May 22 02:29:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqNsX-00077o-3f; Tue, 22 May 2007 02:29:53 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HqNsW-00077f-A6 for discuss-confirm+ok@megatron.ietf.org; Tue, 22 May 2007 02:29:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqNsV-00077T-TI for discuss@apps.ietf.org; Tue, 22 May 2007 02:29:51 -0400 Received: from tls.sendmail.com ([209.246.26.40] helo=foon.sendmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqNsT-0007WU-Gq for discuss@apps.ietf.org; Tue, 22 May 2007 02:29:51 -0400 Received: from [10.201.0.47] (adsl-64-58-1-252.mho.net [64.58.1.252] (may be forged)) (authenticated bits=0) by foon.sendmail.com (Switch-3.2.5/Switch-3.2.0) with ESMTP id l4M6WQbd024771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 May 2007 23:32:28 -0700 X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com l4M6WQbd024771 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1179815550; bh=aoLPjSxZAS8yaXcUDDYcGiv8h80=; h=X-DomainKeys: DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type; b=VgoaTjb987BN9PJ/ Zj31faYDVclkf46Z/2qFRKnlX677z6VffiNR3fCToK3uEihJCZ4j4BAKl3IoSqi+yVK EDSPIJN1Nv6uiRYYRb4FzGoXLU3nBpPCTkhXAOcHFGSt/dizH8HoFHqCLMNMn+akutv oKxZeTuqh+K3iLbgHKJ4A= X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com l4M6WQbd024771 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=fTIaoxJ3ngckJzy/g9wCK7DMmBIr5Q5Ra9g2wBSqI7U24PnN4VwTrK5B6mlD4YXws eGJN09yqSKN5neuxAtGtRB8dpxh6G/JQvXu0/3wrupCD0L0ODu4r5HEIRSI2OpgzE+Y oWacAH3hKMeBAcOZn5n07OCBrsz+wedR1O7KYFg= Date: Tue, 22 May 2007 00:29:38 -0600 From: Philip Guenther X-X-Sender: guenther@skarrin.mho.net To: dcrocker@bbiw.net Subject: Re: Seeking clarification of ABNF "name formation" reference In-Reply-To: <46523D89.70905@dcrocker.net> Message-ID: References: <46523D89.70905@dcrocker.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Mon, 21 May 2007, Dave Crocker wrote: > In the ABNF document, there is a precedence chart: > >>
>> >> The various mechanisms described above have the following >> precedence, from highest (binding tightest) at the top, to >> lowest (loosest) at the bottom: >> >> Strings, Names formation >> Comment ... >> >> > > > The reference to "Name formation" has been in this form since RFC 2234. > > Oddly, we can't figure out what it is supposed to mean, exactly. > > We could make some guesses, but I'd rather check with the group. My guess was that it's a reference to the 'prose' value form, ala: tag = 1* Inside the angle-brackets, only close-angle-bracket is special, just as inside a string, only double-quote is special, so those forms have a higher precedence than comment (semicolon isn't special) and repetition (asterisk isn't special), and... So then I looked at the RFC and discovered that the prose value form is *only* mentioned in the ABNF definition of ABNF! Was its prose description misplaced and accidentally used to shim a wobbly table? If so, that would explain the dangling reference. Philip Guenther From discuss-bounces@apps.ietf.org Tue May 22 06:23:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqRWx-00080g-EG; Tue, 22 May 2007 06:23:51 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HqRWw-00080b-Cl for discuss-confirm+ok@megatron.ietf.org; Tue, 22 May 2007 06:23:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqRWv-00080T-Ue for discuss@apps.ietf.org; Tue, 22 May 2007 06:23:50 -0400 Received: from ppsw-3.csi.cam.ac.uk ([131.111.8.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqRWr-00011R-Lc for discuss@apps.ietf.org; Tue, 22 May 2007 06:23:49 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:43180) by ppsw-3.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.153]:25) with esmtpa (EXTERNAL:fanf2) id 1HqRWc-0001se-BC (Exim 4.63) (return-path ); Tue, 22 May 2007 11:23:30 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1HqRWc-0000tN-EK (Exim 4.54) (return-path ); Tue, 22 May 2007 11:23:30 +0100 Date: Tue, 22 May 2007 11:23:30 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: dcrocker@bbiw.net Subject: Re: Seeking clarification of ABNF "name formation" reference In-Reply-To: <46523D89.70905@dcrocker.net> Message-ID: References: <46523D89.70905@dcrocker.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Mon, 21 May 2007, Dave Crocker wrote: > > The reference to "Name formation" has been in this form since RFC 2234. > Oddly, we can't figure out what it is supposed to mean, exactly. > We could make some guesses, but I'd rather check with the group. I guess that "strings" means any terminal value, including % numeric character specifiers even though it usually means only quoted strings. I guess that "names formation" (sic) refers to rule names. Tony. -- f.a.n.finch http://dotat.at/ SOUTHEAST ICELAND: SOUTHWEST VEERING WEST 5 OR 6 INCREASING 7 TO SEVERE GALE 9. ROUGH INCREASING VERY ROUGH OR HIGH. SHOWERS BECOMING WINTRY. GOOD. From discuss-bounces@apps.ietf.org Tue May 22 19:30:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqdnr-0006QY-6l; Tue, 22 May 2007 19:30:07 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hqdno-0006QI-IX for discuss-confirm+ok@megatron.ietf.org; Tue, 22 May 2007 19:30:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqdno-0006QA-1u for discuss@apps.ietf.org; Tue, 22 May 2007 19:30:04 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hqdnm-0006Jh-LF for discuss@apps.ietf.org; Tue, 22 May 2007 19:30:04 -0400 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3A18C142207; Tue, 22 May 2007 16:30:02 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ci0AC3Jd5C84; Tue, 22 May 2007 16:30:01 -0700 (PDT) Received: from [10.1.1.201] (ip10.commerce.net [157.22.41.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id D8D21142206; Tue, 22 May 2007 16:30:00 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7AB296E7-177E-4CDC-9347-4946152A3057@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: Use of LWSP in ABNF -- consensus call Date: Tue, 22 May 2007 16:29:55 -0700 To: Lisa Dusseault X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Apps Discuss , Paul Overell , Dave Crocker , IETF General Discussion Mailing List , ietf-dkim@mipassoc.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Thanks for everybody's input on this. I interpret the discussion as showing consensus for a comment with a warning near the definition of LWSP. Details: I counted 18 opinions. I couldn't see anybody arguing for "no comment or text whatsoever". I saw arguments against treating this as a Security Consideration. I saw opinions in favour of "deprecating" the construct, but I am not sure if that's an opinion for or against the health warning (since the definition of deprecation is loose here). In any case, even if you count those as "votes against" , I still see rough consensus. Lisa > > The IESG reviewed crocker-rfc4234bis-00.txt> for publication as Internet Standard and > would like to know if there is consensus to recommend against the > use of LWSP in future specifications, as it has caused problems > recently in DKIM and could cause problems in other places. > > Some discussion on this point already: > - http://www1.ietf.org/mail-archive/web/ietf/current/msg46048.html > - http://www1.ietf.org/mail-archive/web/discuss/current/msg00463.html > - http://mipassoc.org/pipermail/ietf-dkim/2007q1/007295.html > - https://datatracker.ietf.org/public/pidtracker.cgi? > command=view_comment&id=66440 (in this tracker comment, Chris > Newman recommended to remove LWSP, but for backward-compatibility > it's probably better to keep it and recommend against use) > > Thanks for your input, > Lisa Dusseault > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf From discuss-bounces@apps.ietf.org Wed May 23 04:25:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqmAK-0006XW-3W; Wed, 23 May 2007 04:25:52 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HqmAI-0006XM-BM for discuss-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 04:25:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqmAH-0006XE-UL for discuss@apps.ietf.org; Wed, 23 May 2007 04:25:49 -0400 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqmAG-0001Vc-I3 for discuss@apps.ietf.org; Wed, 23 May 2007 04:25:49 -0400 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTPœ id l4N8PinB013542Wed, 23 May 2007 08:25:46 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1Hqm8w-000FUy-00; Wed, 23 May 2007 09:24:26 +0100 Date: Wed, 23 May 2007 09:24:26 +0100 From: "Clive D.W. Feather" To: Keith Moore Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call Message-ID: <20070523082426.GA57435@finch-staff-1.thus.net> References: <4649FA12.30909@alvestrand.no> <4649FB9A.9000107@bbiw.net> <1504A69099CF1B62F66FE576@p3.JCK.COM> <464C8822.7020503@dcrocker.net> <464CC8D3.2000700@dcrocker.net> <464D02EF.6070607@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <464D02EF.6070607@cs.utk.edu> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ietf-dkim@mipassoc.org, Apps Discuss , dcrocker@bbiw.net, Paul Overell , Sam Hartman , IETF General Discussion Mailing List X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Keith Moore said: > it could be argued that the best thing to do is to remove ALL of the > rules from the ABNF spec, leaving only the language definition and > examples. While I don't support this, it does remind me of a problem. I've had various people tell me in the past that "ABNF" includes Appendix B and, therefore, it is neither necessary to cite the appendix or to define basic concepts yourself. I know that section 1 says that appendix B is "separate from its formal status", but I suggest that the introduction to the appendix should make it clear that citing ABNF does *not* include these rules by reference; such inclusion by reference needs to be explicit. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | From discuss-bounces@apps.ietf.org Wed May 23 04:48:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqmVw-0005Go-JD; Wed, 23 May 2007 04:48:12 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HqmVv-0005Gj-5W for discuss-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 04:48:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqmVu-0005Gb-S2 for discuss@apps.ietf.org; Wed, 23 May 2007 04:48:10 -0400 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqmVt-0001bS-Ee for discuss@apps.ietf.org; Wed, 23 May 2007 04:48:10 -0400 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTPœ id l4N8m8ph021166Wed, 23 May 2007 08:48:08 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1HqmUd-000G2n-00; Wed, 23 May 2007 09:46:51 +0100 Date: Wed, 23 May 2007 09:46:51 +0100 From: "Clive D.W. Feather" To: dcrocker@bbiw.net Subject: Re: Seeking clarification of ABNF "name formation" reference Message-ID: <20070523084651.GB57435@finch-staff-1.thus.net> References: <46523D89.70905@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46523D89.70905@dcrocker.net> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Dave Crocker said: >>
>> >> The various mechanisms described above have the following >> precedence, from highest (binding tightest) at the top, to >> lowest (loosest) at the bottom: >> >> Strings, Names formation >> Comment >> Value range >> Repetition >> Grouping, Optional >> Concatenation >> Alternative >> >> >> If "value range" means the "%x20-3F" construct, then that has higher precedence than comment, I would suggest. More significantly, repetition has lower precedence than grouping and optional: this is shown firstly by the formal grammar, and secondly because "*(A B)" means zero or more sets of A-then-B, while if repetition had higher precedence then it would mean zero or more As followed by one B (that is, the same as "((*A) B)"). > The reference to "Name formation" has been in this form since RFC 2234. I assumed it was . However, as Philip points out, it's not defined anywhere in sections 2 or 3. Rather, 2.1 implies that the "" form can occur on the left of the if the author wants. This means that the grammar should have the following definitions for rulename: rulename = ub-rulename / "<" ub-rulename ">" ub-rulename = ALPHA *(ALPHA / DIGIT / "-") I've used "ub-rulename" to mean "unbracketed rulename"; feel free to change it. Is it intentional to allow to end in a hyphen? As well as needing a textual description of , there are two other considerations: (1) the comment implies that "<" cannot occur in a , but the formal grammar allows it; (2) with the above change, the grammar is ambiguous, because "" can be either a or a . This needs disambiguating in some way, either in a comment or by requiring a prose-val to contain a non alphanumeric character (which might be space). -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | From discuss-bounces@apps.ietf.org Wed May 23 07:47:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqpJA-0007gE-K0; Wed, 23 May 2007 07:47:12 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HqpJ9-0007g9-Ne for discuss-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 07:47:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqpJ9-0007fv-Do for discuss@apps.ietf.org; Wed, 23 May 2007 07:47:11 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HqpJ8-0000tV-1J for discuss@apps.ietf.org; Wed, 23 May 2007 07:47:11 -0400 Received: (qmail invoked by alias); 23 May 2007 11:47:09 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.87]) [217.91.35.233] by mail.gmx.net (mp047) with SMTP; 23 May 2007 13:47:09 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX191WLQ7gHZ1EHx4eL17cLbegnyf6EqTkkgcGlux0A QcObvnLKUfMnRS Message-ID: <465429B2.8030006@gmx.de> Date: Wed, 23 May 2007 13:46:58 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: "Clive D.W. Feather" Subject: Re: Seeking clarification of ABNF "name formation" reference References: <46523D89.70905@dcrocker.net> <20070523084651.GB57435@finch-staff-1.thus.net> In-Reply-To: <20070523084651.GB57435@finch-staff-1.thus.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: discuss@apps.ietf.org, dcrocker@bbiw.net X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Clive D.W. Feather wrote: > If "value range" means the "%x20-3F" construct, then that has higher > precedence than comment, I would suggest. More significantly, repetition > has lower precedence than grouping and optional: this is shown firstly by > the formal grammar, and secondly because "*(A B)" means zero or more sets > of A-then-B, while if repetition had higher precedence then it would mean > zero or more As followed by one B (that is, the same as "((*A) B)"). Maybe we could have the individual items in the precedence list reference either subsections in section 3, or rule names in section 4? >> The reference to "Name formation" has been in this form since RFC 2234. > > I assumed it was . > > However, as Philip points out, it's not defined anywhere in sections 2 or > 3. Rather, 2.1 implies that the "" form can occur on the left of > the if the author wants. This means that the grammar should > have the following definitions for rulename: Maybe we should check whether that is used in practice, and what the parser implementations do with it. > rulename = ub-rulename / "<" ub-rulename ">" > ub-rulename = ALPHA *(ALPHA / DIGIT / "-") > > I've used "ub-rulename" to mean "unbracketed rulename"; feel free to change > it. > > Is it intentional to allow to end in a hyphen? > > As well as needing a textual description of , there are two other > considerations: > (1) the comment implies that "<" cannot occur in a , but the > formal grammar allows it; Right. > (2) with the above change, the grammar is ambiguous, because "" > can be either a or a . This needs disambiguating > in some way, either in a comment or by requiring a prose-val to contain > a non alphanumeric character (which might be space). Best regards, Julian From discuss-bounces@apps.ietf.org Wed May 23 17:16:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqyC7-0008AI-0c; Wed, 23 May 2007 17:16:31 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HqyC5-0008AD-ED for discuss-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 17:16:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqyC5-0008A5-4X for discuss@apps.ietf.org; Wed, 23 May 2007 17:16:29 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqyC3-0005lG-Nk for discuss@apps.ietf.org; Wed, 23 May 2007 17:16:29 -0400 Received: from [192.168.0.4] (adsl-68-122-125-236.dsl.pltn13.pacbell.net [68.122.125.236]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l4NLGEMl025238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 23 May 2007 14:16:15 -0700 Message-ID: <4654AEEC.80503@dcrocker.net> Date: Wed, 23 May 2007 14:15:24 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: discuss@apps.ietf.org Subject: Re: Seeking clarification of ABNF "name formation" reference References: <46523D89.70905@dcrocker.net> <20070523084651.GB57435@finch-staff-1.thus.net> <465429B2.8030006@gmx.de> In-Reply-To: <465429B2.8030006@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Folks, I think we figured out what this was about. The 'name formation' meant the aggregation of characters that form a rulename. The revised precedence list reads: > > Rule name, prose-val, Terminal value > > Comment > > Value range > > Repetition > > Grouping, Optional > > Concatenation > > Alternative We believe that each item on the first line is explained with existing definitions or text. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From discuss-bounces@apps.ietf.org Wed May 23 22:23:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hr2yw-000427-5a; Wed, 23 May 2007 22:23:14 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HqV8L-00082e-Nn for discuss-confirm+ok@megatron.ietf.org; Tue, 22 May 2007 10:14:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqV8L-00082W-EB for discuss@apps.ietf.org; Tue, 22 May 2007 10:14:41 -0400 Received: from piper.mulberrymail.com ([151.201.22.177] helo=mulberrymail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqV8K-0001fI-TW for discuss@apps.ietf.org; Tue, 22 May 2007 10:14:41 -0400 Received: from caldav.corp.apple.com (A17-101-32-44.apple.com [17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l4MEEX79013306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 May 2007 10:14:35 -0400 Date: Tue, 22 May 2007 10:14:27 -0400 From: Cyrus Daboo To: Chris Newman , discuss@apps.ietf.org Subject: Re: vCard and CardDAV strawman Charter Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on piper.mulberrymail.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 X-Mailman-Approved-At: Wed, 23 May 2007 22:23:12 -0400 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi Chris, Some comments: - Yes I would very much like to see this effort happen. --On May 20, 2007 3:57:10 PM -0700 Chris Newman wrote: > I've had several people contact me interested in work on vCard and > CardDAV. So I'm contemplating a BOF on the topic at the Chicago IETF. > I'm interested in volunteers for the following roles: > > 1. BOF chair / co-chair (responsible for charter editing and running a > BOF) > 2. WG chair / co-chair (responsible for running the WG) > 3. vCard revision document editor Whilst I currently have limited time to work on the vCard revision as an autyhor, I do have an XML version of the original 2426 document for whoever wants to take this on. > --- > vCard and CardDAV strawman charter (vcarddav) > > A personal address book (PAB) contains a read/write copy of attributes > describing a user's interpersonal contacts. This is distinct from a > directory which contains a primarily read-only copy of users within an > organization. While these two data objects share a large number of common > attributes, their use and access patterns are fundamentally different. > The IETF has a standards-track data format (vCard) which has been > successfully used to interchange both personal-address-book and user > directory entry data objects. However, due to the lack of a standard > access control model for LDAP, the lack of a standard LDAP schema and > DIT-model for vCard PAB objects, and the different access patterns for > PAB data (as opposed to directory data), the use of LDAP as an access > protocol for PABs has had mixed results in practice. > > If the deployed protocols related to interpersonal communication are > viewed as a component-based system, there are a number of points in the > system that would benefit from a standards track access protocol for > personal address book data. This includes: > > * Mail User Agents use PAB data to assist outgoing email addressing and > may > use vCard attachments to transport PAB data between users. > * Calendar User Agents use PAB data to invite attendees to events > * Instant Messaging User Agents can provide additional information about > a user's buddies if they can be associated with a user's PAB entry. > * A server-side Sieve engine with the spamtest/virustest extension would > benefit from access to a user's PAB to provide per-user white list > capabilities. > * Various deployed challenge-response mechanisms for email present > in Mail Transfer Agents, such as TMDA, would be improved by a PAB-based > white list. > * Mobile device synchronization software might be simplified by a > single cross-platform PAB access protocol. > * A voice conference or IP telephony system could access a user's PAB to > provide name-based or nickname-based dialing. > > This WG will produce the following two primary outputs: > > * A revision of the vCard spec (RFC 2426) likely at proposed standard > status. The WG will attempt to avoid adding new features, with two > exceptions: 1. The WG may consider including other proposed standard > vCard > extensions (e.g., RFC 4770, RFC 2739). 2. The WG may evaluate > extensions > that would assist synchronization technologies (for example, a per-entry > UUID or per-attribute sequence number). I agree that rolling up all the new properties defined in RFCs into one document would be good. Also I think it would make sense to define an IANA registry for properties along the lines of what iCalendar has (is) doing. There has also been some discussion about the lack of a "groups" facility in vCard - i.e. the ability to specify a distribution list that references other vCards in a list. Many PAB clients have the concept of a "group" of addresses, so I think formalizing something like that in vCard would be good too. > * An address book access protocol leveraging the vCard data format. The > Internet-draft draft-daboo-carddav will be the starting point. > The WG is explicitly cautioned to keep the base specification feature > set > small with an adequate extension mechanism, as failure to do so was a > problem for previous PAB efforts (ACAP). The WG will consider arguments > of the form "feature X must be in the base feature set because ..." > with great skepticism. Some things to note: - The latest CardDAV spec (-02) was just published. This now pretty much echoes exactly what is in the CalDAV Spec (RFC4791) and I was planning on asking for a last call on it soon. - One thing did get removed from CardDAV in the last revision - the "synchronization" report feature. I removed this because a similar feature is also needed by CalDAV, and is arguably applicable to WebDAV as a whole. I was planning on writing that up as a separate spec (work under way). I would like to see such a specification also be dealt with by this group - I think it is in scope on the basis that it does touch on synchronization issues (and more specifically for deployment - performance). > These documents will consider security implications carefully. The WG > will consider developing a mechanism that provides the ability to check > if an email address (or im address, etc) is in the user's PAB without > providing unrestricted access to all of the user's PAB data. The WG > should also consider developing a mechanism that allows the user to grant > this limited permission to a third-party service (such as a server-based > Sieve engine) for white-list purposes. Interesting. That is something that I had not considered in CardDAV. Though we do have something similar in CalDAV - the CALDAV:read-free-busy privilege which allows a user (WebDAV principal) to get busy time information on another user's calendar without actually exposing the underlying calendar data. We could do something similar here: define a new report that is used for verifying addresses, and a new WebDAV privilege to grant the right to run that report separately from the ability to read the content of an address book collection. That way, the third party service could be given a principal on the WebDAV server and the right to run that report only. I think that would cover this. > Once the primary outputs are complete, the WG may consider the following > secondary outputs: > > * An XML schema which is semantically identical to vCard in all ways and > can > be mechanically translated to and from vCard format without loss of > data. > While vCard has deployed successfully and will remain the preferred > interchange format, a standard XML schema which preserves vCard > semantics > might make vCard data more accessible to XML-centric technologies such > as > AJAX and XSLT. Such a standard format would be preferable to multiple > proprietary XML schemas, particularly if vCard semantics were lost by > some > of them and a lossy gateway problem resulted. The jabber community already has a vCard<->XML spec that we could look at. I have to say that there has also been some renewed interest within the Calendaring and Scheduling Consortium to progress the iCalendar<->XML work too. Since the two formats are very close it would make sense to tackle both of these in the same way. > * Identifying useful deployed vCard vendor extensions and creating > standards > track versions of those extensions. FYI There has been some recent discussion in Calconnect (the Calendaring and Scheduling Consortium) about doing some work on vCard. Obviously many people that do calendaring also do address books/contact information (in particular mobile device vendors) and many of the pain points in iCalendar synchronization also exist in vCard. To that end Calconnect is considering supporting any vCard efforts in the same way it has supported iCalendar and related work (e.g. through production of recommendation documents, surveys, interoperability testing). At present Calconnect is discussing the possibility of a one day vCard workshop to be held in conjunction with its next Roundtable meeting in Boston in September. Certainly if the IETF proceeds with this work, that would likely happen - but as with the WG, it really depends on enough interested parties coming to the table. > * Cooperate with the Sieve WG to produce a Sieve extension for address > book > Sieve tests. In any case, I hope we can progress with this BOF and maybe WG too. -- Cyrus Daboo From discuss-bounces@apps.ietf.org Thu May 24 04:53:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hr94I-0002ja-Vt; Thu, 24 May 2007 04:53:10 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hr94I-0002jO-1D for discuss-confirm+ok@megatron.ietf.org; Thu, 24 May 2007 04:53:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hr94H-0002jG-EW for discuss@apps.ietf.org; Thu, 24 May 2007 04:53:09 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hr94G-0005Dk-05 for discuss@apps.ietf.org; Thu, 24 May 2007 04:53:09 -0400 Received: (qmail invoked by alias); 24 May 2007 08:46:54 -0000 Received: from p508FA1D4.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.161.212] by mail.gmx.net (mp049) with SMTP; 24 May 2007 10:46:54 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/WPFE3dfPWlHlBgXeVMW2UAWw8bC6qIXUSAbhOdS REB7DAb6tfFf7C Message-ID: <4655509E.8010903@gmx.de> Date: Thu, 24 May 2007 10:45:18 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: vCard and CardDAV strawman Charter References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: discuss@apps.ietf.org, Chris Newman X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Cyrus Daboo wrote: > I agree that rolling up all the new properties defined in RFCs into one > document would be good. Also I think it would make sense to define an > IANA registry for properties along the lines of what iCalendar has (is) > doing. That registry exists at ; a revision of RFC2425 probably should cite that. > Some things to note: > > - The latest CardDAV spec (-02) was just published. This now pretty much > echoes exactly what is in the CalDAV Spec (RFC4791) and I was planning > on asking for a last call on it soon. > > - One thing did get removed from CardDAV in the last revision - the > "synchronization" report feature. I removed this because a similar > feature is also needed by CalDAV, and is arguably applicable to WebDAV > as a whole. I was planning on writing that up as a separate spec (work > under way). I would like to see such a specification also be dealt with > by this group - I think it is in scope on the basis that it does touch > on synchronization issues (and more specifically for deployment - > performance). Having that stand-alone sounds right, please do it on the former WebDAV WG's mailing list... > ... Best regards, Julian From discuss-bounces@apps.ietf.org Thu May 24 10:10:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrE16-0003kp-DD; Thu, 24 May 2007 10:10:12 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HrE15-0003kc-Gj for discuss-confirm+ok@megatron.ietf.org; Thu, 24 May 2007 10:10:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrE14-0003kQ-6k for discuss@apps.ietf.org; Thu, 24 May 2007 10:10:10 -0400 Received: from piper.mulberrymail.com ([151.201.22.177] helo=mulberrymail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrE12-0002P9-S0 for discuss@apps.ietf.org; Thu, 24 May 2007 10:10:10 -0400 Received: from caldav.corp.apple.com (A17-101-32-44.apple.com [17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l4OEA4ii022490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 May 2007 10:10:07 -0400 Date: Thu, 24 May 2007 10:09:59 -0400 From: Cyrus Daboo To: Julian Reschke Subject: Re: vCard and CardDAV strawman Charter Message-ID: In-Reply-To: <4655509E.8010903@gmx.de> References: <4655509E.8010903@gmx.de> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on piper.mulberrymail.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: discuss@apps.ietf.org, Chris Newman X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi Julian, --On May 24, 2007 10:45:18 AM +0200 Julian Reschke wrote: > Cyrus Daboo wrote: >> I agree that rolling up all the new properties defined in RFCs into one >> document would be good. Also I think it would make sense to define an >> IANA registry for properties along the lines of what iCalendar has (is) >> doing. > > That registry exists at > ; a > revision of RFC2425 probably should cite that. Hrmm - well that registry does not reference the vCard spec 2426, and 2426 does not reference it (as you noted). Also the IANA registry is not populated with the registrations defined in 2425 itself, and it ought to include the items defined in 2426 too. So something definitely needs to be fixed. Also, in CardDAV I used the MIME type text/vcard - but I note that does is not the registered type. Instead 'text/directory; profile=vcard' is. However, I am pretty sure I have seen text/vcard being used in email - it may be we want to register that too as part of vcard-bis. I also question the utility of text/directory these days. It seems that the only thing that actually uses it is vCard. Does it still make sense to have that as a separate document, or should it be rolled up into the vCard-bis effort? At the very least it may be that 2425 needs some updating as well and should be something we discuss at the BOF and potentially include in the charter. >> - One thing did get removed from CardDAV in the last revision - the >> "synchronization" report feature. I removed this because a similar >> feature is also needed by CalDAV, and is arguably applicable to WebDAV >> as a whole. I was planning on writing that up as a separate spec (work >> under way). I would like to see such a specification also be dealt with >> by this group - I think it is in scope on the basis that it does touch >> on synchronization issues (and more specifically for deployment - >> performance). > > Having that stand-alone sounds right, please do it on the former WebDAV > WG's mailing list... Whilst this is a "generic" WebDAV extension, both CalDAV and CardDAV really need it, so I would like to see this be part of the work items for the proposed working group if it gets going. -- Cyrus Daboo From discuss-bounces@apps.ietf.org Fri May 25 08:11:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrYdI-0000qv-4b; Fri, 25 May 2007 08:11:00 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HrYdG-0000fi-39 for discuss-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 08:10:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrYdF-0000cP-J2 for discuss@apps.ietf.org; Fri, 25 May 2007 08:10:57 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HrYdE-0001w1-6M for discuss@apps.ietf.org; Fri, 25 May 2007 08:10:57 -0400 Received: (qmail invoked by alias); 25 May 2007 12:10:54 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.87]) [217.91.35.233] by mail.gmx.net (mp030) with SMTP; 25 May 2007 14:10:54 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/uXPVVBSHu1MdlY72zyPMNhJQ2O21gQ9m5+HQvvJ 6Xa+u1/MfmjSSf Message-ID: <4656D240.8070204@gmx.de> Date: Fri, 25 May 2007 14:10:40 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: vCard and CardDAV strawman Charter References: <4655509E.8010903@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: discuss@apps.ietf.org, Chris Newman X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Cyrus Daboo wrote: > Also, in CardDAV I used the MIME type text/vcard - but I note that does > is not the registered type. Instead 'text/directory; profile=vcard' is. > However, I am pretty sure I have seen text/vcard being used in email - > it may be we want to register that too as part of vcard-bis. Interesting. Of course I do agree that whatever gets used should be registered. Do we have any evidence that 'text/directory; profile=vcard' doesn't work in practice? > I also question the utility of text/directory these days. It seems that > the only thing that actually uses it is vCard. Does it still make sense > to have that as a separate document, or should it be rolled up into the > vCard-bis effort? At the very least it may be that 2425 needs some > updating as well and should be something we discuss at the BOF and > potentially include in the charter. Probably true. >>> - One thing did get removed from CardDAV in the last revision - the >>> "synchronization" report feature. I removed this because a similar >>> feature is also needed by CalDAV, and is arguably applicable to WebDAV >>> as a whole. I was planning on writing that up as a separate spec (work >>> under way). I would like to see such a specification also be dealt with >>> by this group - I think it is in scope on the basis that it does touch >>> on synchronization issues (and more specifically for deployment - >>> performance). >> >> Having that stand-alone sounds right, please do it on the former WebDAV >> WG's mailing list... > > Whilst this is a "generic" WebDAV extension, both CalDAV and CardDAV > really need it, so I would like to see this be part of the work items > for the proposed working group if it gets going. It's fine to have it as a work item, but it still may make sense to use the more generic mailing list for it (that's what it's for after all). Best regards, Julian From discuss-bounces@apps.ietf.org Fri May 25 08:31:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrYx2-00050u-5e; Fri, 25 May 2007 08:31:24 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HrYx0-00050p-3G for discuss-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 08:31:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrYwz-00050h-Pq for discuss@apps.ietf.org; Fri, 25 May 2007 08:31:21 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HrYwy-0004db-D6 for discuss@apps.ietf.org; Fri, 25 May 2007 08:31:21 -0400 Received: (qmail invoked by alias); 25 May 2007 12:31:19 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.87]) [217.91.35.233] by mail.gmx.net (mp039) with SMTP; 25 May 2007 14:31:19 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+assU0Ih+arnT+V5CKw08aKxgSBFf5FPbpwqEkpq Foo9vLc7k+NF55 Message-ID: <4656D709.2090604@gmx.de> Date: Fri, 25 May 2007 14:31:05 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: vCard and CardDAV strawman Charter References: <4655509E.8010903@gmx.de> <4656D240.8070204@gmx.de> In-Reply-To: <4656D240.8070204@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: discuss@apps.ietf.org, Chris Newman X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Julian Reschke wrote: > Cyrus Daboo wrote: >> Also, in CardDAV I used the MIME type text/vcard - but I note that >> does is not the registered type. Instead 'text/directory; >> profile=vcard' is. However, I am pretty sure I have seen text/vcard >> being used in email - it may be we want to register that too as part >> of vcard-bis. > > Interesting. Of course I do agree that whatever gets used should be > registered. Do we have any evidence that 'text/directory; profile=vcard' > doesn't work in practice? > ... Speaking of which, it seems that what is in common use is "text/x-vcard" - unregistered as well. So yes, the media type issue probably should be in the WG's charter. Best regards, Julian From discuss-bounces@apps.ietf.org Wed May 30 08:57:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtNk8-0001eu-Tj; Wed, 30 May 2007 08:57:36 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtNk7-0001dP-6W for discuss-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 08:57:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtNk6-0001cK-SO for discuss@apps.ietf.org; Wed, 30 May 2007 08:57:34 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtNk5-0001Q2-CX for discuss@apps.ietf.org; Wed, 30 May 2007 08:57:34 -0400 Received: from [192.168.1.102] (unknown [59.167.129.121]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id C2C3E5194C; Wed, 30 May 2007 08:57:29 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Straw-man charter for http-bis Date: Wed, 30 May 2007 22:57:25 +1000 To: "ietf-http-wg@w3.org Group" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Revision based upon feedback and discussion; ---8<--- HyperText Transfer Protocol Revision (http-bis) Charter Last Modified: 2007-05-30 Chair(s): [TBD] Applications Area Director(s): Chris Newman Lisa Dusseault Applications Area Advisor: [TBD] Mailing Lists: General Discussion: ietf-http-wg@w3.org To Subscribe: ietf-http-wg-request@w3.org In Subject: subscribe Archive: http://lists.w3.org/Archives/Public/ietf-http-wg/ Description of Working Group: HTTP is one of the most successful and widely-used protocols on the Internet today. However, its specification has several editorial issues. Additionally, after years of implementation and extension, several ambiguities have arisen, impairing interoperability and the ability to easily implement and use HTTP to its full potential. The working group will refine RFC2616 to: * Incorporate errata and updates * Improve editorial quality * Clarify conformance requirements * Remove known ambiguities where they affect interoperability * Clarify methods and requirements for extensibility * Remove or deprecate those features that are not widely implemented, unduly affect interoperability and are not well-supported * Where necessary, add implementation advice * Document the security properties of HTTP and its associated mechanisms (e.g., Basic and Digest authentication, cookies, TLS) for common applications In doing so, it should consider: * Implementer experience * Demonstrated use of HTTP * Impact on existing implementations and deployments The Working Group must not introduce a new version of HTTP, and should not introduce new features or capabilities to HTTP. The Working Group's specification deliverables are: * A document that is suitable to supersede RFC2616 * A document cataloguing the security properties of HTTP Additionally, the Working Group should review (and may document) test suites for HTTP conformance, as they are made available. Goals and Milestones: Sep 2007 - First HTTP Revision Internet Draft Nov 2007 - First HTTP Security Properties Internet Draft Dec 2007 - IETF 70 Meeting, Vancouver, BC, Canada Mar 2008 - IETF 71 Meeting, Philadelphia, PA, USA Apr 2008 - Request Last Call for HTTP Revision May 2008 - Request Last Call for HTTP Security Properties Jul 2008 - IETF 72 Meeting, TBD Aug 2008 - Submit HTTP Revision to IESG for consideration as a Proposed Standard Aug 2008 - Submit HTTP Security Properties to IESG for consideration as Best Current Practice --->8--- On 06/03/2007, at 5:54 PM, Mark Nottingham wrote: > > Below, I've cut-and-pasted a straw-man charter along the lines that > have been previously discussed. It's on a fairly short time-scale, > to focus efforts on interop and editorial work, rather than > spinning off into large-scale revisions or adding new features. > > The tentative path forward is to discuss this informally in Prague, > have a formal BoF in Chicago, and start thereafter. > > Comments would be very much appreciated. > > Cheers, > > ---8<--- > HyperText Transfer Protocol Revision (http-bis) Charter > > Last Modified: 2007-01-14 > > Chair(s): > [TBD] > > Applications Area Director(s): > [TBD] > Lisa Dusseault > > Applications Area Advisor: > [TBD] > > Mailing Lists: > General Discussion: ietf-http-wg@w3.org > To Subscribe: ietf-http-wg-request@w3.org > In Subject: subscribe > Archive: http://lists.w3.org/Archives/Public/ietf-http-wg/ > > Description of Working Group: > HTTP is one of the most successful and widely-used protocols on the > Internet today. However, its specification has several editorial > issues. Additionally, after years of implementation and extension, > several ambiguities have arisen, impairing interoperability and the > ability to easily implement and use HTTP to its full potential. > > The working group will refine RFC2616 to: > * Incorporate errata > * Improve editorial quality > * Clarify conformance requirements and targets > * Eliminate ambiguities where they affect interoperability > * Document the extensibility model of HTTP > * Add implementation advice (e.g., deprecating problematic > optional features, if necessary) > * Update to reflect current IETF practice > * Identify mandatory-to-implement security mechanisms > > In doing so, it should consider: > * Implementer experience > * Demonstrated use of HTTP > * Impact on existing implementations and deployments > > The working group must not introduce a new version of HTTP. It > should not introduce new features or capabilities to HTTP, except > where doing so is necessary to improve interoperability. > > The Working Group's sole specification deliverable is a document > that is suitable to supersede RFC2616. > > Additionally, the working group may produce one or more test suites > for HTTP conformance, if there is sufficient interest. > > Goals and Milestones: > Sep 2007 - First HTTP Revision Internet Draft > Dec 2007 - IETF 70 Meeting, TBD > Mar 2008 - IETF 71 Meeting, TBD > Apr 2008 - Request Last Call for HTTP Revision > Jul 2008 - IETF 72 Meeting, TBD > Aug 2008 - Submit HTTP Revision to IESG for consideration as a > Proposed Standard > --->8--- > > > -- > Mark Nottingham http://www.mnot.net/ > > -- Mark Nottingham http://www.mnot.net/ From discuss-bounces@apps.ietf.org Wed May 30 09:11:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtNxY-0001oq-FY; Wed, 30 May 2007 09:11:28 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtNxX-0001ol-Uy for discuss-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 09:11:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtNxX-0001od-LK for discuss@apps.ietf.org; Wed, 30 May 2007 09:11:27 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HtNxW-0007DW-8e for discuss@apps.ietf.org; Wed, 30 May 2007 09:11:27 -0400 Received: (qmail invoked by alias); 30 May 2007 13:11:24 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.87]) [217.91.35.233] by mail.gmx.net (mp004) with SMTP; 30 May 2007 15:11:24 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19DXT8UCw1DoeRDzX9Z46NUj/XWkcz7Z8V8iJPesL U1E+1hLjgDUgIk Message-ID: <465D77F9.1010106@gmx.de> Date: Wed, 30 May 2007 15:11:21 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Alexey Melnikov Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D76EE.7060408@isode.com> In-Reply-To: <465D76EE.7060408@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Apps Discuss , Mark Nottingham , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Alexey Melnikov wrote: > > Hi Mark, > > Mark Nottingham wrote: > >> Aug 2008 - Submit HTTP Revision to IESG for consideration as a >> Proposed Standard > > I think the target should be to move the document to Draft. Actually, it already *is* a Draft Standard, so I think the target should be to *keep* it a Draft Standard, with an eye on the possibility to actually get it to full Standard (which may require creative solutions to the MIME dependencies). Best regards, Julian From discuss-bounces@apps.ietf.org Wed May 30 10:51:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtPWA-0001fq-5Y; Wed, 30 May 2007 10:51:18 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtPW8-0001fg-W6 for discuss-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 10:51:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtPW8-0001fY-MF for discuss@apps.ietf.org; Wed, 30 May 2007 10:51:16 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtPW7-0004jT-9l for discuss@apps.ietf.org; Wed, 30 May 2007 10:51:16 -0400 Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l4UEpCSq089060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 May 2007 07:51:13 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> Date: Wed, 30 May 2007 07:51:10 -0700 To: Mark Nottingham , "ietf-http-wg@w3.org Group" From: Paul Hoffman Subject: Re: Straw-man charter for http-bis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Serious question, not a gratuitous opening of a big can-o-worms: would the WG also consider extensions to HTTP that would go into different documents? That is, is the WG only for the revision of the base spec, or also open to ( animated && lengthy && contentious ) discussion of other documents as well? From discuss-bounces@apps.ietf.org Wed May 30 10:59:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtPdx-0006u2-Vm; Wed, 30 May 2007 10:59:21 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtPdx-0006ts-BU for discuss-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 10:59:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtPdx-0006tk-0t for discuss@apps.ietf.org; Wed, 30 May 2007 10:59:21 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HtPdv-0005Vm-KT for discuss@apps.ietf.org; Wed, 30 May 2007 10:59:21 -0400 Received: (qmail invoked by alias); 30 May 2007 14:59:18 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.87]) [217.91.35.233] by mail.gmx.net (mp017) with SMTP; 30 May 2007 16:59:18 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18Jse8jXUYJDUjoyBHhMiopWZ0VNRog/pBTvPP6IM 1ickvcfYyf7Gy4 Message-ID: <465D9142.9050506@gmx.de> Date: Wed, 30 May 2007 16:59:14 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Paul Hoffman Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Apps Discuss , Mark Nottingham , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Paul Hoffman wrote: > Serious question, not a gratuitous opening of a big can-o-worms: would > the WG also consider extensions to HTTP that would go into different > documents? That is, is the WG only for the revision of the base spec, or > also open to ( animated && lengthy && contentious ) discussion of other > documents as well? I guess the idea was that the more we restrict the scope of what we want to do, the easier it'll be to gather the right group of people to do it. For instance, RFC2617 needs a revision badly as well (for instance, wrt to I18N of usernames and passwords, and, as far as I can recall, certain problems with the definition of Digest Auth). IMHO; this should occur in a separate working group. Are there any specific extensions you have in mind? Best regards, Julian From discuss-bounces@apps.ietf.org Wed May 30 11:30:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtQ80-00071w-Ew; Wed, 30 May 2007 11:30:24 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtQ7z-00071q-H0 for discuss-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 11:30:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtQ7z-00071i-7M for discuss@apps.ietf.org; Wed, 30 May 2007 11:30:23 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtQ7x-0000wi-UQ for discuss@apps.ietf.org; Wed, 30 May 2007 11:30:23 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 30 May 2007 17:30:22 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l4UFULHb000702; Wed, 30 May 2007 17:30:21 +0200 Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp304.cisco.com [10.61.65.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4UFU7DR006405; Wed, 30 May 2007 15:30:07 GMT Message-ID: <465D987F.5070906@cisco.com> Date: Wed, 30 May 2007 17:30:07 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Julian Reschke Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> In-Reply-To: <465D9142.9050506@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=393; t=1180539021; x=1181403021; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20Straw-man=20charter=20for=20http-bis |Sender:=20; bh=vX4seLa+13YEJ20vWxHlK/q9kEa6uJTcp8/yddn9J14=; b=VfmR3qZVnQ4C3/yNHuChqFBjtlSvg0k3np8C1t9RVkUVr5CuelTv5vlBmWP7fOlY38wxuCQm VY7XqWd3XfknCzpmKuaMaoYWF0JfksfUvx0ELazTmUUzXxAL5DvA4Mq3; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Paul Hoffman , Apps Discuss , Mark Nottingham , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Julian Reschke wrote: > For instance, RFC2617 needs a revision badly as well (for instance, > wrt to I18N of usernames and passwords, and, as far as I can recall, > certain problems with the definition of Digest Auth). IMHO; this > should occur in a separate working group. The HTTP auth model needs a lot of work. Creating an update without addressing it seems to me pointless. From discuss-bounces@apps.ietf.org Wed May 30 11:33:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtQB4-00008i-CN; Wed, 30 May 2007 11:33:34 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtQB2-00008c-Nm for discuss-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 11:33:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtQB2-00008U-EB for discuss@apps.ietf.org; Wed, 30 May 2007 11:33:32 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtQB1-0001MS-1r for discuss@apps.ietf.org; Wed, 30 May 2007 11:33:32 -0400 Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l4UFXTDj099405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 May 2007 08:33:29 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <465D9142.9050506@gmx.de> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> Date: Wed, 30 May 2007 08:33:27 -0700 To: Julian Reschke From: Paul Hoffman Subject: Re: Straw-man charter for http-bis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Apps Discuss , Mark Nottingham , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org At 4:59 PM +0200 5/30/07, Julian Reschke wrote: >I guess the idea was that the more we restrict the scope of what we >want to do, the easier it'll be to gather the right group of people >to do it. Fully agree. >For instance, RFC2617 needs a revision badly as well (for instance, >wrt to I18N of usernames and passwords, and, as far as I can recall, >certain problems with the definition of Digest Auth). IMHO; this >should occur in a separate working group. The proposed charter has: * Document the security properties of HTTP and its associated mechanisms (e.g., Basic and Digest authentication, cookies, TLS) for common applications So, would obviously-needed changes to the associated mechanisms be in scope for the WG, or not? >Are there any specific extensions you have in mind? Definitely not. I was asking whether or not we want to clamp down on charter creep now or later. From discuss-bounces@apps.ietf.org Wed May 30 11:44:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtQM7-0006Xy-4F; Wed, 30 May 2007 11:44:59 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtQM6-0006Xr-DC for discuss-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 11:44:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtQM6-0006Xj-3Z for discuss@apps.ietf.org; Wed, 30 May 2007 11:44:58 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HtQM4-0003Hi-Mk for discuss@apps.ietf.org; Wed, 30 May 2007 11:44:58 -0400 Received: (qmail invoked by alias); 30 May 2007 15:44:55 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.87]) [217.91.35.233] by mail.gmx.net (mp032) with SMTP; 30 May 2007 17:44:55 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19XhaE2gtFXzUsoOM9CtfokVtWtCndO5zHZ5i2LaH htVpyxyDX+VvdG Message-ID: <465D9BF4.40707@gmx.de> Date: Wed, 30 May 2007 17:44:52 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Paul Hoffman Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Apps Discuss , Mark Nottingham , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Paul Hoffman wrote: > The proposed charter has: > * Document the security properties of HTTP and its associated > mechanisms (e.g., Basic and Digest authentication, cookies, TLS) > for common applications > So, would obviously-needed changes to the associated mechanisms be in > scope for the WG, or not? I would have hoped that we can concentrate on revising RFC2616, and do just that. However, we got signals from IESG members that a revision of RFC2616 would not be accepted unless it improves the security story. IMHO a very bad idea. Fixing it needs, but that needs to be done somewhere else. >> Are there any specific extensions you have in mind? > > Definitely not. I was asking whether or not we want to clamp down on > charter creep now or later. :-) I'd prefer the charter to be as small & precise as possible. Best regards, Julian From discuss-bounces@apps.ietf.org Wed May 30 12:47:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtRKi-0004fk-AK; Wed, 30 May 2007 12:47:36 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtRKh-0004ff-6U for discuss-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 12:47:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtRKg-0004fX-TB for discuss@apps.ietf.org; Wed, 30 May 2007 12:47:34 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtRKf-0000N2-Hi for discuss@apps.ietf.org; Wed, 30 May 2007 12:47:34 -0400 Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l4UGlVGW020513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 May 2007 09:47:32 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <465D9BF4.40707@gmx.de> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <465D9BF4.40707@gmx.de> Date: Wed, 30 May 2007 09:47:29 -0700 To: Apps Discuss , "ietf-http-wg@w3.org Group" From: Paul Hoffman Subject: Re: Straw-man charter for http-bis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Splitting my previous question into two: a) Will this WG consider clarifications and revisions to main-line HTTP-related RFCs, most notably the security ones? b) Will this WG consider new extensions to HTTP outside the main documents? If the answer to (a) is "no", then we need a second WG, which will likely have a lot of membership overlap. To me, that seems non-optimal. I'm OK either way with (b), but hope that if the answer is "yes" that they aren't even considered until all the other work is done first. From discuss-bounces@apps.ietf.org Wed May 30 13:04:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtRad-0006Pi-40; Wed, 30 May 2007 13:04:03 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtRab-0006Oi-Fo for discuss-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 13:04:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtRab-0006Oa-5x for discuss@apps.ietf.org; Wed, 30 May 2007 13:04:01 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtRaZ-0003ke-Ty for discuss@apps.ietf.org; Wed, 30 May 2007 13:04:01 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id B7F8C1EE1D0; Wed, 30 May 2007 13:03:58 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31z1sZ7pvif7; Wed, 30 May 2007 13:03:38 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 9B2C41EE1CB; Wed, 30 May 2007 13:03:25 -0400 (EDT) Message-ID: <465DAE5B.2070605@cs.utk.edu> Date: Wed, 30 May 2007 13:03:23 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Eliot Lear Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <465D987F.5070906@cisco.com> In-Reply-To: <465D987F.5070906@cisco.com> X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Paul Hoffman , Mark Nottingham , "ietf-http-wg@w3.org Group" , Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Eliot Lear wrote: > Julian Reschke wrote: >> For instance, RFC2617 needs a revision badly as well (for instance, >> wrt to I18N of usernames and passwords, and, as far as I can recall, >> certain problems with the definition of Digest Auth). IMHO; this >> should occur in a separate working group. > > The HTTP auth model needs a lot of work. Creating an update without > addressing it seems to me pointless. Not that I disagree, but sites that are currently using forms+ssl to do logins aren't going to go back to a model where the browser gets to control the UI for the username/password prompt. So maybe what is needed is an auth model that lets the server give credentials to the browser, along with some advice for how to use it. And whatever mechanism were defined to pass these credentials around would need to be substantially better than what can currently be done with SSL and cookies (if that's even possible) otherwise there would be no point in defining it. IMHO, the first work item of httpbis should be a defect list for http 1.1 and associated documents. The next step would be to assess which defects could reasonably be corrected in a revision to the http document (probably to recycle at DS). Then the group could be rechartered to revise the http specification and to correct other defects that could reasonably be done by that group. One or more additional groups could be spun up to correct the remaining defects. From discuss-bounces@apps.ietf.org Wed May 30 14:26:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtSsX-0007xh-Sc; Wed, 30 May 2007 14:26:37 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtSsX-0007xc-Hz for discuss-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 14:26:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtSsX-0007xU-8Q for discuss@apps.ietf.org; Wed, 30 May 2007 14:26:37 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HtSsV-0005R1-RS for discuss@apps.ietf.org; Wed, 30 May 2007 14:26:37 -0400 Received: (qmail invoked by alias); 30 May 2007 18:26:34 -0000 Received: from p508F99AB.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.153.171] by mail.gmx.net (mp034) with SMTP; 30 May 2007 20:26:34 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18chYt5AU8c6R9g+WPXEcqsreShgWwr0oMiFw+Cxf q4AUiE+oH1z9P0 Message-ID: <465DC1D6.1020700@gmx.de> Date: Wed, 30 May 2007 20:26:30 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Paul Hoffman Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <465D9BF4.40707@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Apps Discuss , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Paul Hoffman wrote: > > Splitting my previous question into two: > > a) Will this WG consider clarifications and revisions to main-line > HTTP-related RFCs, most notably the security ones? > > b) Will this WG consider new extensions to HTTP outside the main documents? My preferred answer to both is "no", because I really doubt that we'll be able to finish in a reasonable amount of time. > If the answer to (a) is "no", then we need a second WG, which will > likely have a lot of membership overlap. To me, that seems non-optimal. I do agree that RFC2617 needs a revision as well, I'm just not sure that we currently have the right people to do it. If a BOF would show that there are people willing to work on this (and implementors willing to update their products), then fine... > I'm OK either way with (b), but hope that if the answer is "yes" that > they aren't even considered until all the other work is done first. Best regards, Julian From discuss-bounces@apps.ietf.org Wed May 30 14:28:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtSuE-0008Qy-DK; Wed, 30 May 2007 14:28:22 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtSuD-0008Qq-DJ for discuss-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 14:28:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtSuD-0008Qi-3Y for discuss@apps.ietf.org; Wed, 30 May 2007 14:28:21 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HtSuB-0005mK-Mc for discuss@apps.ietf.org; Wed, 30 May 2007 14:28:21 -0400 Received: (qmail invoked by alias); 30 May 2007 18:28:18 -0000 Received: from p508F99AB.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.153.171] by mail.gmx.net (mp003) with SMTP; 30 May 2007 20:28:18 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18wwIMCifgwHB01r7G8F2QOrT+vk+/lNgswoRRW/X Er6QSHmCoOliDQ Message-ID: <465DC23D.6050303@gmx.de> Date: Wed, 30 May 2007 20:28:13 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Keith Moore Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <465D987F.5070906@cisco.com> <465DAE5B.2070605@cs.utk.edu> In-Reply-To: <465DAE5B.2070605@cs.utk.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Paul Hoffman , Apps Discuss , Mark Nottingham , "ietf-http-wg@w3.org Group" , Eliot Lear X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Keith Moore wrote: > ... > IMHO, the first work item of httpbis should be a defect list for http > 1.1 and associated documents. The next step would be to assess which Preparations have started for this at . > ... Best regards, Julian From discuss-bounces@apps.ietf.org Wed May 30 17:20:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtVay-0006Q2-H6; Wed, 30 May 2007 17:20:40 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtVax-0006Ps-42 for discuss-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 17:20:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtVaw-0006Pk-Qa for discuss@apps.ietf.org; Wed, 30 May 2007 17:20:38 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HtVav-0003qj-E3 for discuss@apps.ietf.org; Wed, 30 May 2007 17:20:38 -0400 Received: (qmail invoked by alias); 30 May 2007 21:20:36 -0000 Received: from p508F99AB.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.153.171] by mail.gmx.net (mp035) with SMTP; 30 May 2007 23:20:36 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/PPT0l033P8QAIOTVdzDqylVz1i40z9eFIhsK+xP 6DiIsgek/adG8O Message-ID: <465DEA9C.2060508@gmx.de> Date: Wed, 30 May 2007 23:20:28 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Eliot Lear Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <465D987F.5070906@cisco.com> In-Reply-To: <465D987F.5070906@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Paul Hoffman , Apps Discuss , Mark Nottingham , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Eliot Lear wrote: > Julian Reschke wrote: >> For instance, RFC2617 needs a revision badly as well (for instance, >> wrt to I18N of usernames and passwords, and, as far as I can recall, >> certain problems with the definition of Digest Auth). IMHO; this >> should occur in a separate working group. > > The HTTP auth model needs a lot of work. Creating an update without > addressing it seems to me pointless. Well, RFC2616 needs updating, so does RFC2617. Why does this need to be the same activity? Best regards, Julian From discuss-bounces@apps.ietf.org Wed May 30 18:54:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtX4E-0004U0-2n; Wed, 30 May 2007 18:54:58 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtX4C-0004T6-Ob for discuss-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 18:54:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtX4C-0004Sh-D6 for discuss@apps.ietf.org; Wed, 30 May 2007 18:54:56 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtX43-0005rz-Ts for discuss@apps.ietf.org; Wed, 30 May 2007 18:54:56 -0400 Received: from [192.168.1.102] (unknown [59.167.129.121]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 4AA71519A9; Wed, 30 May 2007 18:54:44 -0400 (EDT) In-Reply-To: References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <465D9BF4.40707@gmx.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: Straw-man charter for http-bis Date: Thu, 31 May 2007 08:54:40 +1000 To: Paul Hoffman X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Apps Discuss , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On 31/05/2007, at 2:47 AM, Paul Hoffman wrote: > > Splitting my previous question into two: > > a) Will this WG consider clarifications and revisions to main-line > HTTP-related RFCs, most notably the security ones? There's been talk of incorporating parts of others (e.g., authority for the status code registry) or more prominent references (e.g., to 2145). The big question at this point is whether 2617 will be directly included in the charter. > b) Will this WG consider new extensions to HTTP outside the main > documents? I think that's an emphatic "no". It can always be re-chartered if that seems wise down the road. Cheers, -- Mark Nottingham http://www.mnot.net/ From discuss-bounces@apps.ietf.org Wed May 30 18:55:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtX4j-000536-AO; Wed, 30 May 2007 18:55:29 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtX4i-00051f-Ao for discuss-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 18:55:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtX4i-00051T-11 for discuss@apps.ietf.org; Wed, 30 May 2007 18:55:28 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtX4g-000694-LE for discuss@apps.ietf.org; Wed, 30 May 2007 18:55:28 -0400 Received: from [10.20.30.108] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l4UMtM3f057048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 May 2007 15:55:23 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <465DEA9C.2060508@gmx.de> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <465D987F.5070906@cisco.com> <465DEA9C.2060508@gmx.de> Date: Wed, 30 May 2007 15:55:19 -0700 To: Julian Reschke , Eliot Lear From: Paul Hoffman Subject: Re: Straw-man charter for http-bis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Apps Discuss , Mark Nottingham , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org At 11:20 PM +0200 5/30/07, Julian Reschke wrote: >Eliot Lear wrote: >>Julian Reschke wrote: >>>For instance, RFC2617 needs a revision badly as well (for >>>instance, wrt to I18N of usernames and passwords, and, as far as I >>>can recall, certain problems with the definition of Digest Auth). >>>IMHO; this should occur in a separate working group. >> >>The HTTP auth model needs a lot of work. Creating an update >>without addressing it seems to me pointless. > >Well, RFC2616 needs updating, so does RFC2617. Why does this need to >be the same activity? If the effort for the two are temporally linked (they have to be done at the same time), and there will be a lot of overlap in the groups working on the two (that is, HTTP implementers and HTTP weenies are needed for both efforts), having two WGs seems like a waste of resources. From discuss-bounces@apps.ietf.org Wed May 30 18:58:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtX7y-0007E5-8I; Wed, 30 May 2007 18:58:50 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtX7w-0007Dz-L5 for discuss-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 18:58:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtX7w-0007Dr-BV for discuss@apps.ietf.org; Wed, 30 May 2007 18:58:48 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtX7v-0006rT-4C for discuss@apps.ietf.org; Wed, 30 May 2007 18:58:48 -0400 Received: from [192.168.1.102] (unknown [59.167.129.121]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id E73F65194C; Wed, 30 May 2007 18:58:44 -0400 (EDT) In-Reply-To: <465D987F.5070906@cisco.com> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <465D987F.5070906@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: Straw-man charter for http-bis Date: Thu, 31 May 2007 08:58:41 +1000 To: Eliot Lear X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Paul Hoffman , "ietf-http-wg@w3.org Group" , Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On 31/05/2007, at 1:30 AM, Eliot Lear wrote: > The HTTP auth model needs a lot of work. Agreed. > Creating an update without addressing it seems to me pointless. Not to me. The scope of the two activities is vastly different; I've only seen support for doing minor changes and clarifications to 2616, while 2617 needs wholesale revision or replacement in many eyes. To be fair, there are some small clarification/editorial-type issues (e.g., encoding of credentials) in 2617 that could be addressed by this style of charter. The concern that I have is that a) it would be difficult to keep the lid on and limit it to just those changes, and b) doing so would do a lot of good in the world, considering Kieth's point. Paul just noted that if the efforts are temporally linked, doing them separately is a waste of resources. I'm wondering if they are; e.g., could a WG do 2616bis, and then be re-chartered to do 2617bis (with a similar scope)? Cheers, -- Mark Nottingham http://www.mnot.net/ From discuss-bounces@apps.ietf.org Wed May 30 20:14:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtYIu-0002kg-0X; Wed, 30 May 2007 20:14:12 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtYIs-0002kb-Vy for discuss-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 20:14:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtYIs-0002kT-Lx for discuss@apps.ietf.org; Wed, 30 May 2007 20:14:10 -0400 Received: from chip2og53.obsmtp.com ([64.18.13.43]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HtYIq-0002K2-S9 for discuss@apps.ietf.org; Wed, 30 May 2007 20:14:10 -0400 Received: from source ([192.150.11.134]) by chip2ob53.postini.com ([64.18.5.12]) with SMTP; Wed, 30 May 2007 17:13:36 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l4V0CXbg012261; Wed, 30 May 2007 17:12:38 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l4V0DI0g016369; Wed, 30 May 2007 17:13:25 -0700 (PDT) Received: from namail1.corp.adobe.com ([10.8.192.62]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 17:13:20 -0700 Received: from masinterlap06 ([153.32.47.39]) by namail1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 17:13:17 -0700 From: "Larry Masinter" To: "'Mark Nottingham'" , "'Eliot Lear'" References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <465D987F.5070906@cisco.com> In-Reply-To: Subject: RE: Straw-man charter for http-bis Date: Wed, 30 May 2007 17:13:15 -0700 Message-ID: <000c01c7a318$7bc243e0$7346cba0$@org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcejDh3oBPtTP2QjTwCt5VjVvGiV4QACKMAA Content-Language: en-us X-OriginalArrivalTime: 31 May 2007 00:13:17.0764 (UTC) FILETIME=[7D27A040:01C7A318] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: 'Paul Hoffman' , ietf-http-wg@w3.org, 'Apps Discuss' X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org I'm sympathetic to the desire to keep the charter narrow, but I wonder if it is feasible to update 2616 without updating 2617. I thought that it was more of a convenience and that the split between the two was (to some degree) artificial. If you really want to limit scope, what do you think about issuing an informational RFC on 'what changes are needed to 2617' (starting with the Sayre draft, I'd think)? Then 2616bis could be published and the group rechartered to do the 2617 update (and, if needed, yet another turn of the crank on 2616bisbis.) Larry From discuss-bounces@apps.ietf.org Thu May 31 00:20:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htc8r-0002mj-Q2; Thu, 31 May 2007 00:20:05 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Htc8r-0002me-Bk for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 00:20:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htc8r-0002mW-1i for discuss@apps.ietf.org; Thu, 31 May 2007 00:20:05 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htc8o-00053m-Qy for discuss@apps.ietf.org; Thu, 31 May 2007 00:20:05 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id AEF351EE1B5; Thu, 31 May 2007 00:19:57 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbK2txfK7HKU; Thu, 31 May 2007 00:19:48 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 07BB71EE1AC; Thu, 31 May 2007 00:19:35 -0400 (EDT) Message-ID: <465E4CD3.30106@cs.utk.edu> Date: Thu, 31 May 2007 00:19:31 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Paul Hoffman Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <465D987F.5070906@cisco.com> <465DEA9C.2060508@gmx.de> In-Reply-To: X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Apps Discuss , Mark Nottingham , "ietf-http-wg@w3.org Group" , Eliot Lear X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >> Well, RFC2616 needs updating, so does RFC2617. Why does this need to >> be the same activity? > > If the effort for the two are temporally linked (they have to be done > at the same time), and there will be a lot of overlap in the groups > working on the two (that is, HTTP implementers and HTTP weenies are > needed for both efforts), having two WGs seems like a waste of resources. I'm thinking that perhaps RFC2617 should be moved to historic. From discuss-bounces@apps.ietf.org Thu May 31 00:23:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtcBx-0004qo-G5; Thu, 31 May 2007 00:23:17 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtcBv-0004n4-JV for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 00:23:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtcBv-0004kt-7v for discuss@apps.ietf.org; Thu, 31 May 2007 00:23:15 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtcBs-00065l-Vf for discuss@apps.ietf.org; Thu, 31 May 2007 00:23:15 -0400 Received: from [127.0.0.1] (unknown [216.145.54.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 5C90A5197D; Thu, 31 May 2007 00:23:10 -0400 (EDT) In-Reply-To: <000c01c7a318$7bc243e0$7346cba0$@org> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <465D987F.5070906@cisco.com> <000c01c7a318$7bc243e0$7346cba0$@org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: Straw-man charter for http-bis -- call for errata/clarifications to 2617 Date: Thu, 31 May 2007 14:23:06 +1000 To: Larry Masinter X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: 'Paul Hoffman' , ietf-http-wg@w3.org, 'Eliot Lear' , 'Apps Discuss' X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On 31/05/2007, at 10:13 AM, Larry Masinter wrote: > I'm sympathetic to the desire to keep the charter narrow, but I wonder > if it is feasible to update 2616 without updating 2617. I thought > that it was more of a convenience and that the split between > the two was (to some degree) artificial. > > If you really want to limit scope, what do you think about > issuing an informational RFC on 'what changes are needed to 2617' > (starting with the Sayre draft, I'd think)? Then 2616bis > could be published and the group rechartered to do the > 2617 update (and, if needed, yet another turn of the crank > on 2616bisbis.) Robert's draft is orthogonal to a 2617 update; the idea of that is to address the need for MTI security. It would be interesting to compile issues for 2617 as well, to see what the scope of work would be. If we can keep the scope to errata and clarifications (i.e., not introducing new schemes), it might be doable. Anybody? -- Mark Nottingham http://www.mnot.net/ From discuss-bounces@apps.ietf.org Thu May 31 03:37:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtfDz-0007g7-FD; Thu, 31 May 2007 03:37:35 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtfDz-0007g2-79 for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 03:37:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtfDy-0007fu-Jk for discuss@apps.ietf.org; Thu, 31 May 2007 03:37:34 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtfDx-0001pc-Ad for discuss@apps.ietf.org; Thu, 31 May 2007 03:37:34 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 31 May 2007 09:37:33 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l4V7bWhF030099; Thu, 31 May 2007 09:37:32 +0200 Received: from adsl-247-6-fixip.tiscali.ch (ams3-vpn-dhcp169.cisco.com [10.61.64.169]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4V7bJDR012225; Thu, 31 May 2007 07:37:19 GMT Message-ID: <465E7B2F.8010304@cisco.com> Date: Thu, 31 May 2007 09:37:19 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Yves Lafon Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <465D987F.5070906@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=346; t=1180597052; x=1181461052; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20Straw-man=20charter=20for=20http-bis |Sender:=20; bh=GBX6R2GK0WWn/+gn8+2QSX9AGGAhjWrM2KXmn11+Cys=; b=nvrc/a8bGtf+0hCchLJrl5rZD6/LCW9d2QmYrZUn4EcTSdeRj7+86fQ3U+eDsDaxmcxt1JXz Yy33w8oxLINqGUF61Fr2WrTgqAZpIrLTFuyzvtKJ8jUzwXWgot8hoxqh; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: Paul Hoffman , Mark Nottingham , "ietf-http-wg@w3.org Group" , Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org An authentication requirements document sits in "Last Call" right now as we speak. My concern is that we'll close 2616bis only to discover that not only do we need a 2617bis but also a 2616bisbis. The only real question is whether or not we can move fast enough on the auth work so that you're not left twiddling your thumbs too long. From discuss-bounces@apps.ietf.org Thu May 31 04:15:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htfoc-0003dJ-VJ; Thu, 31 May 2007 04:15:26 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Htfoc-0003dE-Ax for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 04:15:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htfoc-0003d6-1D for discuss@apps.ietf.org; Thu, 31 May 2007 04:15:26 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Htfob-0003rk-HS for discuss@apps.ietf.org; Thu, 31 May 2007 04:15:26 -0400 Received: (qmail invoked by alias); 31 May 2007 08:15:24 -0000 Received: from p508fa20f.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.162.15] by mail.gmx.net (mp010) with SMTP; 31 May 2007 10:15:24 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+IRmdCqx+IUuzL8FYKu72BFQ7u1xChlXNGmlQLzw 0bFNqQDYqkcayV Message-ID: <465E8416.2020302@gmx.de> Date: Thu, 31 May 2007 10:15:18 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Paul Hoffman Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <465D987F.5070906@cisco.com> <465DEA9C.2060508@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Apps Discuss , Mark Nottingham , "ietf-http-wg@w3.org Group" , Eliot Lear X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Paul Hoffman wrote: > If the effort for the two are temporally linked (they have to be done at > the same time), and there will be a lot of overlap in the groups working > on the two (that is, HTTP implementers and HTTP weenies are needed for > both efforts), having two WGs seems like a waste of resources. Good point. I think they can be done separately, that is, there can be a RFC2616bis without a RFC2617bis. RFC2616bis would just continue to refer to RFC2617, which at some point of time would be obsoleted by its revision. Am I missing something? Best regards, Julian From discuss-bounces@apps.ietf.org Thu May 31 04:20:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtftL-0006Aw-5m; Thu, 31 May 2007 04:20:19 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtftK-0006AO-Df for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 04:20:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtftK-0006AE-3E for discuss@apps.ietf.org; Thu, 31 May 2007 04:20:18 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HtftI-0004or-LY for discuss@apps.ietf.org; Thu, 31 May 2007 04:20:18 -0400 Received: (qmail invoked by alias); 31 May 2007 08:20:15 -0000 Received: from p508FA20F.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.162.15] by mail.gmx.net (mp054) with SMTP; 31 May 2007 10:20:15 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX191mSIJaqF1Yd5VT9sy1EBT5F3rfgZyuI1+mbDbyY odQhPMpTLETaCx Message-ID: <465E853A.9010405@gmx.de> Date: Thu, 31 May 2007 10:20:10 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Robert Sayre Subject: Re: Straw-man charter for http-bis -- call for errata/clarifications to 2617 References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <465D987F.5070906@cisco.com> <000c01c7a318$7bc243e0$7346cba0$@org> <68fba5c50705302228v7f8ab278y50cf38c9f971f0a3@mail.gmail.com> In-Reply-To: <68fba5c50705302228v7f8ab278y50cf38c9f971f0a3@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Eliot Lear , Larry Masinter , Apps Discuss , Mark Nottingham , ietf-http-wg@w3.org, Paul Hoffman X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Robert Sayre wrote: > > On 5/31/07, Mark Nottingham wrote: >> >> Robert's draft is orthogonal to a 2617 update; the idea of that is to >> address the need for MTI security. > > My draft is orthogonal to things that are unimplementable, because it > seeks to document what has actually happened, and why it did. It may Can somebody please remind me what that draft is? It's not , right? > My feeling is that the current schemes can be updated by documenting > the internationalization behavior of popular implementations, but > nothing else is worth doing. I think that really needs to be done, and if the charter would restrict changes to RFC2617 to do just that, that might be feasible. Best regards, Julian From discuss-bounces@apps.ietf.org Thu May 31 04:21:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htfu8-0006K0-FM; Thu, 31 May 2007 04:21:08 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Htfu7-0006Je-5l for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 04:21:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htfu6-0006JV-SE for discuss@apps.ietf.org; Thu, 31 May 2007 04:21:06 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Htfu5-0004sm-FL for discuss@apps.ietf.org; Thu, 31 May 2007 04:21:06 -0400 Received: (qmail invoked by alias); 31 May 2007 08:21:04 -0000 Received: from p508FA20F.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.162.15] by mail.gmx.net (mp053) with SMTP; 31 May 2007 10:21:04 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+GGXd4D8CG+ZIputf7vf51+wT55RRL/lilof/ETB enJ1ayejkp6Ohb Message-ID: <465E8569.7080504@gmx.de> Date: Thu, 31 May 2007 10:20:57 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Eliot Lear Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <465D987F.5070906@cisco.com> <465E7B2F.8010304@cisco.com> In-Reply-To: <465E7B2F.8010304@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Yves Lafon , Paul Hoffman , Mark Nottingham , "ietf-http-wg@w3.org Group" , Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Eliot Lear wrote: > An authentication requirements document sits in "Last Call" right now as > we speak. My concern is that we'll close 2616bis only to discover that > not only do we need a 2617bis but also a 2616bisbis. The only real > question is whether or not we can move fast enough on the auth work so > that you're not left twiddling your thumbs too long. Pointer, please :-). Best regards, Julian From discuss-bounces@apps.ietf.org Thu May 31 05:22:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htgre-00011z-KY; Thu, 31 May 2007 05:22:38 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Htgrc-00011p-Hk for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 05:22:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htgrb-00011h-M0 for discuss@apps.ietf.org; Thu, 31 May 2007 05:22:35 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtgrZ-0003ej-CD for discuss@apps.ietf.org; Thu, 31 May 2007 05:22:35 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 31 May 2007 11:22:29 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4V9MSaq008784; Thu, 31 May 2007 11:22:28 +0200 Received: from adsl-247-6-fixip.tiscali.ch (ams3-vpn-dhcp169.cisco.com [10.61.64.169]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4V9MNDR015724; Thu, 31 May 2007 09:22:23 GMT Message-ID: <465E93CF.9060603@cisco.com> Date: Thu, 31 May 2007 11:22:23 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Julian Reschke Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <465D987F.5070906@cisco.com> <465E7B2F.8010304@cisco.com> <465E8569.7080504@gmx.de> In-Reply-To: <465E8569.7080504@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=204; t=1180603348; x=1181467348; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20Straw-man=20charter=20for=20http-bis |Sender:=20; bh=kYGDdShtOmQwSMlKsBpLeNJ2a6nJxoGebJMy1KUREcI=; b=uPQfOzJxILL9KnA+aPUHw8PxhfUzC4k5e/NaCN8CiUy3LWnLe6FZifZDulZScjnB67chvXNq xSikLq4hYoozFH28Era4yP5JILMJACYTjByUtcNC2la+pt3cRnIHwlBw; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Yves Lafon , Paul Hoffman , Mark Nottingham , "ietf-http-wg@w3.org Group" , Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Julian Reschke wrote: > Eliot Lear wrote: >> An authentication requirements document sits in "Last Call" right now >> as we speak. > > Pointer, please :-). draft-hartman-webauth-phishing-03.txt From discuss-bounces@apps.ietf.org Thu May 31 06:53:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtiHJ-0000qT-ND; Thu, 31 May 2007 06:53:13 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtiHI-0000qO-VS for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 06:53:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtiHI-0000qE-L9 for discuss@apps.ietf.org; Thu, 31 May 2007 06:53:12 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtiHH-00031d-Dh for discuss@apps.ietf.org; Thu, 31 May 2007 06:53:12 -0400 Received: from [192.168.1.102] (unknown [59.167.129.121]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 404F051981; Thu, 31 May 2007 06:53:06 -0400 (EDT) In-Reply-To: <465E7B2F.8010304@cisco.com> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <465D987F.5070906@cisco.com> <465E7B2F.8010304@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <35A8B74A-E78B-4A8B-85C1-7FCE72A7CE49@mnot.net> Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: Straw-man charter for http-bis Date: Thu, 31 May 2007 20:53:03 +1000 To: Eliot Lear X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Yves Lafon , Paul Hoffman , "ietf-http-wg@w3.org Group" , Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Considering the scope of 2616bis is errata, and explicitly not new features/mechanisms, I'm not sure I follow. Do you think that designing new auth mechanisms will expose new errata? My initial thought is that it's much more likely that it'll require who new features, or no changes to HTTP at all. On 31/05/2007, at 5:37 PM, Eliot Lear wrote: > An authentication requirements document sits in "Last Call" right > now as we speak. My concern is that we'll close 2616bis only to > discover that not only do we need a 2617bis but also a 2616bisbis. > The only real question is whether or not we can move fast enough on > the auth work so that you're not left twiddling your thumbs too long. -- Mark Nottingham http://www.mnot.net/ From discuss-bounces@apps.ietf.org Thu May 31 08:13:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtjWa-0004xh-H2; Thu, 31 May 2007 08:13:04 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtjWa-0004xY-21 for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 08:13:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtjWZ-0004xQ-OX for discuss@apps.ietf.org; Thu, 31 May 2007 08:13:03 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtjWX-000561-H8 for discuss@apps.ietf.org; Thu, 31 May 2007 08:13:03 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 31 May 2007 14:13:01 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4VCD057029824; Thu, 31 May 2007 14:13:00 +0200 Received: from adsl-247-6-fixip.tiscali.ch (ams3-vpn-dhcp169.cisco.com [10.61.64.169]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4VCCsDR008038; Thu, 31 May 2007 12:12:59 GMT Message-ID: <465EBBC7.9030800@cisco.com> Date: Thu, 31 May 2007 14:12:55 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Mark Nottingham Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <465D987F.5070906@cisco.com> <465E7B2F.8010304@cisco.com> <35A8B74A-E78B-4A8B-85C1-7FCE72A7CE49@mnot.net> In-Reply-To: <35A8B74A-E78B-4A8B-85C1-7FCE72A7CE49@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=470; t=1180613580; x=1181477580; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20Straw-man=20charter=20for=20http-bis |Sender:=20; bh=x9kOVRhtmZTJflmpKWoGCWcAoJWV1hkxJkA85icJfXo=; b=TgoMqFIbm1RGk5Z0lvdgRYQb5Jg0C1HtjnIBVsNV15yHmRlRR/MwlRJYGxCOAGMiBq9aCEJ8 72NmQpnrV+uGi4gUY1cHJ3uXEQVUlRt/gPkCycuYUzCmZmiH5+pURbhP; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Yves Lafon , Paul Hoffman , "ietf-http-wg@w3.org Group" , Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Mark, > Considering the scope of 2616bis is errata, and explicitly not new > features/mechanisms, I'm not sure I follow. Do you think that > designing new auth mechanisms will expose new errata? > > My initial thought is that it's much more likely that it'll require > who new features, or no changes to HTTP at all. If you do the errata and then we need any update to cover authentication - whatsoever - we end up with bisbis. That's my point. Eliot From discuss-bounces@apps.ietf.org Thu May 31 08:19:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htjd7-0000Np-El; Thu, 31 May 2007 08:19:49 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Htjd5-0000Ef-Ng for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 08:19:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htjd5-0000Ct-DC for discuss@apps.ietf.org; Thu, 31 May 2007 08:19:47 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Htjd4-0006JN-0O for discuss@apps.ietf.org; Thu, 31 May 2007 08:19:47 -0400 Received: (qmail invoked by alias); 31 May 2007 12:19:44 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.87]) [217.91.35.233] by mail.gmx.net (mp037) with SMTP; 31 May 2007 14:19:44 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/yjqVEv4zycgYN7ck5FxtGUf/6F9Sqwgkg2K+6mq wplU/aR3DE96Zd Message-ID: <465EBD5D.3090208@gmx.de> Date: Thu, 31 May 2007 14:19:41 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Eliot Lear Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <465D987F.5070906@cisco.com> <465E7B2F.8010304@cisco.com> <35A8B74A-E78B-4A8B-85C1-7FCE72A7CE49@mnot.net> <465EBBC7.9030800@cisco.com> In-Reply-To: <465EBBC7.9030800@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Yves Lafon , Paul Hoffman , Mark Nottingham , "ietf-http-wg@w3.org Group" , Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Eliot Lear wrote: > Mark, >> Considering the scope of 2616bis is errata, and explicitly not new >> features/mechanisms, I'm not sure I follow. Do you think that >> designing new auth mechanisms will expose new errata? >> >> My initial thought is that it's much more likely that it'll require >> who new features, or no changes to HTTP at all. > > If you do the errata and then we need any update to cover authentication > - whatsoever - we end up with bisbis. That's my point. But that would be an update to RCF2617, not RFC2616bis, right? Best regards, Julian From discuss-bounces@apps.ietf.org Thu May 31 08:23:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtjgR-0001t3-HV; Thu, 31 May 2007 08:23:15 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtjgQ-0001sw-QB for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 08:23:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtjgQ-0001so-GX for discuss@apps.ietf.org; Thu, 31 May 2007 08:23:14 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtjgP-0006zo-7u for discuss@apps.ietf.org; Thu, 31 May 2007 08:23:14 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 31 May 2007 14:23:13 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l4VCNCnY024178; Thu, 31 May 2007 14:23:12 +0200 Received: from adsl-247-6-fixip.tiscali.ch (ams3-vpn-dhcp169.cisco.com [10.61.64.169]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4VCNBDR011376; Thu, 31 May 2007 12:23:11 GMT Message-ID: <465EBE30.4040802@cisco.com> Date: Thu, 31 May 2007 14:23:12 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Julian Reschke Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <465D987F.5070906@cisco.com> <465E7B2F.8010304@cisco.com> <35A8B74A-E78B-4A8B-85C1-7FCE72A7CE49@mnot.net> <465EBBC7.9030800@cisco.com> <465EBD5D.3090208@gmx.de> In-Reply-To: <465EBD5D.3090208@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=119; t=1180614192; x=1181478192; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20Straw-man=20charter=20for=20http-bis |Sender:=20; bh=kFVsSiqEJkcdgKIGSyaHYZkbM2utG5qdWk5FLkH26mI=; b=bxYjZdYOjtlajP8s/8Isf3HMhB/GZsxUP4vZxEmBxhqMpbe2qSCs4wXq+D0MBIIjpDcsBoAx 9DhljBM4N4Pozq9Yws8j/gEwZrQw0psx+HZugwF6DBLIt6O/8noByGfN; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Cc: Yves Lafon , Paul Hoffman , Mark Nottingham , "ietf-http-wg@w3.org Group" , Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Julian Reschke wrote: > But that would be an update to RCF2617, not RFC2616bis, right? Do we know enough to know? From discuss-bounces@apps.ietf.org Thu May 31 08:25:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtjiV-0002IH-Fi; Thu, 31 May 2007 08:25:23 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtjiU-0002I9-ER for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 08:25:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtjiU-0002Hz-4e for discuss@apps.ietf.org; Thu, 31 May 2007 08:25:22 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HtjiS-0007Jj-IM for discuss@apps.ietf.org; Thu, 31 May 2007 08:25:22 -0400 Received: (qmail invoked by alias); 31 May 2007 12:25:19 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.87]) [217.91.35.233] by mail.gmx.net (mp023) with SMTP; 31 May 2007 14:25:19 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX198r6Bsmn18l+yXXQZaDqnYRjgRhyuRnafd4azR6N 0uXSSwpqwICccv Message-ID: <465EBEAA.30104@gmx.de> Date: Thu, 31 May 2007 14:25:14 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Eliot Lear Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <465D987F.5070906@cisco.com> <465E7B2F.8010304@cisco.com> <35A8B74A-E78B-4A8B-85C1-7FCE72A7CE49@mnot.net> <465EBBC7.9030800@cisco.com> <465EBD5D.3090208@gmx.de> <465EBE30.4040802@cisco.com> In-Reply-To: <465EBE30.4040802@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Yves Lafon , Paul Hoffman , Mark Nottingham , "ietf-http-wg@w3.org Group" , Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Eliot Lear wrote: > Julian Reschke wrote: >> But that would be an update to RCF2617, not RFC2616bis, right? > > Do we know enough to know? Well, RFC2616 doesn't define authentication, it relies on RFC2617. So as long as we keep that separation, I don't see any problem. Of course I'm making the assumption that we don't want to change this. Best regards, Julian From discuss-bounces@apps.ietf.org Thu May 31 09:08:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtkO7-0003BW-Nq; Thu, 31 May 2007 09:08:23 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtkO6-00036I-IL for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 09:08:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtkO6-000341-6p for discuss@apps.ietf.org; Thu, 31 May 2007 09:08:22 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HtkO4-0007VQ-P1 for discuss@apps.ietf.org; Thu, 31 May 2007 09:08:22 -0400 Received: (qmail invoked by alias); 31 May 2007 13:08:19 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.87]) [217.91.35.233] by mail.gmx.net (mp004) with SMTP; 31 May 2007 15:08:19 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+unpsVvk2uirUZSp6os7bWEiq3Gvj0FNC0e6+RtE GLNqEF3L2EPRsq Message-ID: <465EC8C0.1020700@gmx.de> Date: Thu, 31 May 2007 15:08:16 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Robert Sayre Subject: Re: Straw-man charter for http-bis -- call for errata/clarifications to 2617 References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <465D987F.5070906@cisco.com> <000c01c7a318$7bc243e0$7346cba0$@org> <68fba5c50705302228v7f8ab278y50cf38c9f971f0a3@mail.gmail.com> <465E853A.9010405@gmx.de> <68fba5c50705310602k1fca8c23xdb8fe2fa932ba933@mail.gmail.com> In-Reply-To: <68fba5c50705310602k1fca8c23xdb8fe2fa932ba933@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Eliot Lear , Larry Masinter , Apps Discuss , Mark Nottingham , ietf-http-wg@w3.org, Paul Hoffman X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Robert Sayre wrote: > On 5/31/07, Julian Reschke wrote: >> Robert Sayre wrote: >> > >> > On 5/31/07, Mark Nottingham wrote: >> >> >> >> Robert's draft is orthogonal to a 2617 update; the idea of that is to >> >> address the need for MTI security. >> > >> > My draft is orthogonal to things that are unimplementable, because it >> > seeks to document what has actually happened, and why it did. It may >> >> Can somebody please remind me what that draft is? It's not >> , right? > > Nope, it's here: > ...so, are you going to submit it as an ID? Best regards, Julian (I think it would be a good starting point for future work on RFC2617) From discuss-bounces@apps.ietf.org Thu May 31 09:42:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtkvI-0002Zs-Sd; Thu, 31 May 2007 09:42:40 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtkvH-0002WL-6x for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 09:42:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtkvG-0002Ug-T0 for discuss@apps.ietf.org; Thu, 31 May 2007 09:42:38 -0400 Received: from piper.mulberrymail.com ([151.201.22.177] helo=mulberrymail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtkvF-0006Vs-HI for discuss@apps.ietf.org; Thu, 31 May 2007 09:42:38 -0400 Received: from [17.101.35.92] ([17.101.35.92]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l4VDgSew025020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 May 2007 09:42:31 -0400 Date: Thu, 31 May 2007 09:42:22 -0400 From: Cyrus Daboo To: Robert Sayre , Mark Nottingham Subject: Re: Straw-man charter for http-bis -- call for errata/clarifications to 2617 Message-ID: In-Reply-To: <68fba5c50705302228v7f8ab278y50cf38c9f971f0a3@mail.gmail.com> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <465D987F.5070906@cisco.com> <000c01c7a318$7bc243e0$7346cba0$@org> <68fba5c50705302228v7f8ab278y50cf38c9f971f0a3@mail.gmail.com> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on piper.mulberrymail.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Eliot Lear , Larry Masinter , Apps Discuss , ietf-http-wg@w3.org, Paul Hoffman X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi Robert, --On May 31, 2007 1:28:39 AM -0400 Robert Sayre wrote: > My feeling is that the current schemes can be updated by documenting > the internationalization behavior of popular implementations, but > nothing else is worth doing. I disagree. I think we need to go a lot further. My suggestion would be to throw away 2617 as-is, and instead do something more akin to the SASL document set, i.e. a "framework" document describing the general issues of http authentication that lays out the ground-work for the existing http-based auth schemes, plus documents other auth schemes in use (form-based, cookie-based etc). We then have separate documents for each of the http-based schemes basic and digest - and we should add Kerberos/SPNEGO to that too. Having those as separate documents will make updates in the future an easier process. If we want to document other types in more detail (as proposed or informational) that could be done too. I would also like to see the "webmail" (proxying credentials though a web-app to some back end service) issue dealt with too - ideally with the Kerberos mechanism as a basis (and others too that make sense). I think all that is a lot more work than just a quick rev of 2617. Given that it involves a lot of security there will be a need to have the direct participation of the Security area folks. They are less likely to be interested in the minutiae of 2616bis though. So I think separate working groups would be better because of the different cross-area participation requirements. -- Cyrus Daboo From discuss-bounces@apps.ietf.org Thu May 31 11:27:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtmZ6-0004sM-Hk; Thu, 31 May 2007 11:27:52 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtmZ4-0004sH-Uv for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 11:27:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtmZ4-0004s9-LL for discuss@apps.ietf.org; Thu, 31 May 2007 11:27:50 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtmZ2-0003Tg-E6 for discuss@apps.ietf.org; Thu, 31 May 2007 11:27:50 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 5C8A11EE1D8; Thu, 31 May 2007 11:27:45 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4suUZ0p7uOe0; Thu, 31 May 2007 11:27:03 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id CB4EC1EE1DD; Thu, 31 May 2007 11:26:17 -0400 (EDT) Message-ID: <465EE917.3010308@cs.utk.edu> Date: Thu, 31 May 2007 11:26:15 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Mark Nottingham Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <465D987F.5070906@cisco.com> <465E7B2F.8010304@cisco.com> <35A8B74A-E78B-4A8B-85C1-7FCE72A7CE49@mnot.net> In-Reply-To: <35A8B74A-E78B-4A8B-85C1-7FCE72A7CE49@mnot.net> X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Yves Lafon , Paul Hoffman , "ietf-http-wg@w3.org Group" , Eliot Lear , Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Mark Nottingham wrote: > Considering the scope of 2616bis is errata, and explicitly not new > features/mechanisms, I'm not sure I follow. Do you think that > designing new auth mechanisms will expose new errata? > > My initial thought is that it's much more likely that it'll require > who new features, or no changes to HTTP at all. I think it likely that some minor enhancements to HTTP will be needed by a new authentication method. However I don't know that this would require an update to the base HTTP specification; a separate document might be sufficient. The more I think about it, the more I believe that a separate working group for HTTP security is needed. This work should not need to be critical path for httpbis. From discuss-bounces@apps.ietf.org Thu May 31 17:16:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hts07-0002ck-0Q; Thu, 31 May 2007 17:16:07 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hts05-0002cf-6w for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 17:16:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hts04-0002cX-TX for discuss@apps.ietf.org; Thu, 31 May 2007 17:16:04 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hts03-0003F6-FG for discuss@apps.ietf.org; Thu, 31 May 2007 17:16:04 -0400 Received: from [127.0.0.1] (unknown [216.145.54.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id C54FB51937; Thu, 31 May 2007 17:16:00 -0400 (EDT) In-Reply-To: <1358AF2C-F967-46D6-B291-BC65126CCDF6@gbiv.com> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <1358AF2C-F967-46D6-B291-BC65126CCDF6@gbiv.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8FBD37BC-E635-485D-A368-22D9DE332498@mnot.net> Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: Straw-man charter for http-bis Date: Fri, 1 Jun 2007 07:15:57 +1000 To: Roy T. Fielding X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: Apps Discuss , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On 01/06/2007, at 5:10 AM, Roy T. Fielding wrote: > Just to reiterate what I have said before, I think it is absurd to > make > minor editorial modifications to RFC 2616 in a new revision. If minor > editorial changes are necessary right now, the RFC editor can make > them > with a simple set of instructions from the original authors. However, > I don't see them as necessary -- the existing list of errata is > sufficient until such time as the more pressing security issues can > be resolved in other specifications. I'm very aware of your feelings. I'm also aware of the pain that folks go through when they try to implement the current spec. Yes, some of that is caused by the organisation and committee-speak there, but much more is on very specific points where the spec is silent or misleading -- our issues list now has more than sixty issues. That this effort will help in those cases. No, it's not a magic pill, but a complete rewrite wouldn't be either, and it would have much less chance of success. > The reason that RFC 2616 had so many editorial mistakes is because the > RFC became completely unreadable due to far too much committee-driven > discussion being added in the revision from 2068 to 2616. > If an actual revision is desired for HTTP/1.1, then a ground-up reorg > of the specification and formal ABNF productions are necessary. > I don't care if that matches "group consensus desires" or not; > sometimes the work needs to be done regardless of popular opinion. > What matters is not what work the working group is willing to embark > upon, but what work the group is willing to review at the end. If I > completely rewrite the HTTP/1.1 specification without adding features, > and submit that new draft for review, will the working group consider > it to be out of scope? If not, then limiting the scope of changes > to the specification (aside from not adding new features) is > irrelevant > to the charter. If it will be out of scope, then I have no interest > in participating here and will fork the standard to a place that > isn't being driven by a short-term corporate agenda. Is your threat to attempt a fork of HTTP if you don't get your way a hypothetical, or something you're actually considering? Also, on what do you base the accusation that this is being driven by "short-term corporate agendas?" In any case, I don't think re-organising parts of the spec is off the table; indeed, it's already been discussed on a small scale. Re- writing the entire spec sentence-for-sentence is, in my opinion. > If an IETF HTTP WG is to be recreated, then its task items should be > to create what the working group believes to be the best documents > to replace 2616 and 2617. The charter does not need to constrain > that. That would be disruptive and unproductive. You may be willing to re- write HTTP from scratch, but the review requirements are much higher than required for what we're attempting (with step-by-step diffs, by the way). Somehow, HTTP has been implemented and become one of the most widely- deployed application protocols today, despite your claims that the spec needs to be re-written from scratch. I don't hear *anyone* else saying that this necessary, or a realistic option. > In any case, the IESG has expressed many times that an application > protocol will not move forward without providing a required solution > for secure authentication. Thus, it is foolish to start a 2616 > revision > without first completing some form of 2617 revision, whether or not > that includes new features for HTTP. That is not going to happen as > long as you guys are burning up all of the available HTTP reviewers' > time on irrelevant changes to 2616. This concern has already been discussed extensively, and as of Prague we believe we have a workable solution. Thanks, -- Mark Nottingham http://www.mnot.net/ From discuss-bounces@apps.ietf.org Thu May 31 17:16:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hts0g-00035B-7j; Thu, 31 May 2007 17:16:42 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hts0e-000356-Lq for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 17:16:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hts0e-00034y-CG for discuss@apps.ietf.org; Thu, 31 May 2007 17:16:40 -0400 Received: from piper.mulberrymail.com ([151.201.22.177] helo=mulberrymail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hts0d-0003O8-05 for discuss@apps.ietf.org; Thu, 31 May 2007 17:16:40 -0400 Received: from caldav.corp.apple.com ([17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l4VLG7vA026639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 May 2007 17:16:17 -0400 Date: Thu, 31 May 2007 17:16:02 -0400 From: Cyrus Daboo To: Henrik Nordstrom Subject: Re: Straw-man charter for http-bis -- call for errata/clarifications to 2617 Message-ID: In-Reply-To: <1180637848.4471.11.camel@henriknordstrom.net> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <465D987F.5070906@cisco.com> <000c01c7a318$7bc243e0$7346cba0$@org> <68fba5c50705302228v7f8ab278y50cf38c9f971f0a3@mail.gmail.com> <1180637848.4471.11.camel@henriknordstrom.net> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on piper.mulberrymail.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Eliot Lear , Larry Masinter , Robert Sayre , Apps Discuss , Mark Nottingham , ietf-http-wg@w3.org, Paul Hoffman X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi Henrik, --On May 31, 2007 8:57:28 PM +0200 Henrik Nordstrom wrote: >> (form-based, cookie-based etc). We then have separate documents for each >> of the http-based schemes basic and digest - and we should add >> Kerberos/SPNEGO to that too. > > Note: Both Kerberos & SPNEGO both break the foundations laid out by > RFC2616 and 2617, tying authentication to connections and not messages. Well there is already RFC4559 and some folks in the security area were working on tidying that up a bit more for a proposed standard. -- Cyrus Daboo From discuss-bounces@apps.ietf.org Thu May 31 17:39:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtsMe-0007Se-Hs; Thu, 31 May 2007 17:39:24 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtNuQ-0008LQ-4v for discuss-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 09:08:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtNuP-0008LI-Rb for discuss@apps.ietf.org; Wed, 30 May 2007 09:08:13 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtNuN-0004fL-Ht for discuss@apps.ietf.org; Wed, 30 May 2007 09:08:13 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 30 May 2007 14:08:10 +0100 Message-ID: <465D76EE.7060408@isode.com> Date: Wed, 30 May 2007 14:06:54 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Mark Nottingham Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> In-Reply-To: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-Mailman-Approved-At: Thu, 31 May 2007 17:39:23 -0400 Cc: Apps Discuss , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi Mark, Mark Nottingham wrote: > Aug 2008 - Submit HTTP Revision to IESG for consideration as a > Proposed Standard I think the target should be to move the document to Draft. From discuss-bounces@apps.ietf.org Thu May 31 17:39:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtsMe-0007Ud-Rs; Thu, 31 May 2007 17:39:24 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtOEl-0000z3-6T for discuss-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 09:29:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtOEk-0000yu-T6 for discuss@apps.ietf.org; Wed, 30 May 2007 09:29:14 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtOEj-00064j-H3 for discuss@apps.ietf.org; Wed, 30 May 2007 09:29:14 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 30 May 2007 14:29:11 +0100 Message-ID: <465D7BDB.1040706@isode.com> Date: Wed, 30 May 2007 14:27:55 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Julian Reschke Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D76EE.7060408@isode.com> <465D77F9.1010106@gmx.de> In-Reply-To: <465D77F9.1010106@gmx.de> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Thu, 31 May 2007 17:39:23 -0400 Cc: Apps Discuss , Mark Nottingham , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Julian Reschke wrote: > Alexey Melnikov wrote: > >> Hi Mark, >> >> Mark Nottingham wrote: >> >>> Aug 2008 - Submit HTTP Revision to IESG for consideration as a >>> Proposed Standard >> >> I think the target should be to move the document to Draft. > > Actually, it already *is* a Draft Standard, Good point. > so I think the target should be to *keep* it a Draft Standard, with an > eye on the possibility to actually get it to full Standard (which may > require creative solutions to the MIME dependencies). Right. I meant "move to Full or at least recycle as Draft". From discuss-bounces@apps.ietf.org Thu May 31 17:39:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtsMf-0007Wu-Fr; Thu, 31 May 2007 17:39:25 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hteyv-0005aO-Hi for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 03:22:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hteyq-0005TT-VP for discuss@apps.ietf.org; Thu, 31 May 2007 03:21:57 -0400 Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hteyn-00084R-GO for discuss@apps.ietf.org; Thu, 31 May 2007 03:21:56 -0400 Received: by homer.w3.org (Postfix, from userid 12961) id 564774F018; Thu, 31 May 2007 03:21:52 -0400 (EDT) Date: Thu, 31 May 2007 03:21:52 -0400 (EDT) From: Yves Lafon To: Mark Nottingham Subject: Re: Straw-man charter for http-bis In-Reply-To: Message-ID: References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <465D987F.5070906@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-Mailman-Approved-At: Thu, 31 May 2007 17:39:23 -0400 Cc: Paul Hoffman , "ietf-http-wg@w3.org Group" , Eliot Lear , Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Thu, 31 May 2007, Mark Nottingham wrote: >> Creating an update without addressing it seems to me pointless. > > Not to me. The scope of the two activities is vastly different; I've only= =20 > seen support for doing minor changes and clarifications to 2616, while 26= 17=20 > needs wholesale revision or replacement in many eyes. At worst, basic auth could be back in 2616, but fixing auth in general or= =20 even the issues with digest is way bigger than what planned in the=20 proposed scope. > Paul just noted that if the efforts are temporally linked, doing them=20 > separately is a waste of resources. I'm wondering if they are; e.g., coul= d a=20 > WG do 2616bis, and then be re-chartered to do 2617bis (with a similar sco= pe)? If two groups are created, there will be overlap in membership, but not=20 in the work done, so I don't see a big issue here. I would be against=20 doing a 2617bis to fix only typos, much more is needed. --=20 Baroula que barouleras, au ti=E9u toujou t'entourneras. ~~Yves From discuss-bounces@apps.ietf.org Thu May 31 17:39:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtsMf-0007aH-PE; Thu, 31 May 2007 17:39:25 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtkIP-0007aO-HH for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 09:02:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtkIP-0007Y8-6X for discuss@apps.ietf.org; Thu, 31 May 2007 09:02:29 -0400 Received: from nz-out-0506.google.com ([64.233.162.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtkIN-0005bD-Tv for discuss@apps.ietf.org; Thu, 31 May 2007 09:02:29 -0400 Received: by nz-out-0506.google.com with SMTP id i28so136803nzi for ; Thu, 31 May 2007 06:02:27 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qIgF3MVTwV5SQGtfCAbepC/2szpyqqAqNJQ5YIESQbnpjXjYyw51VV/U6zPIaFUBdpaV1CMhTzcblvkC37TO2RDESeLBYwtZfHQv8Enhby3E+kV5zGsAo7d4TmbhjFK5BAFFCRX78+1byjqqcg6qEeg/g+xsFl/Gx0m++HixYh4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZaFkIys8lifBxnSVlOfzJF2BrrKuZTcmGiiZP3dpbZD7xK9B2GaFgP61bXyIuHE5K5hGfAt9FKc2bDmZaE+OERP65Kex6VRWoMtCHZTh28qa5lXgSd2+i8CEzHs3eHbG0xfDxjC7WRONHgRw7P0I+y+0PrpMqowrM4wOPBHcSGk= Received: by 10.114.78.1 with SMTP id a1mr573151wab.1180616545333; Thu, 31 May 2007 06:02:25 -0700 (PDT) Received: by 10.114.211.7 with HTTP; Thu, 31 May 2007 06:02:25 -0700 (PDT) Message-ID: <68fba5c50705310602k1fca8c23xdb8fe2fa932ba933@mail.gmail.com> Date: Thu, 31 May 2007 09:02:25 -0400 From: "Robert Sayre" To: "Julian Reschke" Subject: Re: Straw-man charter for http-bis -- call for errata/clarifications to 2617 In-Reply-To: <465E853A.9010405@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <465D987F.5070906@cisco.com> <000c01c7a318$7bc243e0$7346cba0$@org> <68fba5c50705302228v7f8ab278y50cf38c9f971f0a3@mail.gmail.com> <465E853A.9010405@gmx.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-Mailman-Approved-At: Thu, 31 May 2007 17:39:23 -0400 Cc: Eliot Lear , Larry Masinter , Apps Discuss , Mark Nottingham , ietf-http-wg@w3.org, Paul Hoffman X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On 5/31/07, Julian Reschke wrote: > Robert Sayre wrote: > > > > On 5/31/07, Mark Nottingham wrote: > >> > >> Robert's draft is orthogonal to a 2617 update; the idea of that is to > >> address the need for MTI security. > > > > My draft is orthogonal to things that are unimplementable, because it > > seeks to document what has actually happened, and why it did. It may > > Can somebody please remind me what that draft is? It's not > , right? Nope, it's here: Regarding that Digest work, I have since improved it based on feedback I got. In particular, Phillip Hallam-Baker's comments were right on the mark. The new and improved version is pretty good (and blogged long ago). Doing the right thing, and thus meeting the very sane requirements given in Sam Hartman's draft, is a task prone to ratholes of the non-technical variety. It also attracts volume-oriented participants. -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From discuss-bounces@apps.ietf.org Thu May 31 17:39:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtsMg-0007bt-6C; Thu, 31 May 2007 17:39:26 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Htklk-0006vu-5z for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 09:32:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htklj-0006uL-PM for discuss@apps.ietf.org; Thu, 31 May 2007 09:32:47 -0400 Received: from nz-out-0506.google.com ([64.233.162.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htkli-0003hA-R0 for discuss@apps.ietf.org; Thu, 31 May 2007 09:32:47 -0400 Received: by nz-out-0506.google.com with SMTP id i28so144236nzi for ; Thu, 31 May 2007 06:32:46 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=U0/4E2LDFjWM8RC9dsaARSiW07NUADfVkecHJ7qJ9tHlnA4RUbTxmg5mtsLScLS2B4WR+Ka1nNvb1TgTj6BK9n7WdSRQh9+379qcI9q55txbNYGT11Qof3LtCTZyrSmS7j7UMYQr42hZ/+NvRhgy5oeuqH7hF58A1WN/2ND2sdo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IwtyFAn1C4x0OfGWfLMBZiKJf2Kq4VNLNZtSYcdH0QQ00ZvvjCrjc8kNiXyqOXkYXhz+vd/ykHWwwGkSMCzSYUmyqo0M4syNeKtF36/q5S1wYABp5R51huHSAZku2DcgTIwTCqT0q+hUXzuWHxR/kdkWGTrJ6df2SEnksx82gbU= Received: by 10.115.94.1 with SMTP id w1mr614519wal.1180618365630; Thu, 31 May 2007 06:32:45 -0700 (PDT) Received: by 10.114.211.7 with HTTP; Thu, 31 May 2007 06:32:45 -0700 (PDT) Message-ID: <68fba5c50705310632l2396af50u710a6be87d729e92@mail.gmail.com> Date: Thu, 31 May 2007 09:32:45 -0400 From: "Robert Sayre" To: "Paul Hoffman" Subject: Re: Straw-man charter for http-bis In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <465D987F.5070906@cisco.com> <465DEA9C.2060508@gmx.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-Mailman-Approved-At: Thu, 31 May 2007 17:39:23 -0400 Cc: Apps Discuss , Mark Nottingham , "ietf-http-wg@w3.org Group" , Eliot Lear X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On 5/30/07, Paul Hoffman wrote: > > If the effort for the two are temporally linked (they have to be done > at the same time), and there will be a lot of overlap in the groups > working on the two (that is, HTTP implementers and HTTP weenies are > needed for both efforts), having two WGs seems like a waste of > resources. I don't think this follows. Personally, I don't want to participate in the group working on 2617 until it's clear that it isn't yet another list full of bombast about "trust", "identity", "federation", and a bunch of other jargon that never amounts to anything technically feasible. I don't think there is a good economic argument for bringing that noise over here, where I definitely do want to participate. -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From discuss-bounces@apps.ietf.org Thu May 31 17:39:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtsMg-0007co-E0; Thu, 31 May 2007 17:39:26 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Htkpg-0000vf-Pf for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 09:36:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htkpg-0000vV-Fw for discuss@apps.ietf.org; Thu, 31 May 2007 09:36:52 -0400 Received: from nz-out-0506.google.com ([64.233.162.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htkpd-00054o-KD for discuss@apps.ietf.org; Thu, 31 May 2007 09:36:52 -0400 Received: by nz-out-0506.google.com with SMTP id i28so145204nzi for ; Thu, 31 May 2007 06:36:48 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=D8s6mF/vGoJMldPktcUxJSEY0728nKZbxfS2I7JThK4sXIiC79VXJVhNmQUOQtmQF7nsbmTJtAYr3QH6Uuw5hpArJs1GvTKRgc0v7am442YuF1QELTJHkevc9k7cmOinqO+i50HuAsaB2DyeiHUpSyDv/dMBl3Td0gYfnOEGhBs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dAeFWdGExTmWj/tb3Ub7nQYMJTzTuTqKZHEZCDaSL1zxrji2HOkt9/SqGF/voRBQ+etcwuMKnM2EOUjX1cP4faz1GoThn2icmWu6FVsRKhQaNhSkEazOci16rGJssd3lOIkh1JyzcRFUmuDHB4XAQJDRU75+wpu04HBggv7p2xc= Received: by 10.115.88.1 with SMTP id q1mr635407wal.1180618606950; Thu, 31 May 2007 06:36:46 -0700 (PDT) Received: by 10.114.211.7 with HTTP; Thu, 31 May 2007 06:36:46 -0700 (PDT) Message-ID: <68fba5c50705310636q1e191a10j7b35f2c8b99b789f@mail.gmail.com> Date: Thu, 31 May 2007 09:36:46 -0400 From: "Robert Sayre" To: "Julian Reschke" Subject: Re: Straw-man charter for http-bis -- call for errata/clarifications to 2617 In-Reply-To: <465EC8C0.1020700@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <465D9142.9050506@gmx.de> <465D987F.5070906@cisco.com> <000c01c7a318$7bc243e0$7346cba0$@org> <68fba5c50705302228v7f8ab278y50cf38c9f971f0a3@mail.gmail.com> <465E853A.9010405@gmx.de> <68fba5c50705310602k1fca8c23xdb8fe2fa932ba933@mail.gmail.com> <465EC8C0.1020700@gmx.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-Mailman-Approved-At: Thu, 31 May 2007 17:39:23 -0400 Cc: Eliot Lear , Larry Masinter , Apps Discuss , Mark Nottingham , ietf-http-wg@w3.org, Paul Hoffman X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On 5/31/07, Julian Reschke wrote: > > > Nope, it's here: > > > > ...so, are you going to submit it as an ID? If that makes a difference, I am happy to. -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From discuss-bounces@apps.ietf.org Thu May 31 17:39:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtsMg-0007dw-OS; Thu, 31 May 2007 17:39:26 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Htl1n-0006wI-H4 for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 09:49:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htl1l-0006pf-LN for discuss@apps.ietf.org; Thu, 31 May 2007 09:49:22 -0400 Received: from py-out-1112.google.com ([64.233.166.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htl1k-0008DL-Em for discuss@apps.ietf.org; Thu, 31 May 2007 09:49:21 -0400 Received: by py-out-1112.google.com with SMTP id y77so329962pyg for ; Thu, 31 May 2007 06:49:19 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=N5KjkuiSPlFnbrWSKAGqJKiVcyi/erNoCm1Q5cWkdSqXUUiwVVxz2bVcUE1jQCeW2ryUZkMVkolvWjWKmG8U0JzidR+nq4tDiG4trGRJ86EYp8VpjXQRl5LAr0PlvYEos3ioGSaC8aQR9k+/0ZkyagDtlHoLYGyEjLpv2+bEKwM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MVgR2o2hh+FHkAOr41FAS2GrAsu6A5C8fQ0kDdbvRy1xI4B8ywS/sxQp0RJTpSyzub39DZLiCwTQKAPC9rPNS0a/WVRTIVYDhSyL8S4XmGJE9AMZbbi0CVBFO58p6uYKtATmKzs4YuOT9aKSAyidMMXAxTQv0ihZUoKrNn5pjFk= Received: by 10.115.49.16 with SMTP id b16mr598516wak.1180619359077; Thu, 31 May 2007 06:49:19 -0700 (PDT) Received: by 10.114.211.7 with HTTP; Thu, 31 May 2007 06:49:19 -0700 (PDT) Message-ID: <68fba5c50705310649i418f14c6g21d0f0c669ffa692@mail.gmail.com> Date: Thu, 31 May 2007 09:49:19 -0400 From: "Robert Sayre" To: "Cyrus Daboo" Subject: Re: Straw-man charter for http-bis -- call for errata/clarifications to 2617 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <465D987F.5070906@cisco.com> <000c01c7a318$7bc243e0$7346cba0$@org> <68fba5c50705302228v7f8ab278y50cf38c9f971f0a3@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-Mailman-Approved-At: Thu, 31 May 2007 17:39:23 -0400 Cc: Eliot Lear , Larry Masinter , Apps Discuss , Mark Nottingham , ietf-http-wg@w3.org, Paul Hoffman X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On 5/31/07, Cyrus Daboo wrote: > Hi Robert, > > --On May 31, 2007 1:28:39 AM -0400 Robert Sayre wrote: > > > My feeling is that the current schemes can be updated by documenting > > the internationalization behavior of popular implementations, but > > nothing else is worth doing. > > I disagree. I think we need to go a lot further. My suggestion would be to > throw away 2617 as-is, ... > So I think separate working > groups would be better because of the different cross-area participation > requirements. Fully agree. I should have written "no other work on 2617 is worth doing". -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From discuss-bounces@apps.ietf.org Thu May 31 17:39:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtsMh-0007gB-2T; Thu, 31 May 2007 17:39:27 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtsBC-00078M-Dq for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 17:27:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtsBC-00078E-4A for discuss@apps.ietf.org; Thu, 31 May 2007 17:27:34 -0400 Received: from sumo.dreamhost.com ([66.33.216.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtsBA-0007JG-N5 for discuss@apps.ietf.org; Thu, 31 May 2007 17:27:34 -0400 Received: from spaceymail-a4.g.dreamhost.com (sd-green-bigip-202.dreamhost.com [208.97.132.202]) by sumo.dreamhost.com (Postfix) with ESMTP id D6F1C1782A7 for ; Thu, 31 May 2007 12:10:06 -0700 (PDT) Received: from [192.168.0.133] (ip72-211-200-45.oc.oc.cox.net [72.211.200.45]) by spaceymail-a4.g.dreamhost.com (Postfix) with ESMTP id F08581616BB; Thu, 31 May 2007 12:09:45 -0700 (PDT) In-Reply-To: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1358AF2C-F967-46D6-B291-BC65126CCDF6@gbiv.com> Content-Transfer-Encoding: 7bit From: "Roy T. Fielding" Subject: Re: Straw-man charter for http-bis Date: Thu, 31 May 2007 12:10:03 -0700 To: Mark Nottingham X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-Mailman-Approved-At: Thu, 31 May 2007 17:39:23 -0400 Cc: Apps Discuss , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Just to reiterate what I have said before, I think it is absurd to make minor editorial modifications to RFC 2616 in a new revision. If minor editorial changes are necessary right now, the RFC editor can make them with a simple set of instructions from the original authors. However, I don't see them as necessary -- the existing list of errata is sufficient until such time as the more pressing security issues can be resolved in other specifications. The reason that RFC 2616 had so many editorial mistakes is because the RFC became completely unreadable due to far too much committee-driven discussion being added in the revision from 2068 to 2616. If an actual revision is desired for HTTP/1.1, then a ground-up reorg of the specification and formal ABNF productions are necessary. I don't care if that matches "group consensus desires" or not; sometimes the work needs to be done regardless of popular opinion. What matters is not what work the working group is willing to embark upon, but what work the group is willing to review at the end. If I completely rewrite the HTTP/1.1 specification without adding features, and submit that new draft for review, will the working group consider it to be out of scope? If not, then limiting the scope of changes to the specification (aside from not adding new features) is irrelevant to the charter. If it will be out of scope, then I have no interest in participating here and will fork the standard to a place that isn't being driven by a short-term corporate agenda. If an IETF HTTP WG is to be recreated, then its task items should be to create what the working group believes to be the best documents to replace 2616 and 2617. The charter does not need to constrain that. In any case, the IESG has expressed many times that an application protocol will not move forward without providing a required solution for secure authentication. Thus, it is foolish to start a 2616 revision without first completing some form of 2617 revision, whether or not that includes new features for HTTP. That is not going to happen as long as you guys are burning up all of the available HTTP reviewers' time on irrelevant changes to 2616. Cheers, Roy T. Fielding Chief Scientist, Day Software From discuss-bounces@apps.ietf.org Thu May 31 17:39:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtsMh-0007i5-Do; Thu, 31 May 2007 17:39:27 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtsKF-0006M3-Sm for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 17:36:55 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtsKF-0006Lv-JE for discuss@apps.ietf.org; Thu, 31 May 2007 17:36:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtsIv-00059l-Kr for discuss@apps.ietf.org; Thu, 31 May 2007 17:35:33 -0400 Received: from av8-1-sn3.vrr.skanova.net ([81.228.9.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtsIu-0000ys-8F for discuss@apps.ietf.org; Thu, 31 May 2007 17:35:33 -0400 Received: by av8-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 1411238587; Thu, 31 May 2007 23:35:31 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av8-1-sn3.vrr.skanova.net (Postfix) with ESMTP id F2914383F8; Thu, 31 May 2007 23:35:30 +0200 (CEST) Received: from henriknordstrom.net (81-233-163-21-no84.tbcn.telia.com [81.233.163.21]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 31E4737E48; Thu, 31 May 2007 23:35:27 +0200 (CEST) Received: from [192.168.1.2] (henriknordstrom.net [192.168.1.2] (may be forged)) by henriknordstrom.net (8.12.11.20060308/8.12.8) with ESMTP id l4VLZR3X018378; Thu, 31 May 2007 23:35:27 +0200 Subject: Re: Straw-man charter for http-bis -- call for errata/clarifications to 2617 From: Henrik Nordstrom To: Cyrus Daboo In-Reply-To: References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <465D987F.5070906@cisco.com> <000c01c7a318$7bc243e0$7346cba0$@org> <68fba5c50705302228v7f8ab278y50cf38c9f971f0a3@mail.gmail.com> <1180637848.4471.11.camel@henriknordstrom.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-y2RxZ1cZNX3amrJ9NSDX" Date: Thu, 31 May 2007 23:35:27 +0200 Message-Id: <1180647327.5423.9.camel@henriknordstrom.net> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on henriknordstrom.net X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-TMDA-Confirmed: Thu, 31 May 2007 17:36:55 -0400 X-Mailman-Approved-At: Thu, 31 May 2007 17:39:23 -0400 Cc: Eliot Lear , Larry Masinter , Robert Sayre , Apps Discuss , Mark Nottingham , ietf-http-wg@w3.org, Paul Hoffman X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --=-y2RxZ1cZNX3amrJ9NSDX Content-Type: text/plain Content-Transfer-Encoding: quoted-printable tor 2007-05-31 klockan 17:16 -0400 skrev Cyrus Daboo: > Well there is already RFC4559 and some folks in the security area were=20 > working on tidying that up a bit more for a proposed standard. Sure, but it doesn't make it follow the HTTP specs any better. It's not very visible when reading the rfc until one gets to the security considerations section, or alternatively study how the "scheme" actually operates on the wire. NTLM and Negotiate is not HTTP authentication schemes, it's something completely different masqueraded to look like HTTP authentication at a first glance, but with far going implications on the HTTP message, transport and security models. Regards Henrik --=-y2RxZ1cZNX3amrJ9NSDX Content-Type: application/pgp-signature; name=signature.asc Content-Description: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iQCVAwUARl8/nENPQ5Kbx8daAQL5YAP+MpfVCSHTzXSeC27yorV2LO1tcQYoTrMe ZrpZTWhtgsu8u/fqajDqZLub1f58QfuNjTLGV6TswZo8o5DidB4L71eqAKvlz+Mr xyajtS4Hx97ta4+BZqtx3Eo/QGDc4wJlMtZw/kPHaiImjiCICvI4goXCYVH4eBpp 5P6nIxUn8Gk= =qFXx -----END PGP SIGNATURE----- --=-y2RxZ1cZNX3amrJ9NSDX-- From discuss-bounces@apps.ietf.org Thu May 31 17:39:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtsMh-0007kG-Po; Thu, 31 May 2007 17:39:27 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtsKO-0006N1-Bl for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 17:37:04 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtsKO-0006Ms-2G for discuss@apps.ietf.org; Thu, 31 May 2007 17:37:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htrl6-0000EN-4d for discuss@apps.ietf.org; Thu, 31 May 2007 17:00:36 -0400 Received: from av9-2-sn3.vrr.skanova.net ([81.228.9.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htrl4-0000Pf-OC for discuss@apps.ietf.org; Thu, 31 May 2007 17:00:36 -0400 Received: by av9-2-sn3.vrr.skanova.net (Postfix, from userid 502) id C1939386A6; Thu, 31 May 2007 23:00:32 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av9-2-sn3.vrr.skanova.net (Postfix) with ESMTP id B14FE37FCE; Thu, 31 May 2007 23:00:31 +0200 (CEST) Received: from henriknordstrom.net (81-233-163-21-no84.tbcn.telia.com [81.233.163.21]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id AE87037E4B; Thu, 31 May 2007 23:00:25 +0200 (CEST) Received: from [192.168.1.2] (henriknordstrom.net [192.168.1.2] (may be forged)) by henriknordstrom.net (8.12.11.20060308/8.12.8) with ESMTP id l4VIvSLD004895; Thu, 31 May 2007 20:57:28 +0200 Subject: Re: Straw-man charter for http-bis -- call for errata/clarifications to 2617 From: Henrik Nordstrom To: Cyrus Daboo In-Reply-To: References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <465D987F.5070906@cisco.com> <000c01c7a318$7bc243e0$7346cba0$@org> <68fba5c50705302228v7f8ab278y50cf38c9f971f0a3@mail.gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-IftaNtXyILIGPIUGMnZ6" Date: Thu, 31 May 2007 20:57:28 +0200 Message-Id: <1180637848.4471.11.camel@henriknordstrom.net> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on henriknordstrom.net X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-TMDA-Confirmed: Thu, 31 May 2007 17:37:04 -0400 X-Mailman-Approved-At: Thu, 31 May 2007 17:39:23 -0400 Cc: Eliot Lear , Larry Masinter , Robert Sayre , Apps Discuss , Mark Nottingham , ietf-http-wg@w3.org, Paul Hoffman X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --=-IftaNtXyILIGPIUGMnZ6 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable tor 2007-05-31 klockan 09:42 -0400 skrev Cyrus Daboo: > (form-based, cookie-based etc). We then have separate documents for each = of=20 > the http-based schemes basic and digest - and we should add Kerberos/SPNE= GO=20 > to that too. Note: Both Kerberos & SPNEGO both break the foundations laid out by RFC2616 and 2617, tying authentication to connections and not messages. Regards Henrik --=-IftaNtXyILIGPIUGMnZ6 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iQCVAwUARl8alkNPQ5Kbx8daAQJDAAP9FTVFffM40g5afubwWay6npJSHreU432P oNU9tAgqLBoPbEDbwmjJxU68q2yauBQg4m3l4KUlulmh78ednNnB9FzZClQjbvgz iGc5XUhN5cQIkuG3BL2AIoIdnfaAHZZn5dtiBY27N22ity3eALtpfOVuYxTltKvq bVPGhwZ25hM= =kOqQ -----END PGP SIGNATURE----- --=-IftaNtXyILIGPIUGMnZ6-- From discuss-bounces@apps.ietf.org Thu May 31 17:39:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtsMf-0007VE-0D; Thu, 31 May 2007 17:39:25 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtW8K-0001Gd-GN for discuss-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 17:55:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtW8J-0001Fw-WE for discuss@apps.ietf.org; Wed, 30 May 2007 17:55:08 -0400 Received: from nz-out-0506.google.com ([64.233.162.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtW8I-0001In-9G for discuss@apps.ietf.org; Wed, 30 May 2007 17:55:07 -0400 Received: by nz-out-0506.google.com with SMTP id i28so1763005nzi for ; Wed, 30 May 2007 14:55:05 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=q02PuDbf7ZR8oKu2mbdOizN3F0c5Ole72H7HzdmWZkmgmGZy13qGG55u2bWef8S8iBDaEqFaYqgzVxbotZMmiqKPUZEf5uBcxArL8AvOtcSzaCHtxiKIcbeY4/oKfhO3DGo+fSFu3DKzZPENb/Ojhkbgdo7wSoPzQoOtkPbTq0M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QtkDyYPatd//QP4p8Z74jLPvsw2bSUvXaKahUsaj7Q5tpIVifSSA+nCQnfLnqMmazGrd3FjTVO2mUQgh2vSGRux7BAMfylLQy35D5hgxvovkCjhbMLgxYi7k/0y4SHbQNZ+1hUj4vrUFkpSMZVoJI2HN7FLTQvPOKgIG+ZZzIeo= Received: by 10.115.95.1 with SMTP id x1mr4313705wal.1180561739393; Wed, 30 May 2007 14:48:59 -0700 (PDT) Received: by 10.114.211.7 with HTTP; Wed, 30 May 2007 14:48:59 -0700 (PDT) Message-ID: <68fba5c50705301448k242099abj7fc5d131ea0dca85@mail.gmail.com> Date: Wed, 30 May 2007 17:48:59 -0400 From: "Robert Sayre" To: "Mark Nottingham" Subject: Re: Straw-man charter for http-bis In-Reply-To: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1df8e4abc9851cb4adb45bd64d8514ae X-Mailman-Approved-At: Thu, 31 May 2007 17:39:23 -0400 Cc: Apps Discuss , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On 5/30/07, Mark Nottingham wrote: > > * Document the security properties of HTTP and its associated > mechanisms (e.g., Basic and Digest authentication, cookies, TLS) for > common applications I think this is excellent news. Below, you'll find the text I mentioned in a previous thread. It's not very well-written, and I'm not sure I'll have much time to work on it, but it's a start. I think there is important work to be done to the core spec, and extensions and revisions to 2617 are needed. I appreciate the narrow scope of the charter, and I think it would be best to leave it that way until it's clear we are making good progress on the listed milestones. -- Robert Sayre --------------------------------------------------------------------- Network Working Group R. Sayre Internet-Draft Mozilla Corporation Intended status: Informational January 15, 2007 Expires: July 19, 2007 Security Requirements for HTTP draft-sayre-http-security-variance-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 19, 2007. Copyright Notice Copyright (C) The Internet Society (2007). Abstract Recent IESG practice dictates that IETF protocols must specify mandatory to implement security mechanisms, so that all conformant implementations share a common baseline. This document examines all widely deployed HTTP security technologies, and analyzes the trade- offs of each. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 3. Existing HTTP Security Mechanisms . . . . . . . . . . . . . . 5 3.1. Forms And Cookies . . . . . . . . . . . . . . . . . . . . 5 3.2. HTTP Access Authentication . . . . . . . . . . . . . . . . 6 3.2.1. Basic Authentication . . . . . . . . . . . . . . . . . 6 3.2.2. Digest Authentication . . . . . . . . . . . . . . . . 6 3.2.3. Other Schemes . . . . . . . . . . . . . . . . . . . . 7 3.3. Centrally-Issued Tickets . . . . . . . . . . . . . . . . . 7 3.4. Web Services . . . . . . . . . . . . . . . . . . . . . . . 7 3.5. Transport Layer Security . . . . . . . . . . . . . . . . . 8 4. Revisions To HTTP . . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Normative References . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 1. Introduction Note: this is document is just a laundry list of security technologies and tradeoffs for the moment. This document examines the effects of applying security constraints to Web applications, documents the properties that result from each method, and will make Best Current Practice recommendations for HTTP security in a later document version. 2. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Existing HTTP Security Mechanisms For HTTP, the IETF generally defines "security mechanisms" as some combination of access authentication and/or a secure transport. 3.1. Forms And Cookies Almost all HTTP authentication is accomplished through HTML forms, with session keys stored in cookies. For cookies, most implementations rely on the Netscape specification. One update, HTTP State Management Mechanism [RFC2109] is relatively widely implemented, but most clients don't advertise support for it. HTTP State Management Mechanism was later updated [RFC2965], but the newer version is not widely implemented. Forms and cookies have number of properties that make them an excellent solution for some implementors. However, many of those properties introduce serious security trade-offs. HTML forms provide a large degree of control over presentation, an imperative for many websites. However, this increases user reliance on the appearance of the interface. Many users do not understand the construction of URIs [RFC3986], or their presentation in common clients [todo: citation]. As a result, forms are extremely vulnerable to spoofing. HTML forms provide acceptable internationalization if used carefully, at the cost of being transmitted as normal HTTP content in all cases (credentials are not differentiated in the protocol). HTML forms provide a facility for sites to indicate a password should never be pre-populated. [@more on autocomplete] The cookies that result from a successful form submission make it unessecary to validate credentials with each HTTP request, an excellent property for scalability. Cookies are susceptible to a large variety of XSS (Cross-site scripting) attacks, and measures to prevent such attacks will never be as stringent as necessary for authentication credentials, because cookies are used for many purposes. Cookies are also susceptible to a wide variety of attacks from malicious intermediaries and observers. The possible attacks depend on the contents of the cookie data. There is no standard format for most of the data. HTML forms and cookies provide flexible ways of ending a session from the client. HTML forms require an HTML rendering engine, which many protocols have no use for. 3.2. HTTP Access Authentication HTTP 1.1 provides a simple authentication framework, and HTTP Authentication: Basic and Digest Access Authentication [RFC2617] defines two OPTIONAL mechanisms. Both of these mechanisms are extremely rarely used in comparison to forms and cookies, but some degree of support for one or both is available in many implementations. Neither scheme provides presentation control, logout capabilities, or interoperable internationalization. 3.2.1. Basic Authentication Basic Authentication transmits usernames and passwords in the clear. It is very easy to implement, but not at all secure unless used over a secure transport. Basic has very poor scalability properties, because credentials must be revalidated with every request, and secure transports negate many of HTTP's caching mechanisms. Some implementations use cookies in combination with Basic credentials, but there is no standard method of doing so. Since Basic credentials are clear text, they are reusable by any party. This makes them compatible with any authentication database, at the cost of making the user vulnerable to mismanaged or malicious servers, even over a secure channel. Basic is not interoperable when used with credentials that contain characters outside of the Latin-1 range. 3.2.2. Digest Authentication In Digest Authentication, the client transmits the results of hashing user credentials with properties of the request and values from the server challenge. Digest is susceptible to man in the middle attacks when not used over a secure transport. Digest has some properties that are preferable to Basic and Cookies. Credentials are not immediately reusable by parties that observe or recieve them, and session data can be transmitted along side credentials with each request, allowing servers to validate credentials only when absolutely necessary. Authentication data session keys are distinct from other protocol traffic. Digest includes many modes of operation, but only the simplest modes enjoy any degree of interoperability. For example, most implementations do not implement the mode that provides full message integrity. Additionally, implementation experience has shown that the mode is impractical, because it requires servers to analyze the full request before determining whether the client knows the shared secret. Digest is extremely susceptible to offline dictionary attacks, making it practical for attackers to perform a namespace walk consisting of a few million passwords [todo: cite]. Many of the most widely-deployed HTTP/1.1 clients are not compliant when GET requests include a query string [Apache_Digest]. Digest requires that authentication databases be expressly designed to accomodate it. As a result, many authentication databases are incompatible, including the most common method of storing passwords for use with Forms and Cookies. Many Digest capabilities included to prevent replay attacks expose the server to Denial of Service attacks. Digest is not interoperable when used with credentials that contain characters outside of the Latin-1 range. 3.2.3. Other Schemes There are many niche schemes that make use of the HTTP Authentication framework, but very few are well documented. Some are bound to transport layer connections. 3.3. Centrally-Issued Tickets Many large Internet services rely on authentication schemes that center on clients consulting a single service for a time-limited ticket that is validated with undocumented heuristics. Centralized ticket issuing has the advantage that users may employ one set of credentials for many services, and clients don't send credentials to many servers. This approach is often no more than a sophisticated application of Forms and Cookies. All of the schemes in wide use are proprietary, undocumented, and non-standard. There are many standardization efforts in progress, as usual. 3.4. Web Services Many security properties mentioned above have been recast in XML- based protocols, using HTTP as a substitute for TCP. Like the amalgam of HTTP technologies mentioned above, the XML-based protocols are defined by an ever-changing combination of standard and vendor- produced specifications, some of which may be obsoleted at any time [WS-Pagecount], with no documented change control procedures. These protocols usually don't have much in common the Architecture of the World Wide Web. It's not clear why term "Web" is used to group them, but they are obviously out of scope for HTTP-based application protocols. 3.5. Transport Layer Security [todo] 4. Revisions To HTTP Is is possible that HTTP will be revised in the future. HTTP 1.1 [RFC2616] and Use and Interpretation of HTTP Version Numbers [RFC2145] define conformance requirements in relation to version numbers. In HTTP 1.1, all authentication mechanisms are OPTIONAL, and no single transport substrate is specified. Any HTTP revision that adds a mandatory security mechanism or transport substrate MUST increment the HTTP version number appropriately. All widely used schemes are non-standard and/or proprietary. 5. Security Considerations 6. Normative References [Apache_Digest] ASF, "Apache HTTP Server - mod_auth_digest". [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2109, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use and Interpretation of HTTP Version Numbers", RFC 2145, May 1997. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2965, October 2000. [RFC3365] Schiller, J., "Strong Security Requirements for Internet Engineering Task Force Standard Protocols", BCP 61, RFC 3365, August 2002. [RFC3631] Bellovin, S., Schiller, J., and C. Kaufman, "Security Mechanisms for the Internet", RFC 3631, December 2003. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [WS-Pagecount] Bray, T., "WS-Pagecount", September 2004. Author's Address Robert Sayre Mozilla Corporation Full Copyright Statement Copyright (C) The Internet Society (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). From discuss-bounces@apps.ietf.org Thu May 31 17:39:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtsMf-0007Vj-9J; Thu, 31 May 2007 17:39:25 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtdDH-0000qC-7H for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 01:28:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtdDG-0000pv-H3 for discuss@apps.ietf.org; Thu, 31 May 2007 01:28:42 -0400 Received: from wa-out-1112.google.com ([209.85.146.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtdDE-00034I-Kj for discuss@apps.ietf.org; Thu, 31 May 2007 01:28:41 -0400 Received: by wa-out-1112.google.com with SMTP id k22so72902waf for ; Wed, 30 May 2007 22:28:39 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RpgzZjOMx1VO5RDpG3NNRyOUeUh4q1Ztg3/SgzLjoksMdOt35enNUpVi7B4pQ4LPuK6VbbvxI9GmQ6yAlHgdzN+yFkq/zpnZwFEJ7D39g15ZnnCYvfh3Gic8ZinLHmi0NR6WrOMtkeRCOeNA6+G0LXTU5wp2dXyd0RHss8hqgII= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IINLBBRoDhXJ5kcYDAqCb/Hh664FF+yvpqxep3I8d8Ts4PRZAtiO9OXou60IdiM1FEHVTXHmN7zxrGXaWlzoH6NW8sNcops6pR2K0x5o8cTqEeWKhvnwD5fiPD8ND6ccGGK+d3ls6GtCPC1/pRHtg5Yy+SifH1V4ZwtLozisDVA= Received: by 10.115.54.1 with SMTP id g1mr180398wak.1180589319384; Wed, 30 May 2007 22:28:39 -0700 (PDT) Received: by 10.114.211.7 with HTTP; Wed, 30 May 2007 22:28:39 -0700 (PDT) Message-ID: <68fba5c50705302228v7f8ab278y50cf38c9f971f0a3@mail.gmail.com> Date: Thu, 31 May 2007 01:28:39 -0400 From: "Robert Sayre" To: "Mark Nottingham" Subject: Re: Straw-man charter for http-bis -- call for errata/clarifications to 2617 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <465D987F.5070906@cisco.com> <000c01c7a318$7bc243e0$7346cba0$@org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-Mailman-Approved-At: Thu, 31 May 2007 17:39:23 -0400 Cc: Eliot Lear , Larry Masinter , Apps Discuss , ietf-http-wg@w3.org, Paul Hoffman X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On 5/31/07, Mark Nottingham wrote: > > Robert's draft is orthogonal to a 2617 update; the idea of that is to > address the need for MTI security. My draft is orthogonal to things that are unimplementable, because it seeks to document what has actually happened, and why it did. It may be possible to design an MTI scheme for HTTP. So far, the text in my draft leads me to believe that HTTP authentication is wedged between graphic design, scalability, and security in such a way that implementors of a given protocol will never be able to agree on shared trade-offs. But I have only written what I know. I'm sure the document can be augmented and corrected. > It would be interesting to compile issues for 2617 as well, to see > what the scope of work would be. If we can keep the scope to errata > and clarifications (i.e., not introducing new schemes), it might be > doable. My feeling is that the current schemes can be updated by documenting the internationalization behavior of popular implementations, but nothing else is worth doing. -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From discuss-bounces@apps.ietf.org Thu May 31 17:39:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtsMf-0007VE-0D; Thu, 31 May 2007 17:39:25 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtW8K-0001Gd-GN for discuss-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 17:55:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtW8J-0001Fw-WE for discuss@apps.ietf.org; Wed, 30 May 2007 17:55:08 -0400 Received: from nz-out-0506.google.com ([64.233.162.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtW8I-0001In-9G for discuss@apps.ietf.org; Wed, 30 May 2007 17:55:07 -0400 Received: by nz-out-0506.google.com with SMTP id i28so1763005nzi for ; Wed, 30 May 2007 14:55:05 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=q02PuDbf7ZR8oKu2mbdOizN3F0c5Ole72H7HzdmWZkmgmGZy13qGG55u2bWef8S8iBDaEqFaYqgzVxbotZMmiqKPUZEf5uBcxArL8AvOtcSzaCHtxiKIcbeY4/oKfhO3DGo+fSFu3DKzZPENb/Ojhkbgdo7wSoPzQoOtkPbTq0M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QtkDyYPatd//QP4p8Z74jLPvsw2bSUvXaKahUsaj7Q5tpIVifSSA+nCQnfLnqMmazGrd3FjTVO2mUQgh2vSGRux7BAMfylLQy35D5hgxvovkCjhbMLgxYi7k/0y4SHbQNZ+1hUj4vrUFkpSMZVoJI2HN7FLTQvPOKgIG+ZZzIeo= Received: by 10.115.95.1 with SMTP id x1mr4313705wal.1180561739393; Wed, 30 May 2007 14:48:59 -0700 (PDT) Received: by 10.114.211.7 with HTTP; Wed, 30 May 2007 14:48:59 -0700 (PDT) Message-ID: <68fba5c50705301448k242099abj7fc5d131ea0dca85@mail.gmail.com> Date: Wed, 30 May 2007 17:48:59 -0400 From: "Robert Sayre" To: "Mark Nottingham" Subject: Re: Straw-man charter for http-bis In-Reply-To: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1df8e4abc9851cb4adb45bd64d8514ae X-Mailman-Approved-At: Thu, 31 May 2007 17:39:23 -0400 Cc: Apps Discuss , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On 5/30/07, Mark Nottingham wrote: > > * Document the security properties of HTTP and its associated > mechanisms (e.g., Basic and Digest authentication, cookies, TLS) for > common applications I think this is excellent news. Below, you'll find the text I mentioned in a previous thread. It's not very well-written, and I'm not sure I'll have much time to work on it, but it's a start. I think there is important work to be done to the core spec, and extensions and revisions to 2617 are needed. I appreciate the narrow scope of the charter, and I think it would be best to leave it that way until it's clear we are making good progress on the listed milestones. -- Robert Sayre --------------------------------------------------------------------- Network Working Group R. Sayre Internet-Draft Mozilla Corporation Intended status: Informational January 15, 2007 Expires: July 19, 2007 Security Requirements for HTTP draft-sayre-http-security-variance-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 19, 2007. Copyright Notice Copyright (C) The Internet Society (2007). Abstract Recent IESG practice dictates that IETF protocols must specify mandatory to implement security mechanisms, so that all conformant implementations share a common baseline. This document examines all widely deployed HTTP security technologies, and analyzes the trade- offs of each. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 3. Existing HTTP Security Mechanisms . . . . . . . . . . . . . . 5 3.1. Forms And Cookies . . . . . . . . . . . . . . . . . . . . 5 3.2. HTTP Access Authentication . . . . . . . . . . . . . . . . 6 3.2.1. Basic Authentication . . . . . . . . . . . . . . . . . 6 3.2.2. Digest Authentication . . . . . . . . . . . . . . . . 6 3.2.3. Other Schemes . . . . . . . . . . . . . . . . . . . . 7 3.3. Centrally-Issued Tickets . . . . . . . . . . . . . . . . . 7 3.4. Web Services . . . . . . . . . . . . . . . . . . . . . . . 7 3.5. Transport Layer Security . . . . . . . . . . . . . . . . . 8 4. Revisions To HTTP . . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Normative References . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 1. Introduction Note: this is document is just a laundry list of security technologies and tradeoffs for the moment. This document examines the effects of applying security constraints to Web applications, documents the properties that result from each method, and will make Best Current Practice recommendations for HTTP security in a later document version. 2. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Existing HTTP Security Mechanisms For HTTP, the IETF generally defines "security mechanisms" as some combination of access authentication and/or a secure transport. 3.1. Forms And Cookies Almost all HTTP authentication is accomplished through HTML forms, with session keys stored in cookies. For cookies, most implementations rely on the Netscape specification. One update, HTTP State Management Mechanism [RFC2109] is relatively widely implemented, but most clients don't advertise support for it. HTTP State Management Mechanism was later updated [RFC2965], but the newer version is not widely implemented. Forms and cookies have number of properties that make them an excellent solution for some implementors. However, many of those properties introduce serious security trade-offs. HTML forms provide a large degree of control over presentation, an imperative for many websites. However, this increases user reliance on the appearance of the interface. Many users do not understand the construction of URIs [RFC3986], or their presentation in common clients [todo: citation]. As a result, forms are extremely vulnerable to spoofing. HTML forms provide acceptable internationalization if used carefully, at the cost of being transmitted as normal HTTP content in all cases (credentials are not differentiated in the protocol). HTML forms provide a facility for sites to indicate a password should never be pre-populated. [@more on autocomplete] The cookies that result from a successful form submission make it unessecary to validate credentials with each HTTP request, an excellent property for scalability. Cookies are susceptible to a large variety of XSS (Cross-site scripting) attacks, and measures to prevent such attacks will never be as stringent as necessary for authentication credentials, because cookies are used for many purposes. Cookies are also susceptible to a wide variety of attacks from malicious intermediaries and observers. The possible attacks depend on the contents of the cookie data. There is no standard format for most of the data. HTML forms and cookies provide flexible ways of ending a session from the client. HTML forms require an HTML rendering engine, which many protocols have no use for. 3.2. HTTP Access Authentication HTTP 1.1 provides a simple authentication framework, and HTTP Authentication: Basic and Digest Access Authentication [RFC2617] defines two OPTIONAL mechanisms. Both of these mechanisms are extremely rarely used in comparison to forms and cookies, but some degree of support for one or both is available in many implementations. Neither scheme provides presentation control, logout capabilities, or interoperable internationalization. 3.2.1. Basic Authentication Basic Authentication transmits usernames and passwords in the clear. It is very easy to implement, but not at all secure unless used over a secure transport. Basic has very poor scalability properties, because credentials must be revalidated with every request, and secure transports negate many of HTTP's caching mechanisms. Some implementations use cookies in combination with Basic credentials, but there is no standard method of doing so. Since Basic credentials are clear text, they are reusable by any party. This makes them compatible with any authentication database, at the cost of making the user vulnerable to mismanaged or malicious servers, even over a secure channel. Basic is not interoperable when used with credentials that contain characters outside of the Latin-1 range. 3.2.2. Digest Authentication In Digest Authentication, the client transmits the results of hashing user credentials with properties of the request and values from the server challenge. Digest is susceptible to man in the middle attacks when not used over a secure transport. Digest has some properties that are preferable to Basic and Cookies. Credentials are not immediately reusable by parties that observe or recieve them, and session data can be transmitted along side credentials with each request, allowing servers to validate credentials only when absolutely necessary. Authentication data session keys are distinct from other protocol traffic. Digest includes many modes of operation, but only the simplest modes enjoy any degree of interoperability. For example, most implementations do not implement the mode that provides full message integrity. Additionally, implementation experience has shown that the mode is impractical, because it requires servers to analyze the full request before determining whether the client knows the shared secret. Digest is extremely susceptible to offline dictionary attacks, making it practical for attackers to perform a namespace walk consisting of a few million passwords [todo: cite]. Many of the most widely-deployed HTTP/1.1 clients are not compliant when GET requests include a query string [Apache_Digest]. Digest requires that authentication databases be expressly designed to accomodate it. As a result, many authentication databases are incompatible, including the most common method of storing passwords for use with Forms and Cookies. Many Digest capabilities included to prevent replay attacks expose the server to Denial of Service attacks. Digest is not interoperable when used with credentials that contain characters outside of the Latin-1 range. 3.2.3. Other Schemes There are many niche schemes that make use of the HTTP Authentication framework, but very few are well documented. Some are bound to transport layer connections. 3.3. Centrally-Issued Tickets Many large Internet services rely on authentication schemes that center on clients consulting a single service for a time-limited ticket that is validated with undocumented heuristics. Centralized ticket issuing has the advantage that users may employ one set of credentials for many services, and clients don't send credentials to many servers. This approach is often no more than a sophisticated application of Forms and Cookies. All of the schemes in wide use are proprietary, undocumented, and non-standard. There are many standardization efforts in progress, as usual. 3.4. Web Services Many security properties mentioned above have been recast in XML- based protocols, using HTTP as a substitute for TCP. Like the amalgam of HTTP technologies mentioned above, the XML-based protocols are defined by an ever-changing combination of standard and vendor- produced specifications, some of which may be obsoleted at any time [WS-Pagecount], with no documented change control procedures. These protocols usually don't have much in common the Architecture of the World Wide Web. It's not clear why term "Web" is used to group them, but they are obviously out of scope for HTTP-based application protocols. 3.5. Transport Layer Security [todo] 4. Revisions To HTTP Is is possible that HTTP will be revised in the future. HTTP 1.1 [RFC2616] and Use and Interpretation of HTTP Version Numbers [RFC2145] define conformance requirements in relation to version numbers. In HTTP 1.1, all authentication mechanisms are OPTIONAL, and no single transport substrate is specified. Any HTTP revision that adds a mandatory security mechanism or transport substrate MUST increment the HTTP version number appropriately. All widely used schemes are non-standard and/or proprietary. 5. Security Considerations 6. Normative References [Apache_Digest] ASF, "Apache HTTP Server - mod_auth_digest". [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2109, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use and Interpretation of HTTP Version Numbers", RFC 2145, May 1997. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2965, October 2000. [RFC3365] Schiller, J., "Strong Security Requirements for Internet Engineering Task Force Standard Protocols", BCP 61, RFC 3365, August 2002. [RFC3631] Bellovin, S., Schiller, J., and C. Kaufman, "Security Mechanisms for the Internet", RFC 3631, December 2003. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [WS-Pagecount] Bray, T., "WS-Pagecount", September 2004. Author's Address Robert Sayre Mozilla Corporation Full Copyright Statement Copyright (C) The Internet Society (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). From discuss-bounces@apps.ietf.org Thu May 31 17:39:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtsMf-0007Vj-9J; Thu, 31 May 2007 17:39:25 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtdDH-0000qC-7H for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 01:28:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtdDG-0000pv-H3 for discuss@apps.ietf.org; Thu, 31 May 2007 01:28:42 -0400 Received: from wa-out-1112.google.com ([209.85.146.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtdDE-00034I-Kj for discuss@apps.ietf.org; Thu, 31 May 2007 01:28:41 -0400 Received: by wa-out-1112.google.com with SMTP id k22so72902waf for ; Wed, 30 May 2007 22:28:39 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RpgzZjOMx1VO5RDpG3NNRyOUeUh4q1Ztg3/SgzLjoksMdOt35enNUpVi7B4pQ4LPuK6VbbvxI9GmQ6yAlHgdzN+yFkq/zpnZwFEJ7D39g15ZnnCYvfh3Gic8ZinLHmi0NR6WrOMtkeRCOeNA6+G0LXTU5wp2dXyd0RHss8hqgII= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IINLBBRoDhXJ5kcYDAqCb/Hh664FF+yvpqxep3I8d8Ts4PRZAtiO9OXou60IdiM1FEHVTXHmN7zxrGXaWlzoH6NW8sNcops6pR2K0x5o8cTqEeWKhvnwD5fiPD8ND6ccGGK+d3ls6GtCPC1/pRHtg5Yy+SifH1V4ZwtLozisDVA= Received: by 10.115.54.1 with SMTP id g1mr180398wak.1180589319384; Wed, 30 May 2007 22:28:39 -0700 (PDT) Received: by 10.114.211.7 with HTTP; Wed, 30 May 2007 22:28:39 -0700 (PDT) Message-ID: <68fba5c50705302228v7f8ab278y50cf38c9f971f0a3@mail.gmail.com> Date: Thu, 31 May 2007 01:28:39 -0400 From: "Robert Sayre" To: "Mark Nottingham" Subject: Re: Straw-man charter for http-bis -- call for errata/clarifications to 2617 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <465D987F.5070906@cisco.com> <000c01c7a318$7bc243e0$7346cba0$@org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-Mailman-Approved-At: Thu, 31 May 2007 17:39:23 -0400 Cc: Eliot Lear , Larry Masinter , Apps Discuss , ietf-http-wg@w3.org, Paul Hoffman X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On 5/31/07, Mark Nottingham wrote: > > Robert's draft is orthogonal to a 2617 update; the idea of that is to > address the need for MTI security. My draft is orthogonal to things that are unimplementable, because it seeks to document what has actually happened, and why it did. It may be possible to design an MTI scheme for HTTP. So far, the text in my draft leads me to believe that HTTP authentication is wedged between graphic design, scalability, and security in such a way that implementors of a given protocol will never be able to agree on shared trade-offs. But I have only written what I know. I'm sure the document can be augmented and corrected. > It would be interesting to compile issues for 2617 as well, to see > what the scope of work would be. If we can keep the scope to errata > and clarifications (i.e., not introducing new schemes), it might be > doable. My feeling is that the current schemes can be updated by documenting the internationalization behavior of popular implementations, but nothing else is worth doing. -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From discuss-bounces@apps.ietf.org Thu May 31 18:33:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HttCZ-0005DU-UT; Thu, 31 May 2007 18:33:03 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HttCX-0005DP-Sz for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 18:33:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HttCX-0005DH-JJ for discuss@apps.ietf.org; Thu, 31 May 2007 18:33:01 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HttCW-0005os-B1 for discuss@apps.ietf.org; Thu, 31 May 2007 18:33:01 -0400 Received: from [127.0.0.1] (unknown [216.145.54.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 2A4E451925; Thu, 31 May 2007 18:32:57 -0400 (EDT) In-Reply-To: <76323E9F0A911944A4E9225FACFC55BA04AFFB6C@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <1358AF2C-F967-46D6-B291-BC65126CCDF6@gbiv.com> <8FBD37BC-E635-485D-A368-22D9DE332498@mnot.net> <76323E9F0A911944A4E9225FACFC55BA04AFFB6C@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6B1691C7-73AB-4C05-8BC7-4D331CC12E3A@mnot.net> Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: Straw-man charter for http-bis Date: Fri, 1 Jun 2007 08:32:53 +1000 To: Paul Leach X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Apps Discuss , "Roy T.Fielding" , ietf-http-wg@w3.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On 01/06/2007, at 8:05 AM, Paul Leach wrote: > Sometimes, the best is the enemy of the good. I think this is one of > cases. As all good engineers should, I have great emotional > sympathy for > Roy's approach of producing the best possible HTTP spec, but while a > brand-new, easy-to-implement-from HTTP/1.1 spec would sure be > wonderful, > if it isn't very likely to get done, then it isn't in reality better > than a careful revision of the current one. (Another aspect of good > engineering is dealing with tradeoffs.) > > Indeed, the above analysis also applies to the proposed charter: > wouldn't an informational RFC "HTTP Implementors Guide" be nearly as > good as the proposed RFC2616bis? And far less work, hence available > much > sooner? That's an interesting suggestion. My initial feeling is that it might be harder to settle on text if given a blank slate. Also, much of the work for bis is done, or in train -- see the issues list and draft-lafon. For the apps-discuss people who may not have seen them; http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/ http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/draft-lafon- rfc2616bis-latest.txt > (And hey, since it isn't us, who are these evil "short-term corporate > interests"? Are they available to take other heat off us, too? :-) I'm sure someone could be found, for the right price... -- Mark Nottingham http://www.mnot.net/ From discuss-bounces@apps.ietf.org Thu May 31 20:58:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtvSs-00044A-6y; Thu, 31 May 2007 20:58:02 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtvSr-000444-Lu for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 20:58:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtvSr-00043w-C2 for discuss@apps.ietf.org; Thu, 31 May 2007 20:58:01 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtvSo-0004PS-Rz for discuss@apps.ietf.org; Thu, 31 May 2007 20:58:01 -0400 Received: from [127.0.0.1] (unknown [216.145.54.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id EE8C55193D; Thu, 31 May 2007 20:57:56 -0400 (EDT) In-Reply-To: References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <1358AF2C-F967-46D6-B291-BC65126CCDF6@gbiv.com> <8FBD37BC-E635-485D-A368-22D9DE332498@mnot.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: Straw-man charter for http-bis Date: Fri, 1 Jun 2007 10:57:53 +1000 To: "Roy T. Fielding" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: Apps Discuss , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On 01/06/2007, at 8:59 AM, Roy T. Fielding wrote: > It is not "if I don't get my way". Who appointed you to be the > determinant of group consensus in the first place? I am not going > to support an IETF working group that says "nobody is allowed > to do a better job describing HTTP than what is in our charter." > If you don't allow people to produce drafts, and allow the working > group to evaluate those drafts on the basis of whether the contents > are better or not, then all you are doing is dictating the content > of the specification based upon some imagined position of authority. You spoke about forking the HTTP spec if the IETF decided to go in a direction that you didn't like. Working outside the process is very different to working within it, whether that be in the charter discussions or the WG. Don't try to make this about me. > So, you should decide whether your work item is to replace 2616 > or to produce a list of errata to be published in RFC form. If it > is the former, than I know a lot more about this subject than you > and I know for a fact that just making small changes around the > edges is not sufficient. That's a naked appeal to authority, and I'll give it as much credence as it deserves. > We already tried that twice. I believe the circumstances are different; time changes things. > If I make the real changes that are needed in draft form and submit > them to the WG, then I will expect them to be evaluated without bias > or the WG to be closed. If the answer is "that's too much > for me to review, so you aren't allowed to do that in the IETF" > then I won't. I will do it elsewhere and the IETF specification > will become irrelevant. > >> Also, on what do you base the accusation that this is being driven >> by "short-term corporate agendas?" > > On the basis that you presuppose every work item as being limited > to what you want to do, rather than a task that can be accomplished > if someone does it, and the continual reference to vendors and > "developers" that never actually show themselves on this list. Can you substantiate that? >> In any case, I don't think re-organising parts of the spec is off >> the table; indeed, it's already been discussed on a small scale. >> Re-writing the entire spec sentence-for-sentence is, in my opinion. > > In your opinion. You chose to ignore mine, in spite of the fact that > I have a bit of history on the subject, and that is why I have to make > comments on these proposals. I'm not ignoring you, Roy. However, you're making the same arguments repeatedly. If you make arguments that convince me, or if you can get other people to agree with you, I'm happy to reconsider my opinion. Neither has happened yet. >>> If an IETF HTTP WG is to be recreated, then its task items should be >>> to create what the working group believes to be the best documents >>> to replace 2616 and 2617. The charter does not need to constrain >>> that. >> >> That would be disruptive and unproductive. You may be willing to >> re-write HTTP from scratch, but the review requirements are much >> higher than required for what we're attempting (with step-by-step >> diffs, by the way). >> >> Somehow, HTTP has been implemented and become one of the most >> widely-deployed application protocols today, despite your claims >> that the spec needs to be re-written from scratch. I don't hear >> *anyone* else saying that this necessary, or a realistic option. > > I don't hear anyone else saying that 2616 needs to be revised before > 2617, yet you continue to take that as an assumption. 2616 doesn't > *need* to be revised at all. 2617 desperately does need to in order > to meet the IESG requirements. Why is that unclear? Have you been following the same discussion that I have? Later, you said to Larry: > I said that I would if it were given a chance to be reviewed. > I offered as much to Lisa before this effort started, and before > the revision was public, and again once people started working on it, > and each of those times I was rebuffed because the people organizing > this WG don't think a full revision should be in scope. I'm willing to do a reasonable amount of work to polish the spec, but at this point am unwilling to commit to start from scratch, both because I don't think it's likely to be successful, or that I'd be able to put the time in. My perception is that most people are in the same boat. If you're willing to put that kind of effort in, good for you, but it would be misleading to say that I'd have the time to see it through to the end. If you want to do that, go ahead and find other people who are willing to make it work; that's what I've trying to do for this effort. -- Mark Nottingham http://www.mnot.net/ From discuss-bounces@apps.ietf.org Thu May 31 21:12:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htvge-0003Rc-E1; Thu, 31 May 2007 21:12:16 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Htvgd-0003RT-Pt for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 21:12:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htvgd-0003RI-GH for discuss@apps.ietf.org; Thu, 31 May 2007 21:12:15 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htvgc-00038l-90 for discuss@apps.ietf.org; Thu, 31 May 2007 21:12:15 -0400 Received: from [127.0.0.1] (unknown [216.145.54.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 65B415190F; Thu, 31 May 2007 21:12:11 -0400 (EDT) In-Reply-To: <68fba5c50705311804w2d39ea88o985d9b6a8aa33220@mail.gmail.com> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <1358AF2C-F967-46D6-B291-BC65126CCDF6@gbiv.com> <8FBD37BC-E635-485D-A368-22D9DE332498@mnot.net> <68fba5c50705311804w2d39ea88o985d9b6a8aa33220@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6C26C1C5-B99B-41EA-989A-F86DCF8489FC@mnot.net> Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: Straw-man charter for http-bis Date: Fri, 1 Jun 2007 11:12:08 +1000 To: "Robert Sayre" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Apps Discuss , "Roy T. Fielding" , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On 01/06/2007, at 11:04 AM, Robert Sayre wrote: > I don't understand why the two approaches are mutually exclusive. I > think the best way to start is by doing exactly what has been done so > far. I agree with Roy that we shouldn't rule out large scale > restructuring at some point, but it might be better to let everyone > look at a few rounds of diffs before any major structural changes are > made. The issues list is already getting a little big. Agreed. As I said earlier, we've already talked about rearranging sections, and maybe rewriting parts of the caching section. Perhaps we're just talking past each other -- Roy, are you really talking about a wholesale rewrite, or rearranging parts, or what? If you gave us an idea of what you want to do, it might help make this discussion more productive. -- Mark Nottingham http://www.mnot.net/