From w3c-dist-auth-request@w3.org Tue Feb 1 21:15:41 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01829 for ; Tue, 1 Feb 2005 21:15:41 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CwA1U-0008PE-Io for w3c-dist-auth-dist@listhub.w3.org; Wed, 02 Feb 2005 02:13:40 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CwA1T-0008Nq-H9 for w3c-dist-auth@listhub.w3.org; Wed, 02 Feb 2005 02:13:39 +0000 Received: from mail-out3.apple.com ([17.254.13.22]) by bart.w3.org with esmtp (Exim 4.34) id 1CwA1T-0007d2-8i for w3c-dist-auth@w3.org; Wed, 02 Feb 2005 02:13:39 +0000 Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id j122D7gE025130 for ; Tue, 1 Feb 2005 18:13:07 -0800 (PST) Received: from relay1.apple.com (relay1.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Tue, 1 Feb 2005 18:13:07 -0800 Received: from [17.112.106.98] ([17.112.106.98]) by relay1.apple.com (8.12.11/8.12.11) with ESMTP id j122D5U1013989 for ; Tue, 1 Feb 2005 18:13:06 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <41FB5226.6050302@gmx.de> References: <41F81BBF.7030104@gmx.de> <488030720501281650450266cb@mail.gmail.com> <41FB5226.6050302@gmx.de> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <53ac68ca9787da99649784df8a7f2790@apple.com> Content-Transfer-Encoding: 7bit From: John Baumgarten Date: Tue, 1 Feb 2005 18:13:04 -0800 To: w3c-dist-auth@w3.org X-Mailer: Apple Mail (2.619.2) Received-SPF: pass (bart.w3.org: domain of jbaumgarten@apple.com designates 17.254.13.22 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: lock-null's Still Locked after MKCOL or PUT conversion? X-Archived-At: http://www.w3.org/mid/53ac68ca9787da99649784df8a7f2790@apple.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9382 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 02 Feb 2005 02:13:40 +0000 Content-Transfer-Encoding: 7bit BTW, at Apple (.Mac, that is) we will be moving away from lock-nulls toward a 2518bis-06 style treatment of "namespace reservation". As suggested, we create a zero-byte locked resource, but we add with a special property "namespace-reservation" in our server namespace. The value of this property is the lock-token that created it. We allow the following "legacy" behavior on a namespace-reservation resource: 1. If converted by any PUT, the special property is removed. Thus the resource is no longer a "namespace-reservation". 2. A MKCOL is allowed on this resource if the namespace-reservation property is still present, which then removes the special property. 3. If an UNLOCK method is successfully executed on the resource passing the lock-token that created the namespace-reservation, while it still possess the special property, the resource is deleted. Successful execution requires ownership of the lock. From w3c-dist-auth-request@w3.org Wed Feb 2 08:43:36 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02654 for ; Wed, 2 Feb 2005 08:43:35 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CwKlb-0006wy-2k for w3c-dist-auth-dist@listhub.w3.org; Wed, 02 Feb 2005 13:41:59 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CwKla-0006wU-2t for w3c-dist-auth@listhub.w3.org; Wed, 02 Feb 2005 13:41:58 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.34) id 1CwKlP-0003fr-8t for w3c-dist-auth@w3.org; Wed, 02 Feb 2005 13:41:47 +0000 Received: (qmail invoked by alias); 02 Feb 2005 13:41:26 -0000 Received: from p50824A45.dip0.t-ipconnect.de (EHLO [192.168.1.20]) (80.130.74.69) by mail.gmx.net (mp009) with SMTP; 02 Feb 2005 14:41:26 +0100 X-Authenticated: #1915285 Message-ID: <4200D884.1030305@gmx.de> Date: Wed, 02 Feb 2005 14:41:24 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baumgarten CC: w3c-dist-auth@w3.org References: <41F81BBF.7030104@gmx.de> <488030720501281650450266cb@mail.gmail.com> <41FB5226.6050302@gmx.de> <53ac68ca9787da99649784df8a7f2790@apple.com> In-Reply-To: <53ac68ca9787da99649784df8a7f2790@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: lock-null's Still Locked after MKCOL or PUT conversion? X-Archived-At: http://www.w3.org/mid/4200D884.1030305@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9383 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 02 Feb 2005 13:41:59 +0000 Content-Transfer-Encoding: 7bit John Baumgarten wrote: > > BTW, at Apple (.Mac, that is) we will be moving away from lock-nulls > toward a 2518bis-06 style treatment of "namespace reservation". As > suggested, we create a zero-byte locked resource, but we add with a > special property "namespace-reservation" in our server namespace. The > value of this property is the lock-token that created it. > > We allow the following "legacy" behavior on a namespace-reservation > resource: > > 1. If converted by any PUT, the special property is removed. Thus the > resource is no longer a "namespace-reservation". > > 2. A MKCOL is allowed on this resource if the namespace-reservation > property is still present, which then removes the special property. > > 3. If an UNLOCK method is successfully executed on the resource passing > the lock-token that created the namespace-reservation, while it still > possess the special property, the resource is deleted. Successful > execution requires ownership of the lock. So, in the end they behave again like the original lock-null resources? What exactly is the point in making that change then? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Feb 2 10:58:56 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20698 for ; Wed, 2 Feb 2005 10:58:56 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CwMs3-0001KW-Rh for w3c-dist-auth-dist@listhub.w3.org; Wed, 02 Feb 2005 15:56:47 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CwMs2-0001Jq-QM for w3c-dist-auth@listhub.w3.org; Wed, 02 Feb 2005 15:56:46 +0000 Received: from mail-out3.apple.com ([17.254.13.22]) by lisa.w3.org with esmtp (Exim 4.34) id 1CwMrs-0001le-1t for w3c-dist-auth@w3.org; Wed, 02 Feb 2005 15:56:36 +0000 Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id j12FuFCn023388 for ; Wed, 2 Feb 2005 07:56:15 -0800 (PST) Received: from relay4.apple.com (relay4.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Wed, 2 Feb 2005 07:56:15 -0800 Received: from [17.207.15.105] (baumjo.apple.com [17.207.15.105]) by relay4.apple.com (8.12.11/8.12.11) with ESMTP id j12FuC9c028057 for ; Wed, 2 Feb 2005 07:56:13 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <4200D884.1030305@gmx.de> References: <41F81BBF.7030104@gmx.de> <488030720501281650450266cb@mail.gmail.com> <41FB5226.6050302@gmx.de> <53ac68ca9787da99649784df8a7f2790@apple.com> <4200D884.1030305@gmx.de> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Baumgarten Date: Wed, 2 Feb 2005 07:56:11 -0800 To: w3c-dist-auth@w3.org X-Mailer: Apple Mail (2.619) Received-SPF: pass (lisa.w3.org: domain of jbaumgarten@apple.com designates 17.254.13.22 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: lock-null's Still Locked after MKCOL or PUT conversion? X-Archived-At: http://www.w3.org/mid/F593EDDE-7532-11D9-9C14-000A95A69B20@apple.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9384 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 02 Feb 2005 15:56:47 +0000 Content-Transfer-Encoding: 7bit Julian- The advantages of "Namespace-reservation" (NR) resources: 1. NRs do not have the "strange" behavior of existing for some methods, but not for others. 2. Legacy clients that use lock-nulls in the most common way should still work. 3. Conversely, the server is more forgiving for less robust or less protocol-savvy clients that unintentionally lock non-existent resources that they intend to use as collections. 4. The above points are achieved without further complicating COPY or MOVE operations, which have been highly optimized for performance in our environment. -Jake On Feb 2, 2005, at 5:41 AM, Julian Reschke wrote: > John Baumgarten wrote: >> BTW, at Apple (.Mac, that is) we will be moving away from lock-nulls >> toward a 2518bis-06 style treatment of "namespace reservation". As >> suggested, we create a zero-byte locked resource, but we add with a >> special property "namespace-reservation" in our server namespace. >> The value of this property is the lock-token that created it. >> We allow the following "legacy" behavior on a namespace-reservation >> resource: >> 1. If converted by any PUT, the special property is removed. Thus >> the resource is no longer a "namespace-reservation". >> 2. A MKCOL is allowed on this resource if the namespace-reservation >> property is still present, which then removes the special property. >> 3. If an UNLOCK method is successfully executed on the resource >> passing the lock-token that created the namespace-reservation, while >> it still possess the special property, the resource is deleted. >> Successful execution requires ownership of the lock. > > So, in the end they behave again like the original lock-null > resources? What exactly is the point in making that change then? > > Best regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Feb 2 14:17:42 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16021 for ; Wed, 2 Feb 2005 14:17:41 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CwPz1-0005Vw-20 for w3c-dist-auth-dist@listhub.w3.org; Wed, 02 Feb 2005 19:16:11 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CwPyx-0005VM-Sf for w3c-dist-auth@listhub.w3.org; Wed, 02 Feb 2005 19:16:07 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CwPyn-0001Sx-3N for w3c-dist-auth@w3.org; Wed, 02 Feb 2005 19:15:57 +0000 Received: (qmail invoked by alias); 02 Feb 2005 19:15:33 -0000 Received: from pD953514A.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.81.74) by mail.gmx.net (mp002) with SMTP; 02 Feb 2005 20:15:33 +0100 X-Authenticated: #1915285 Message-ID: <420126D1.3080001@gmx.de> Date: Wed, 02 Feb 2005 20:15:29 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baumgarten CC: w3c-dist-auth@w3.org References: <41F81BBF.7030104@gmx.de> <488030720501281650450266cb@mail.gmail.com> <41FB5226.6050302@gmx.de> <53ac68ca9787da99649784df8a7f2790@apple.com> <4200D884.1030305@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: lock-null's Still Locked after MKCOL or PUT conversion? X-Archived-At: http://www.w3.org/mid/420126D1.3080001@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9385 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 02 Feb 2005 19:16:11 +0000 Content-Transfer-Encoding: 7bit John Baumgarten wrote: > > Julian- > > The advantages of "Namespace-reservation" (NR) resources: > > 1. NRs do not have the "strange" behavior of existing for some methods, > but not for others. > > 2. Legacy clients that use lock-nulls in the most common way should > still work. > > 3. Conversely, the server is more forgiving for less robust or less > protocol-savvy clients that unintentionally lock non-existent resources > that they intend to use as collections. > > 4. The above points are achieved without further complicating COPY or > MOVE operations, which have been highly optimized for performance in our > environment. With 1, 2 and I agree (but that also applies to simply creating empty, locked resources with no special behaviour). 3) is interesting; I'm not aware of any clients doing this (at least our server product doesn't seem to have any clients suffering from it). So to me this sounds like putting (still) additional complexity into the server implementation that's unneeded (but as usual, your mileage my vary). Of course things look different if indeed you have to support clients that rely on 3). If you do, it would be interesting to the WG to learn which clients these are, because they will break with a pure RFC2518bis as well... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Feb 2 14:56:26 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21000 for ; Wed, 2 Feb 2005 14:56:26 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CwQb5-0002Tf-QA for w3c-dist-auth-dist@listhub.w3.org; Wed, 02 Feb 2005 19:55:31 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CwQb3-0002T2-Pm for w3c-dist-auth@listhub.w3.org; Wed, 02 Feb 2005 19:55:30 +0000 Received: from mail-out4.apple.com ([17.254.13.23]) by lisa.w3.org with esmtp (Exim 4.34) id 1CwQat-0007zG-20 for w3c-dist-auth@w3.org; Wed, 02 Feb 2005 19:55:19 +0000 Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id j12Jswpe016599 for ; Wed, 2 Feb 2005 11:54:58 -0800 (PST) Received: from relay3.apple.com (relay3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Wed, 2 Feb 2005 11:54:58 -0800 Received: from [17.207.15.105] (baumjo.apple.com [17.207.15.105]) by relay3.apple.com (8.12.11/8.12.11) with ESMTP id j12JstoD019076 for ; Wed, 2 Feb 2005 11:54:56 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <420126D1.3080001@gmx.de> References: <41F81BBF.7030104@gmx.de> <488030720501281650450266cb@mail.gmail.com> <41FB5226.6050302@gmx.de> <53ac68ca9787da99649784df8a7f2790@apple.com> <4200D884.1030305@gmx.de> <420126D1.3080001@gmx.de> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4F7C336A-7554-11D9-9763-000A95A69B20@apple.com> Content-Transfer-Encoding: 7bit From: John Baumgarten Date: Wed, 2 Feb 2005 11:54:55 -0800 To: w3c-dist-auth@w3.org X-Mailer: Apple Mail (2.619) Received-SPF: pass (lisa.w3.org: domain of jbaumgarten@apple.com designates 17.254.13.23 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: lock-null's Still Locked after MKCOL or PUT conversion? X-Archived-At: http://www.w3.org/mid/4F7C336A-7554-11D9-9763-000A95A69B20@apple.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9386 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 02 Feb 2005 19:55:31 +0000 Content-Transfer-Encoding: 7bit Julian- Apple has announced and is now supporting an SDK for our operating system (Mac OS X) that wraps the WebDAV protocol into a framework that is highly compatible with other application development frameworks on Mac OS X. This allows rapid development of application features that take advantage of our .Mac iDisk service, which is based almost exclusively on the WebDAV protocol. (Some features preceded full development of similar ones in WebDAV, such as quota.) The point here is not to make a product plug, but to explain that these SDK clients have a simplified view of WebDAV operations, with a focus on solving distributed application collaboration issues. Back to issue (3.) below, they may not check for existence before locking. -Jake On Feb 2, 2005, at 11:15 AM, Julian Reschke wrote: > John Baumgarten wrote: >> Julian- >> The advantages of "Namespace-reservation" (NR) resources: >> 1. NRs do not have the "strange" behavior of existing for some >> methods, but not for others. >> 2. Legacy clients that use lock-nulls in the most common way should >> still work. >> 3. Conversely, the server is more forgiving for less robust or less >> protocol-savvy clients that unintentionally lock non-existent >> resources that they intend to use as collections. >> 4. The above points are achieved without further complicating COPY >> or MOVE operations, which have been highly optimized for performance >> in our environment. > > With 1, 2 and I agree (but that also applies to simply creating empty, > locked resources with no special behaviour). > > 3) is interesting; I'm not aware of any clients doing this (at least > our server product doesn't seem to have any clients suffering from > it). > > So to me this sounds like putting (still) additional complexity into > the server implementation that's unneeded (but as usual, your mileage > my vary). Of course things look different if indeed you have to > support clients that rely on 3). If you do, it would be interesting to > the WG to learn which clients these are, because they will break with > a pure RFC2518bis as well... > > > Best regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Feb 2 15:16:33 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23613 for ; Wed, 2 Feb 2005 15:16:33 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CwQum-0000HY-Od for w3c-dist-auth-dist@listhub.w3.org; Wed, 02 Feb 2005 20:15:52 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CwQum-0000H3-BC for w3c-dist-auth@listhub.w3.org; Wed, 02 Feb 2005 20:15:52 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1CwQum-0004X0-1E for w3c-dist-auth@w3.org; Wed, 02 Feb 2005 20:15:52 +0000 Received: (qmail invoked by alias); 02 Feb 2005 20:15:20 -0000 Received: from pD9535E91.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.94.145) by mail.gmx.net (mp020) with SMTP; 02 Feb 2005 21:15:20 +0100 X-Authenticated: #1915285 Message-ID: <420134D1.1010103@gmx.de> Date: Wed, 02 Feb 2005 21:15:13 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baumgarten CC: w3c-dist-auth@w3.org References: <41F81BBF.7030104@gmx.de> <488030720501281650450266cb@mail.gmail.com> <41FB5226.6050302@gmx.de> <53ac68ca9787da99649784df8a7f2790@apple.com> <4200D884.1030305@gmx.de> <420126D1.3080001@gmx.de> <4F7C336A-7554-11D9-9763-000A95A69B20@apple.com> In-Reply-To: <4F7C336A-7554-11D9-9763-000A95A69B20@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: lock-null's Still Locked after MKCOL or PUT conversion? X-Archived-At: http://www.w3.org/mid/420134D1.1010103@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9387 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 02 Feb 2005 20:15:52 +0000 Content-Transfer-Encoding: 7bit John Baumgarten wrote: > > Julian- > > Apple has announced and is now supporting an SDK for our operating > system (Mac OS X) that wraps the WebDAV protocol into a framework that > is highly compatible with other application development frameworks on > Mac OS X. This allows rapid development of application features that > take advantage of our .Mac iDisk service, which is based almost > exclusively on the WebDAV protocol. (Some features preceded full > development of similar ones in WebDAV, such as quota.) > > The point here is not to make a product plug, but to explain that these Jake, there's no problem at all with talking about specific clients. In fact, this mailing list historically has seen little direct feedback from client implementers, so any kind of feedback is very valuable. > SDK clients have a simplified view of WebDAV operations, with a focus on > solving distributed application collaboration issues. Back to issue > (3.) below, they may not check for existence before locking. Just checking: the SDK allows people to write code without any knowledge of WebDAV protocol, and potentially enables them to write code that basically relies on the "classic" lock-null resources (LOCK uri then MKCOL uri, ...)? If the SDK is supposed to work with pure RFC2518bis servers (is it?), we're facing a problem here. Did you consider to *also* deprecate this kind of operations? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Feb 2 15:33:32 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25755 for ; Wed, 2 Feb 2005 15:33:32 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CwRAv-0004qY-HV for w3c-dist-auth-dist@listhub.w3.org; Wed, 02 Feb 2005 20:32:33 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CwRAu-0004pz-O0 for w3c-dist-auth@listhub.w3.org; Wed, 02 Feb 2005 20:32:32 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CwRAj-000560-Uz for w3c-dist-auth@w3.org; Wed, 02 Feb 2005 20:32:22 +0000 Received: (qmail invoked by alias); 02 Feb 2005 20:32:00 -0000 Received: from pD9535E91.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.94.145) by mail.gmx.net (mp017) with SMTP; 02 Feb 2005 21:32:00 +0100 X-Authenticated: #1915285 Message-ID: <420138B7.3060502@gmx.de> Date: Wed, 02 Feb 2005 21:31:51 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: WG last call on BIND X-Archived-At: http://www.w3.org/mid/420138B7.3060502@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9388 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 02 Feb 2005 20:32:33 +0000 Content-Transfer-Encoding: 7bit Hi, the working group last call for BIND ended today (see announcement in ). As far as I can tell, we have a few issues left that we need to close in some way or another before we can submit a new draft for IETF last call: 1) "Bindings needs to completely describe how bindings interact with locks." In my opinion, we have clarified semantics where RFC2518 + BIND (draft 10) indeed were unclear. Lisa Dusseault has asked for additional clarifications on LOCK refresh behaviour, but IMHO didn't provide any compelling argument why this needs additional spec text. So I'm +1 for closing this as "resolved". 2) "Bindings and DeltaV aren't fully interspecified" I think we have reached some kind of consensus that the spec shouldn't say anything specific about BIND implications for RFC3253. Where we disagree is whether it actually needs to state that certain things are out-of-scope, and in which way. As far as I can tell, the whole discussion is contained in the bug tracker comments, so it would be nice if people would review the whole bug history and give some feedback about whether something needs to be done and what. 3) "Clarify what servers may and may not do with privileges when BIND is used" As far as I'm concerned, this has nothing to do with BIND, and, if this really is a problem, needs to be discussed in RFC3744 errata. Therefore it should be closed (in the current form of a issue raised against BIND). Note that if we can get these issues resolved within the next two weeks, we'll be able to submit a draft for IETF last call in time before the next IETF meeting. Thanks to all who reviewed the spec in the last few weeks! Please also review all changes that have been made since draft -10 in . Best regards, Julian Reschke -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Feb 2 16:39:24 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10299 for ; Wed, 2 Feb 2005 16:39:23 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CwSCQ-0008QG-8u for w3c-dist-auth-dist@listhub.w3.org; Wed, 02 Feb 2005 21:38:10 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CwSCP-0008PM-4u for w3c-dist-auth@listhub.w3.org; Wed, 02 Feb 2005 21:38:09 +0000 Received: from mail-out4.apple.com ([17.254.13.23]) by lisa.w3.org with esmtp (Exim 4.34) id 1CwSCE-0006iu-DK for w3c-dist-auth@w3.org; Wed, 02 Feb 2005 21:37:58 +0000 Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id j12LbbX9013214 for ; Wed, 2 Feb 2005 13:37:37 -0800 (PST) Received: from relay2.apple.com (relay2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Wed, 2 Feb 2005 13:37:37 -0800 Received: from [17.207.15.105] (baumjo.apple.com [17.207.15.105]) by relay2.apple.com (8.12.11/8.12.11) with ESMTP id j12LbZMn023913 for ; Wed, 2 Feb 2005 13:37:36 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <420134D1.1010103@gmx.de> References: <41F81BBF.7030104@gmx.de> <488030720501281650450266cb@mail.gmail.com> <41FB5226.6050302@gmx.de> <53ac68ca9787da99649784df8a7f2790@apple.com> <4200D884.1030305@gmx.de> <420126D1.3080001@gmx.de> <4F7C336A-7554-11D9-9763-000A95A69B20@apple.com> <420134D1.1010103@gmx.de> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Baumgarten Date: Wed, 2 Feb 2005 13:37:35 -0800 To: w3c-dist-auth@w3.org X-Mailer: Apple Mail (2.619) Received-SPF: pass (lisa.w3.org: domain of jbaumgarten@apple.com designates 17.254.13.23 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: lock-null's Still Locked after MKCOL or PUT conversion? X-Archived-At: http://www.w3.org/mid/A74F91EE-7562-11D9-9763-000A95A69B20@apple.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9389 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 02 Feb 2005 21:38:10 +0000 Content-Transfer-Encoding: 7bit Julian- See below. Cheers and thanks for the feedback. -Jake On Feb 2, 2005, at 12:15 PM, Julian Reschke wrote: > John Baumgarten wrote: >> Apple has announced and is now supporting an SDK for our operating >> system (Mac OS X) that wraps the WebDAV protocol into a framework >> that is highly compatible with other application development >> frameworks on Mac OS X. This allows rapid development of application >> features that take advantage of our .Mac iDisk service, which is >> based almost exclusively on the WebDAV protocol. (Some features >> preceded full development of similar ones in WebDAV, such as quota.) >> The point here is not to make a product plug, but to explain that >> these SDK clients have a simplified view of WebDAV operations, with a >> focus on solving distributed application collaboration issues. Back >> to issue (3.) below, they may not check for existence before locking. > > Just checking: the SDK allows people to write code without any > knowledge of WebDAV protocol, Yes > and potentially enables them to write code that basically relies on > the "classic" lock-null resources (LOCK uri then MKCOL uri, ...)? They do not expect a locking operation to preclude a resource from being a collection, so yes > > If the SDK is supposed to work with pure RFC2518bis servers (is it?), > we're facing a problem here. Currently the SDK only works with .Mac, but we supply "usage guidelines" that would result in desired behavior most of the time, with servers supporting either 2518 or 2518bis or our compromise. Specifically, check for existence first. However, we have some "clients" (actually other web-servicing applications) with very high transaction rates and a high probably of multiple concurrent operations on the same resource. So retaining a lock-with-create-but-allow-collection scenario solves some tricky timing issues. Since our service tightly integrates a high-volume web pump with WebDAV "write" operations, providing sufficient performance while maintaining method transaction integrity is quite a challenge. > Did you consider to *also* deprecate this kind of operations? > > Best regards, Julian From w3c-dist-auth-request@w3.org Wed Feb 2 17:08:53 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14935 for ; Wed, 2 Feb 2005 17:08:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CwSfU-0001Ia-VV for w3c-dist-auth-dist@listhub.w3.org; Wed, 02 Feb 2005 22:08:12 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CwSfT-0001I5-Ea for w3c-dist-auth@listhub.w3.org; Wed, 02 Feb 2005 22:08:11 +0000 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by bart.w3.org with esmtp (Exim 4.34) id 1CwSfS-0004xn-UW for w3c-dist-auth@w3.org; Wed, 02 Feb 2005 22:08:11 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id j12M7cXB027267 for ; Wed, 2 Feb 2005 17:07:38 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j12M7ccP280350 for ; Wed, 2 Feb 2005 17:07:38 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j12M7cQZ009620 for ; Wed, 2 Feb 2005 17:07:38 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j12M7b7c009604 for ; Wed, 2 Feb 2005 17:07:37 -0500 In-Reply-To: <420138B7.3060502@gmx.de> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Wed, 2 Feb 2005 17:07:39 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 02/02/2005 17:07:37, Serialize complete at 02/02/2005 17:07:37 Content-Type: multipart/alternative; boundary="=_alternative 00798CBB85256F9C_=" Received-SPF: pass (bart.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.145 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: WG last call on BIND X-Archived-At: http://www.w3.org/mid/OFAE6892BE.8D951E98-ON85256F9C.00797CA0-85256F9C.00798CBC@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9390 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 02 Feb 2005 22:08:12 +0000 This is a multipart message in MIME format. --=_alternative 00798CBB85256F9C_= Content-Type: text/plain; charset="US-ASCII" +1 on closing these three issues as resolved. Cheers, Geoff Julian wrote on 02/02/2005 03:31:51 PM: > > Hi, > > the working group last call for BIND ended today (see announcement in > ). > > As far as I can tell, we have a few issues left that we need to close in > some way or another before we can submit a new draft for IETF last call: > > > 1) "Bindings needs to completely describe how bindings interact with > locks." > > In my opinion, we have clarified semantics where RFC2518 + BIND (draft > 10) indeed were unclear. Lisa Dusseault has asked for additional > clarifications on LOCK refresh behaviour, but IMHO didn't provide any > compelling argument why this needs additional spec text. > > So I'm +1 for closing this as "resolved". > > > 2) "Bindings and DeltaV aren't fully interspecified" > > > I think we have reached some kind of consensus that the spec shouldn't > say anything specific about BIND implications for RFC3253. Where we > disagree is whether it actually needs to state that certain things are > out-of-scope, and in which way. As far as I can tell, the whole > discussion is contained in the bug tracker comments, so it would be nice > if people would review the whole bug history and give some feedback > about whether something needs to be done and what. > > > 3) "Clarify what servers may and may not do with privileges when BIND is > used" > > As far as I'm concerned, this has nothing to do with BIND, and, if this > really is a problem, needs to be discussed in RFC3744 errata. Therefore > it should be closed (in the current form of a issue raised against BIND). > > > Note that if we can get these issues resolved within the next two weeks, > we'll be able to submit a draft for IETF last call in time before the > next IETF meeting. > > Thanks to all who reviewed the spec in the last few weeks! > > Please also review all changes that have been made since draft -10 in > >. > > > Best regards, > > Julian Reschke > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > --=_alternative 00798CBB85256F9C_= Content-Type: text/html; charset="US-ASCII"
+1 on closing these three issues as resolved.

Cheers,
Geoff

Julian wrote on 02/02/2005 03:31:51 PM:

>
> Hi,
>
> the working group last call for BIND ended today (see announcement in
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JanMar/0001.html>).
>
> As far as I can tell, we have a few issues left that we need to close in
> some way or another before we can submit a new draft for IETF last call:
>
>
> 1) "Bindings needs to completely describe how bindings interact with
> locks." <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2>
>
> In my opinion, we have clarified semantics where RFC2518 + BIND (draft
> 10) indeed were unclear. Lisa Dusseault has asked for additional
> clarifications on LOCK refresh behaviour, but IMHO didn't provide any
> compelling argument why this needs additional spec text.
>
> So I'm +1 for closing this as "resolved".
>
>
> 2) "Bindings and DeltaV aren't fully interspecified"
> <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=5>
>
> I think we have reached some kind of consensus that the spec shouldn't
> say anything specific about BIND implications for RFC3253. Where we
> disagree is whether it actually needs to state that certain things are
> out-of-scope, and in which way. As far as I can tell, the whole
> discussion is contained in the bug tracker comments, so it would be nice
> if people would review the whole bug history and give some feedback
> about whether something needs to be done and what.
>
>
> 3) "Clarify what servers may and may not do with privileges when BIND is
> used" <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=71>
>
> As far as I'm concerned, this has nothing to do with BIND, and, if this
> really is a problem, needs to be discussed in RFC3744 errata. Therefore
> it should be closed (in the current form of a issue raised against BIND).
>
>
> Note that if we can get these issues resolved within the next two weeks,
> we'll be able to submit a draft for IETF last call in time before the
> next IETF meeting.
>
> Thanks to all who reviewed the spec in the last few weeks!
>
> Please also review all changes that have been made since draft -10 in
> <http://www.webdav.org/bind/draft-ietf-webdav-bind-latest.html#rfc.section.A.9
> >.
>
>
> Best regards,
>
> Julian Reschke
>
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
--=_alternative 00798CBB85256F9C_=-- From w3c-dist-auth-request@w3.org Wed Feb 2 17:50:54 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21738 for ; Wed, 2 Feb 2005 17:50:54 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CwTJd-0007q2-0A for w3c-dist-auth-dist@listhub.w3.org; Wed, 02 Feb 2005 22:49:41 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CwTJc-0007pX-Ku for w3c-dist-auth@listhub.w3.org; Wed, 02 Feb 2005 22:49:40 +0000 Received: from mail23.sea5.speakeasy.net ([69.17.117.25]) by bart.w3.org with esmtp (Exim 4.34) id 1CwTJc-0003Yd-FF for w3c-dist-auth@w3.org; Wed, 02 Feb 2005 22:49:40 +0000 Received: (qmail 16127 invoked from network); 2 Feb 2005 22:49:38 -0000 Received: from adsl-63-194-88-161.dsl.snfc21.pacbell.net (HELO cse.ucsc.edu) (elias@[63.194.88.161]) (envelope-sender ) by mail23.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 2 Feb 2005 22:49:38 -0000 Message-ID: <42015885.30409@cse.ucsc.edu> Date: Wed, 02 Feb 2005 14:47:33 -0800 From: Elias Sinderson Reply-To: w3c-dist-auth@w3.org User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <420138B7.3060502@gmx.de> In-Reply-To: <420138B7.3060502@gmx.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: none (bart.w3.org: domain of elias@cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: WG last call on BIND X-Archived-At: http://www.w3.org/mid/42015885.30409@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9391 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 02 Feb 2005 22:49:41 +0000 Content-Transfer-Encoding: 7bit Julian Reschke wrote: > the working group last call for BIND ended today [...] As far as I can > tell, we have a few issues left that we need to close in some way or > another before we can submit a new draft for IETF last call [...] > Please also review all changes that have been made since draft -10 [...] I'm satisfied that the open issues have been addressed sufficiently and can be marked as closed. I reviewed the changes in the latest draft and am happy with the new and revised text. Cheers, Elias From w3c-dist-auth-request@w3.org Thu Feb 3 02:08:25 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14733 for ; Thu, 3 Feb 2005 02:08:25 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cwb4D-0003FQ-QS for w3c-dist-auth-dist@listhub.w3.org; Thu, 03 Feb 2005 07:06:17 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cwb4C-0003En-PN for w3c-dist-auth@listhub.w3.org; Thu, 03 Feb 2005 07:06:16 +0000 Received: from exchange.webb.net ([207.182.164.133] helo=ossex1.ossinc.net) by bart.w3.org with esmtp (Exim 4.34) id 1Cwb4B-0003u8-Ns for w3c-dist-auth@w3.org; Thu, 03 Feb 2005 07:06:16 +0000 Received: from [IPv6:::1] (gatekeeper-int.jabber.com [10.101.0.11]) by ossex1.ossinc.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id D95266L6; Wed, 2 Feb 2005 23:58:40 -0700 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <1aef7c87a3636e35da541fba00215c3c@jabber.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: webdav From: Joe Hildebrand Date: Thu, 3 Feb 2005 00:05:21 -0700 X-Mailer: Apple Mail (2.619.2) Received-SPF: none (bart.w3.org: domain of jhildebrand@jabber.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Status of working group last call on BIND X-Archived-At: http://www.w3.org/mid/1aef7c87a3636e35da541fba00215c3c@jabber.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9392 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 03 Feb 2005 07:06:17 +0000 Content-Transfer-Encoding: 7bit Please send a note to the list if you reviewed BIND for the last call. I'd like to make sure we had enough eyes on it. If there are any outstanding issues that, for whatever reason, didn't make it into Bugzilla, please enter them ASAP. I've seen a couple go by on the list that I don't see in the system. Here is a list of the issues I see on bugzilla. --- http://ietf.webdav.org:8080/bugzilla/show_bug.cgi?id=2 "Bindings needs to completely describe how bindings interact with locks." I see consensus for the clarification text proposed and wordsmithed here on the list. --- http://ietf.webdav.org:8080/bugzilla/show_bug.cgi?id=5 "Bindings and DeltaV aren't fully interspecified" Of the text I've seen for this, that says that the interaction is unspecified, I don't see enough consensus on that suggestion to hold things up. --- http://ietf.webdav.org:8080/bugzilla/show_bug.cgi?id=71 "Clarify what servers may and may not do with privileges when BIND is used" I don't see consensus for making a change. However, I want to make sure I understand the issue before I predict how the IESG will react to this during their last call. I'll post a message to the list with some thoughts. -- Joe Hildebrand Denver, CO, USA From w3c-dist-auth-request@w3.org Thu Feb 3 02:10:08 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16274 for ; Thu, 3 Feb 2005 02:10:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cwb7N-00046k-AH for w3c-dist-auth-dist@listhub.w3.org; Thu, 03 Feb 2005 07:09:33 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Cwb7N-00046G-4X for w3c-dist-auth@listhub.w3.org; Thu, 03 Feb 2005 07:09:33 +0000 Received: from exchange.webb.net ([207.182.164.133] helo=ossex1.ossinc.net) by lisa.w3.org with esmtp (Exim 4.34) id 1Cwb7C-0003Rn-F2 for w3c-dist-auth@w3.org; Thu, 03 Feb 2005 07:09:22 +0000 Received: from [IPv6:::1] (gatekeeper-int.jabber.com [10.101.0.11]) by ossex1.ossinc.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id D952663Z; Thu, 3 Feb 2005 00:01:20 -0700 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: webdav From: Joe Hildebrand Date: Thu, 3 Feb 2005 00:07:52 -0700 X-Mailer: Apple Mail (2.619.2) Received-SPF: none (lisa.w3.org: domain of jhildebrand@jabber.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: BIND and access control lists X-Archived-At: http://www.w3.org/mid/f4eb7fcd6a044ec55b39cfe38e58ade9@jabber.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9393 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 03 Feb 2005 07:09:33 +0000 Content-Transfer-Encoding: 7bit Trying to predict what the IESG might latch on to during their last call. I understand that DAV:acl is a property, which applies to the resource, not the URL. The suggestion has been made that MOVE has the same issue, but 3744 gives explicit requirements for MOVE and COPY, which differ slightly. I don't know the history of 3744, but I assume that there needed to be text for section 7.3 and 7.4 since it wasn't obvious what would happen to acl's in the face of those operations. I could imagine an IESG member who knew about the entire suite of protocols asking for the draft that added a new operation specifying how that operation fits into that suite. I would expect that a line saying "BIND is the same as MOVE with respect to acl's", "BIND is the same as COPY with respect to acl's", or a paragraph on the same lines as 7.3 or 7.4 from 3744 would be enough to answer that question. -- Joe Hildebrand From w3c-dist-auth-request@w3.org Thu Feb 3 08:19:59 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20108 for ; Thu, 3 Feb 2005 08:19:59 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CwgsU-0002GE-1C for w3c-dist-auth-dist@listhub.w3.org; Thu, 03 Feb 2005 13:18:34 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CwgsT-0002Fd-04 for w3c-dist-auth@listhub.w3.org; Thu, 03 Feb 2005 13:18:33 +0000 Received: from e1.ny.us.ibm.com ([32.97.182.141]) by bart.w3.org with esmtp (Exim 4.34) id 1CwgsS-0001mx-RU for w3c-dist-auth@w3.org; Thu, 03 Feb 2005 13:18:32 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id j13DI2bs009658 for ; Thu, 3 Feb 2005 08:18:02 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j13DI2oH130154 for ; Thu, 3 Feb 2005 08:18:02 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j13DI1Us016077 for ; Thu, 3 Feb 2005 08:18:01 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j13DI1sO016072 for ; Thu, 3 Feb 2005 08:18:01 -0500 In-Reply-To: To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Thu, 3 Feb 2005 08:18:15 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 02/03/2005 08:18:01, Serialize complete at 02/03/2005 08:18:01 Content-Type: multipart/alternative; boundary="=_alternative 00490FC485256F9D_=" Received-SPF: pass (bart.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.141 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: BIND and access control lists X-Archived-At: http://www.w3.org/mid/OF58C7576F.9586DDFA-ON85256F9D.004745D0-85256F9D.00490FC8@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9394 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 03 Feb 2005 13:18:34 +0000 This is a multipart message in MIME format. --=_alternative 00490FC485256F9D_= Content-Type: text/plain; charset="US-ASCII" The statement that would be consistent with 3744 would be "BIND is the same as MOVE with respect to the DAV:acl property". (I prefer to state it that way, rather than copying the paragraphs from 3744, since that allows us to modify DAV:acl behavior in 3744bis without having to revise the binding specification). If nobody objects to that behavior, then I am happy to add that sentence to the BIND specification. If anyone objects to that behavior, then that is an issue against 3744, and then I believe the BIND specification should remain silent on the topic, and the issue should be raised against 3744 for resolution. Cheers, Geoff Joe wrote on 02/03/2005 02:07:52 AM: > > Trying to predict what the IESG might latch on to during their last > call. > > I understand that DAV:acl is a property, which applies to the resource, > not the URL. The suggestion has been made that MOVE has the same > issue, but 3744 gives explicit requirements for MOVE and COPY, which > differ slightly. I don't know the history of 3744, but I assume that > there needed to be text for section 7.3 and 7.4 since it wasn't obvious > what would happen to acl's in the face of those operations. > > I could imagine an IESG member who knew about the entire suite of > protocols asking for the draft that added a new operation specifying > how that operation fits into that suite. I would expect that a line > saying "BIND is the same as MOVE with respect to acl's", "BIND is the > same as COPY with respect to acl's", or a paragraph on the same lines > as 7.3 or 7.4 from 3744 would be enough to answer that question. > > -- > Joe Hildebrand > > --=_alternative 00490FC485256F9D_= Content-Type: text/html; charset="US-ASCII"
The statement that would be consistent with 3744 would be
"BIND is the same as MOVE with respect to the DAV:acl property".  
(I prefer to state it that way, rather than copying the
paragraphs from 3744, since that allows us to modify
DAV:acl behavior in 3744bis without having to revise the
binding specification).

If nobody objects to that behavior, then I am happy to add
that sentence to the BIND specification.

If anyone objects to that behavior, then that is an issue
against 3744, and then I believe the BIND specification
should remain silent on the topic, and the issue should be raised
against 3744 for resolution.

Cheers,
Geoff

Joe wrote on 02/03/2005 02:07:52 AM:

>
> Trying to predict what the IESG might latch on to during their last
> call.
>
> I understand that DAV:acl is a property, which applies to the resource,
> not the URL.  The suggestion has been made that MOVE has the same
> issue, but 3744 gives explicit requirements for MOVE and COPY, which
> differ slightly.  I don't know the history of 3744, but I assume that
> there needed to be text for section 7.3 and 7.4 since it wasn't obvious
> what would happen to acl's in the face of those operations.
>
> I could imagine an IESG member who knew about the entire suite of
> protocols asking for the draft that added a new operation specifying
> how that operation fits into that suite.  I would expect that a line
> saying "BIND is the same as MOVE with respect to acl's", "BIND is the
> same as COPY with respect to acl's", or a paragraph on the same lines
> as 7.3 or 7.4 from 3744 would be enough to answer that question.
>
> --
> Joe Hildebrand
>
>
--=_alternative 00490FC485256F9D_=-- From w3c-dist-auth-request@w3.org Thu Feb 3 12:27:46 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18149 for ; Thu, 3 Feb 2005 12:27:45 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cwkjf-0008QM-5r for w3c-dist-auth-dist@listhub.w3.org; Thu, 03 Feb 2005 17:25:43 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Cwkje-0008Of-7C for w3c-dist-auth@listhub.w3.org; Thu, 03 Feb 2005 17:25:42 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CwkjT-0004XU-84 for w3c-dist-auth@w3.org; Thu, 03 Feb 2005 17:25:31 +0000 Received: (qmail invoked by alias); 03 Feb 2005 17:25:08 -0000 Received: from p50824E32.dip0.t-ipconnect.de (EHLO [192.168.1.20]) (80.130.78.50) by mail.gmx.net (mp022) with SMTP; 03 Feb 2005 18:25:08 +0100 X-Authenticated: #1915285 Message-ID: <42025E6E.7020908@gmx.de> Date: Thu, 03 Feb 2005 18:25:02 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geoffrey M Clemm CC: webdav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: BIND and access control lists X-Archived-At: http://www.w3.org/mid/42025E6E.7020908@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9395 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 03 Feb 2005 17:25:43 +0000 Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > > The statement that would be consistent with 3744 would be > "BIND is the same as MOVE with respect to the DAV:acl property". ...same for REBIND... > (I prefer to state it that way, rather than copying the > paragraphs from 3744, since that allows us to modify > DAV:acl behavior in 3744bis without having to revise the > binding specification). +1 > If nobody objects to that behavior, then I am happy to add > that sentence to the BIND specification. So where should that statement go (or these statements when we include UNBIND)? Should we insert a new top-level paragraph stating the behaviour? > If anyone objects to that behavior, then that is an issue > against 3744, and then I believe the BIND specification > should remain silent on the topic, and the issue should be raised > against 3744 for resolution. +1 Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Feb 3 12:54:31 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20431 for ; Thu, 3 Feb 2005 12:54:31 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CwlAp-000285-Au for w3c-dist-auth-dist@listhub.w3.org; Thu, 03 Feb 2005 17:53:47 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CwlAp-00027V-41 for w3c-dist-auth@listhub.w3.org; Thu, 03 Feb 2005 17:53:47 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CwlAe-0001Ld-B2 for w3c-dist-auth@w3.org; Thu, 03 Feb 2005 17:53:36 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j13HrksK017341; Thu, 3 Feb 2005 09:53:46 -0800 Date: Thu, 3 Feb 2005 09:53:46 -0800 Message-Id: <200502031753.j13HrksK017341@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 76] New: What event does creationdate refer to X-Archived-At: http://www.w3.org/mid/200502031753.j13HrksK017341@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9396 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 03 Feb 2005 17:53:47 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=76 Summary: What event does creationdate refer to Product: WebDAV-BIND Version: -latest Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 04. BIND Method AssignedTo: julian.reschke@greenbytes.de ReportedBy: lisa@osafoundation.org QAContact: w3c-dist-auth@w3.org Issue: the interactions of creationdate with Bind operations is not specified. Date raised: March 17 2004 on list, revived Jan 28 2005 Proposed Text: "The live property 'DAV:creationdate' refers to the date of creation of the resource. Thus, use of the BIND, REBIND or UNBIND methods SHOULD NOT affect the value of this property for a resource which already existed and continues to exist." ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Thu Feb 3 12:57:28 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20539 for ; Thu, 3 Feb 2005 12:57:28 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CwlDm-0003cU-Rh for w3c-dist-auth-dist@listhub.w3.org; Thu, 03 Feb 2005 17:56:50 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CwlDm-0003c0-LL for w3c-dist-auth@listhub.w3.org; Thu, 03 Feb 2005 17:56:50 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CwlDb-000226-Rs for w3c-dist-auth@w3.org; Thu, 03 Feb 2005 17:56:40 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j13HuoV0017362; Thu, 3 Feb 2005 09:56:50 -0800 Date: Thu, 3 Feb 2005 09:56:50 -0800 Message-Id: <200502031756.j13HuoV0017362@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 77] New: Do Bind operations change the getlastmodified or getetag property values X-Archived-At: http://www.w3.org/mid/200502031756.j13HuoV0017362@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9397 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 03 Feb 2005 17:56:50 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=77 Summary: Do Bind operations change the getlastmodified or getetag property values Product: WebDAV-BIND Version: -latest Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 04. BIND Method AssignedTo: julian.reschke@greenbytes.de ReportedBy: lisa@osafoundation.org QAContact: w3c-dist-auth@w3.org Issue: The affect of Bind operations on the getlastmodified and getetag property values (and the value of the ETag) are not specified. Date raised: first raised March 17 2004 Proposed Text: "The getlastmodified and getetag properties refer to the state of the resource, not the URLs used to access that resource. Since the BIND, REBIND and UNBIND methods do not change the state of the resource but only the bindings to it, the server MUST NOT change the values of these properties when these methods are used." ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Thu Feb 3 13:09:31 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22048 for ; Thu, 3 Feb 2005 13:09:31 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CwlPK-0007j2-M9 for w3c-dist-auth-dist@listhub.w3.org; Thu, 03 Feb 2005 18:08:46 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CwlPK-0007iT-Fk for w3c-dist-auth@listhub.w3.org; Thu, 03 Feb 2005 18:08:46 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CwlPK-0005rX-6l for w3c-dist-auth@w3.org; Thu, 03 Feb 2005 18:08:46 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j13I8iEw017402; Thu, 3 Feb 2005 10:08:44 -0800 Date: Thu, 3 Feb 2005 10:08:44 -0800 Message-Id: <200502031808.j13I8iEw017402@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 78] New: Value of ETag and getlastmodified properties on multiple bindings X-Archived-At: http://www.w3.org/mid/200502031808.j13I8iEw017402@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9398 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 03 Feb 2005 18:08:46 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=78 Summary: Value of ETag and getlastmodified properties on multiple bindings Product: WebDAV-BIND Version: -latest Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 03. Properties AssignedTo: julian.reschke@greenbytes.de ReportedBy: lisa@osafoundation.org QAContact: w3c-dist-auth@w3.org Issue: The Bind specification is currently silent on how consistent live properties, including ETag, must be across bindings. This has been discussed somewhat on the list but no agreed-upon language added yet. The behavior of servers here affects greatly how bindings-aware clients might implement synchronization. It's very similar to the interoperability problems that have plagued the WebDAV community over whether the last-modified date and etag should change when the properties of a resource are changed with PROPFIND so we should avoid a similar ambiguity in the case of bindings. Proposed Text: "The ETag and Last-Modified date values refer to the state of the resource, not the state of any or all bindings. Thus, the ETag, the Last-Modified date and the value of the 'DAV:getetag' and 'DAV:getlastmodified' properties MUST NOT vary according to which binding is used to access the resource." Some discussion on the list recently included the notion that since some servers use the URL as part of the ETag, this requirement cannot be made. I don't agree with that personally because implementing the Bind specification requires far more changes than simply how ETags might be generated. Certainly there are successful implementations which use another method to generate ETags which does not suffer from variance according to URL, and those methods can be emulated. However, should the WG conclude that this requirement cannot be made or met, then the Bind specification still needs to include text specifying that the value of the ETag MAY vary across bindings, and whether the value of last-modified MUST be the same. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Thu Feb 3 13:09:33 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22068 for ; Thu, 3 Feb 2005 13:09:33 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CwlPb-0007r5-41 for w3c-dist-auth-dist@listhub.w3.org; Thu, 03 Feb 2005 18:09:03 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CwlPa-0007qF-Ri for w3c-dist-auth@listhub.w3.org; Thu, 03 Feb 2005 18:09:02 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CwlPQ-0003mn-2A for w3c-dist-auth@w3.org; Thu, 03 Feb 2005 18:08:52 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j13I91fj017414; Thu, 3 Feb 2005 10:09:01 -0800 Date: Thu, 3 Feb 2005 10:09:01 -0800 Message-Id: <200502031809.j13I91fj017414@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 77] Do Bind operations change the getlastmodified or getetag property values X-Archived-At: http://www.w3.org/mid/200502031809.j13I91fj017414@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9399 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 03 Feb 2005 18:09:03 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=77 ------- Additional Comments From julian.reschke@greenbytes.de 2005-02-03 10:09 ------- REBIND is like MOVE, and MOVE doesn't have this restriction in RFC2518. So it would be incorrect to add this as a new requirement. Also note that existing (compliant) servers already change the last mod date in certain cases, such as because they use it internally to generate an ETag. Adding new restrictions would make these servers non-compliant for no obvious benefit, so I would reject any proposal to change this in RFC2518bis. See also the comments made in . ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Thu Feb 3 13:12:52 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22439 for ; Thu, 3 Feb 2005 13:12:52 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CwlSn-0000s3-Fa for w3c-dist-auth-dist@listhub.w3.org; Thu, 03 Feb 2005 18:12:21 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CwlSn-0000rZ-8i for w3c-dist-auth@listhub.w3.org; Thu, 03 Feb 2005 18:12:21 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by bart.w3.org with esmtp (Exim 4.34) id 1CwlSn-0006st-1A for w3c-dist-auth@w3.org; Thu, 03 Feb 2005 18:12:21 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j13ICIaa007194 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 3 Feb 2005 10:12:18 -0800 In-Reply-To: <1aef7c87a3636e35da541fba00215c3c@jabber.com> References: <1aef7c87a3636e35da541fba00215c3c@jabber.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: webdav From: Lisa Dusseault Date: Thu, 3 Feb 2005 10:11:42 -0800 To: Joe Hildebrand X-Mailer: Apple Mail (2.619.2) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (bart.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Status of working group last call on BIND X-Archived-At: http://www.w3.org/mid/aeb37afdf60009228a940f5e7d8cbf37@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9400 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 03 Feb 2005 18:12:21 +0000 Content-Transfer-Encoding: 7bit On Feb 2, 2005, at 11:05 PM, Joe Hildebrand wrote: > > > If there are any outstanding issues that, for whatever reason, didn't > make it into Bugzilla, please enter them ASAP. I've seen a couple go > by on the list that I don't see in the system. > > Thanks for the reminder, I've done that now. Lisa From w3c-dist-auth-request@w3.org Thu Feb 3 13:13:28 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22487 for ; Thu, 3 Feb 2005 13:13:28 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CwlTN-00013G-Fj for w3c-dist-auth-dist@listhub.w3.org; Thu, 03 Feb 2005 18:12:57 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CwlTN-00012m-8M for w3c-dist-auth@listhub.w3.org; Thu, 03 Feb 2005 18:12:57 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CwlTN-00070x-01 for w3c-dist-auth@w3.org; Thu, 03 Feb 2005 18:12:57 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j13ICusm017435; Thu, 3 Feb 2005 10:12:56 -0800 Date: Thu, 3 Feb 2005 10:12:56 -0800 Message-Id: <200502031812.j13ICusm017435@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 76] What event does creationdate refer to X-Archived-At: http://www.w3.org/mid/200502031812.j13ICusm017435@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9401 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 03 Feb 2005 18:12:57 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=76 ------- Additional Comments From julian.reschke@greenbytes.de 2005-02-03 10:12 ------- It's unclear to me why any reader of RFC2518 and BIND could come to the conclusion that the definition for DAV:creationdate is affected by BIND. RFC2518 says it's the creation time of the resource, and as far as I can tell, there's no way to misinterpret this definition. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Thu Feb 3 14:21:35 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28140 for ; Thu, 3 Feb 2005 14:21:34 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CwmWh-0001FQ-Gg for w3c-dist-auth-dist@listhub.w3.org; Thu, 03 Feb 2005 19:20:27 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CwmWf-0001EO-EX for w3c-dist-auth@listhub.w3.org; Thu, 03 Feb 2005 19:20:25 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1CwmWU-0000yQ-MN for w3c-dist-auth@w3.org; Thu, 03 Feb 2005 19:20:14 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j13JKDaa015739 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 3 Feb 2005 11:20:15 -0800 In-Reply-To: <42025E6E.7020908@gmx.de> References: <42025E6E.7020908@gmx.de> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <89e48efd88babbec2a6b0279109af5c1@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: Geoffrey M Clemm , webdav From: Lisa Dusseault Date: Thu, 3 Feb 2005 11:20:07 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.619.2) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: BIND and access control lists X-Archived-At: http://www.w3.org/mid/89e48efd88babbec2a6b0279109af5c1@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9402 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 03 Feb 2005 19:20:27 +0000 Content-Transfer-Encoding: 7bit On Feb 3, 2005, at 9:25 AM, Julian Reschke wrote: > >> If nobody objects to that behavior, then I am happy to add >> that sentence to the BIND specification. > > So where should that statement go (or these statements when we include > UNBIND)? Should we insert a new top-level paragraph stating the > behaviour? > Wherever you think best! I think location and organization largely go under authors' discretion. Lisa From w3c-dist-auth-request@w3.org Thu Feb 3 14:37:32 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29612 for ; Thu, 3 Feb 2005 14:37:32 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CwmmY-0006cb-RN for w3c-dist-auth-dist@listhub.w3.org; Thu, 03 Feb 2005 19:36:50 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CwmmY-0006c6-As for w3c-dist-auth@listhub.w3.org; Thu, 03 Feb 2005 19:36:50 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1CwmmN-0003cZ-HR for w3c-dist-auth@w3.org; Thu, 03 Feb 2005 19:36:39 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j13Jaiaa017207 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 3 Feb 2005 11:36:45 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4e565dcc2d8dc53a996627c438b4cd67@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: " webdav" From: Lisa Dusseault Date: Thu, 3 Feb 2005 11:36:35 -0800 To: Geoffrey M Clemm X-Mailer: Apple Mail (2.619.2) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: BIND and access control lists X-Archived-At: http://www.w3.org/mid/4e565dcc2d8dc53a996627c438b4cd67@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9403 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 03 Feb 2005 19:36:50 +0000 Content-Transfer-Encoding: 7bit This is fine with me for BIND, and I think the same is also true of REBIND and UNBIND. Lisa On Feb 3, 2005, at 5:18 AM, Geoffrey M Clemm wrote: > The statement that would be consistent with 3744 would be > "BIND is the same as MOVE with respect to the DAV:acl property". > (I prefer to state it that way, rather than copying the > paragraphs from 3744, since that allows us to modify > DAV:acl behavior in 3744bis without having to revise the > binding specification). > > If nobody objects to that behavior, then I am happy to add > that sentence to the BIND specification. > > If anyone objects to that behavior, then that is an issue > against 3744, and then I believe the BIND specification > should remain silent on the topic, and the issue should be raised > against 3744 for resolution. > > Cheers, > Geoff > > Joe wrote on 02/03/2005 02:07:52 AM: > >> >> Trying to predict what the IESG might latch on to during their last >> call. >> >> I understand that DAV:acl is a property, which applies to the >> resource, >> not the URL. The suggestion has been made that MOVE has the same >> issue, but 3744 gives explicit requirements for MOVE and COPY, which >> differ slightly. I don't know the history of 3744, but I assume that >> there needed to be text for section 7.3 and 7.4 since it wasn't >> obvious >> what would happen to acl's in the face of those operations. >> >> I could imagine an IESG member who knew about the entire suite of >> protocols asking for the draft that added a new operation specifying >> how that operation fits into that suite. I would expect that a line >> saying "BIND is the same as MOVE with respect to acl's", "BIND is the >> same as COPY with respect to acl's", or a paragraph on the same lines >> as 7.3 or 7.4 from 3744 would be enough to answer that question. >> >> -- >> Joe Hildebrand >> >> From w3c-dist-auth-request@w3.org Thu Feb 3 17:59:48 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02971 for ; Thu, 3 Feb 2005 17:59:47 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CwpvZ-0000pF-5s for w3c-dist-auth-dist@listhub.w3.org; Thu, 03 Feb 2005 22:58:21 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CwpvX-0000oa-PF for w3c-dist-auth@listhub.w3.org; Thu, 03 Feb 2005 22:58:19 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1CwpvX-00060l-6p for w3c-dist-auth@w3.org; Thu, 03 Feb 2005 22:58:19 +0000 Received: (qmail invoked by alias); 03 Feb 2005 22:57:47 -0000 Received: from p54856447.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.100.71) by mail.gmx.net (mp003) with SMTP; 03 Feb 2005 23:57:47 +0100 X-Authenticated: #1915285 Message-ID: <4202AC61.6010400@gmx.de> Date: Thu, 03 Feb 2005 23:57:37 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: Geoffrey M Clemm , webdav References: <4e565dcc2d8dc53a996627c438b4cd67@osafoundation.org> In-Reply-To: <4e565dcc2d8dc53a996627c438b4cd67@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: BIND and access control lists X-Archived-At: http://www.w3.org/mid/4202AC61.6010400@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9404 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 03 Feb 2005 22:58:21 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > This is fine with me for BIND, and I think the same is also true of > REBIND and UNBIND. How is UNBIND relevant here? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Feb 3 18:08:27 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04021 for ; Thu, 3 Feb 2005 18:08:26 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cwq4l-0004SN-C9 for w3c-dist-auth-dist@listhub.w3.org; Thu, 03 Feb 2005 23:07:51 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cwq4k-0004R5-Er for w3c-dist-auth@listhub.w3.org; Thu, 03 Feb 2005 23:07:50 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1Cwq4k-0008HP-5F for w3c-dist-auth@w3.org; Thu, 03 Feb 2005 23:07:50 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j13N7mUN017712; Thu, 3 Feb 2005 15:07:48 -0800 Date: Thu, 3 Feb 2005 15:07:48 -0800 Message-Id: <200502032307.j13N7mUN017712@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 78] Value of ETag and getlastmodified properties on multiple bindings X-Archived-At: http://www.w3.org/mid/200502032307.j13N7mUN017712@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9405 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 03 Feb 2005 23:07:51 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=78 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Component|03. Properties |Other ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Thu Feb 3 18:39:06 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07162 for ; Thu, 3 Feb 2005 18:39:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CwqY5-0000yw-16 for w3c-dist-auth-dist@listhub.w3.org; Thu, 03 Feb 2005 23:38:09 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CwqY4-0000yS-EM for w3c-dist-auth@listhub.w3.org; Thu, 03 Feb 2005 23:38:08 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CwqXt-0001xs-Kx for w3c-dist-auth@w3.org; Thu, 03 Feb 2005 23:37:57 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j13Nc7Nq017745; Thu, 3 Feb 2005 15:38:07 -0800 Date: Thu, 3 Feb 2005 15:38:07 -0800 Message-Id: <200502032338.j13Nc7Nq017745@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 78] Value of ETag and getlastmodified properties on multiple bindings X-Archived-At: http://www.w3.org/mid/200502032338.j13Nc7Nq017745@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9406 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 03 Feb 2005 23:38:09 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=78 ------- Additional Comments From lisa@osafoundation.org 2005-02-03 15:38 ------- Sorry for the confusing wording. I meant that the value of getlastmodified should not vary according to the binding used, and also that the value of getetag may vary according to the binding used. I didn't mean to suggest that getlastmodified should be the same as getetag. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Thu Feb 3 18:48:29 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07961 for ; Thu, 3 Feb 2005 18:48:29 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CwqhT-0005PY-UM for w3c-dist-auth-dist@listhub.w3.org; Thu, 03 Feb 2005 23:47:51 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CwqhT-0005P3-Jk for w3c-dist-auth@listhub.w3.org; Thu, 03 Feb 2005 23:47:51 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CwqhI-0003lX-QG for w3c-dist-auth@w3.org; Thu, 03 Feb 2005 23:47:41 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j13Nlpbb017794; Thu, 3 Feb 2005 15:47:51 -0800 Date: Thu, 3 Feb 2005 15:47:51 -0800 Message-Id: <200502032347.j13Nlpbb017794@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 78] Value of ETag and getlastmodified properties on multiple bindings X-Archived-At: http://www.w3.org/mid/200502032347.j13Nlpbb017794@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9407 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 03 Feb 2005 23:47:51 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=78 ------- Additional Comments From julian.reschke@greenbytes.de 2005-02-03 15:47 ------- Looking at RFC2616's definition of both headers, I don't see any indication why they would behave differently. So, independantly of whether we want to say anything, this particular proposal seems to be technically incorrect. My interpretation of the discussion we had on the mailing list is that the only thing that can reliably be said is that DAV properties that are defined in terms of RFC2616 response headers MUST behave the way they are defined as per RFC2616, which - at the end of the day - isn't really interesting at all (thus, I believe, we shouldn't say anything at all). ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Thu Feb 3 18:51:06 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08494 for ; Thu, 3 Feb 2005 18:51:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cwqk0-0006uW-I1 for w3c-dist-auth-dist@listhub.w3.org; Thu, 03 Feb 2005 23:50:28 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Cwq7r-0005OZ-1s for w3c-dist-auth@listhub.w3.org; Thu, 03 Feb 2005 23:11:03 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CwptI-00034r-BB for w3c-dist-auth@w3.org; Thu, 03 Feb 2005 22:56:00 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j13MuAOP017659; Thu, 3 Feb 2005 14:56:10 -0800 Date: Thu, 3 Feb 2005 14:56:10 -0800 Message-Id: <200502032256.j13MuAOP017659@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 78] Value of ETag and getlastmodified properties on multiple bindings X-Archived-At: http://www.w3.org/mid/200502032256.j13MuAOP017659@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9408 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 03 Feb 2005 23:50:28 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=78 ------- Additional Comments From julian.reschke@greenbytes.de 2005-02-03 14:56 ------- 1) Whether the spec needs to say something or not is up to the WG to decide. 2) What do you mean by "...whether the value of last-modified MUST be the same"? By their syntax definition, no legal value for DAV:getlastmodified is a valid DAV:getetag, and vice versa. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Thu Feb 3 19:10:25 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09963 for ; Thu, 3 Feb 2005 19:10:25 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cwr22-0002mu-Vm for w3c-dist-auth-dist@listhub.w3.org; Fri, 04 Feb 2005 00:09:06 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Cwr22-0002mQ-Is for w3c-dist-auth@listhub.w3.org; Fri, 04 Feb 2005 00:09:06 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1Cwr1r-0006hc-QF for w3c-dist-auth@w3.org; Fri, 04 Feb 2005 00:08:55 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1408laa009302 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 3 Feb 2005 16:08:49 -0800 In-Reply-To: <4202AC61.6010400@gmx.de> References: <4e565dcc2d8dc53a996627c438b4cd67@osafoundation.org> <4202AC61.6010400@gmx.de> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8feaf014125a657b53d94c713c8c95da@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: Geoffrey M Clemm , webdav From: Lisa Dusseault Date: Thu, 3 Feb 2005 16:08:41 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.619.2) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: BIND and access control lists X-Archived-At: http://www.w3.org/mid/8feaf014125a657b53d94c713c8c95da@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9409 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 04 Feb 2005 00:09:06 +0000 Content-Transfer-Encoding: 7bit Let's say the user creates resource 'myresume.doc' and puts it into a collection 'http://example.org/~lisa/public/'. Further, let's say that the public nature of this collection involves inherited permissions which make the new document publicly readable. In step 2, the user does a BIND to also bind 'myresume.doc' into 'http://example.org/~lisa/career/'. This new location is a private folder, but let's assume that 'myresume.doc' remains publicly readable because of its membership in the public folder. (This is where the BIND language would come in but this behavior seems consistent with that.) In step 3, when the user does UNBIND and removes the binding into the public collection, does the document remain public? That's the question for which I'm looking for additional specification requirements. Lisa On Feb 3, 2005, at 2:57 PM, Julian Reschke wrote: > Lisa Dusseault wrote: >> This is fine with me for BIND, and I think the same is also true of >> REBIND and UNBIND. > > How is UNBIND relevant here? > > Best regards, Julian > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Feb 3 19:12:30 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10078 for ; Thu, 3 Feb 2005 19:12:30 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cwr4n-0004zb-G3 for w3c-dist-auth-dist@listhub.w3.org; Fri, 04 Feb 2005 00:11:57 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cwr4m-0004yz-K9 for w3c-dist-auth@listhub.w3.org; Fri, 04 Feb 2005 00:11:56 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1Cwr4m-000385-Bb for w3c-dist-auth@w3.org; Fri, 04 Feb 2005 00:11:56 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j140BtqL017832; Thu, 3 Feb 2005 16:11:55 -0800 Date: Thu, 3 Feb 2005 16:11:55 -0800 Message-Id: <200502040011.j140BtqL017832@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 78] Value of ETag and getlastmodified properties on multiple bindings X-Archived-At: http://www.w3.org/mid/200502040011.j140BtqL017832@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9410 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 04 Feb 2005 00:11:57 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=78 ------- Additional Comments From lisa@osafoundation.org 2005-02-03 16:11 ------- I don't agree that nothing further can be said. When defining new features, we can and should define how RFC2616 features work together with the new features. The independence of these features is not perfect although it doesn't require much to specify the interactions. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Thu Feb 3 21:04:30 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18199 for ; Thu, 3 Feb 2005 21:04:29 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CwsnU-0007up-Jt for w3c-dist-auth-dist@listhub.w3.org; Fri, 04 Feb 2005 02:02:12 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CwsnT-0007uL-Jl for w3c-dist-auth@listhub.w3.org; Fri, 04 Feb 2005 02:02:11 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CwsnI-0001g3-QL for w3c-dist-auth@w3.org; Fri, 04 Feb 2005 02:02:01 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j14228Rn017908; Thu, 3 Feb 2005 18:02:08 -0800 Date: Thu, 3 Feb 2005 18:02:08 -0800 Message-Id: <200502040202.j14228Rn017908@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 78] Value of ETag and getlastmodified properties on multiple bindings X-Archived-At: http://www.w3.org/mid/200502040202.j14228Rn017908@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9411 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 04 Feb 2005 02:02:12 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=78 ------- Additional Comments From geoffrey.clemm@us.ibm.com 2005-02-03 18:02 ------- I agree with Julian that adding text which states that the definition of DAV:getetag and DAV:getlastmodified is not affected by this specification would not solve any interoperability problems. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Fri Feb 4 15:27:09 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01642 for ; Fri, 4 Feb 2005 15:27:09 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CxA0F-0001Tl-KU for w3c-dist-auth-dist@listhub.w3.org; Fri, 04 Feb 2005 20:24:31 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CxA0E-0001TC-2n for w3c-dist-auth@listhub.w3.org; Fri, 04 Feb 2005 20:24:30 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1CxA0D-0002Kz-O1 for w3c-dist-auth@w3.org; Fri, 04 Feb 2005 20:24:30 +0000 Received: (qmail invoked by alias); 04 Feb 2005 20:23:56 -0000 Received: from mnsr-d9b9cd6c.pool.mediaWays.net (EHLO [217.185.205.108]) (217.185.205.108) by mail.gmx.net (mp025) with SMTP; 04 Feb 2005 21:23:56 +0100 X-Authenticated: #1915285 Message-ID: <4203D9D9.6060209@gmx.de> Date: Fri, 04 Feb 2005 21:23:53 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geoffrey M Clemm CC: webdav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: BIND and access control lists X-Archived-At: http://www.w3.org/mid/4203D9D9.6060209@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9412 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 04 Feb 2005 20:24:31 +0000 Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > > The statement that would be consistent with 3744 would be > "BIND is the same as MOVE with respect to the DAV:acl property". > (I prefer to state it that way, rather than copying the > paragraphs from 3744, since that allows us to modify > DAV:acl behavior in 3744bis without having to revise the > binding specification). > > If nobody objects to that behavior, then I am happy to add > that sentence to the BIND specification. > > If anyone objects to that behavior, then that is an issue > against 3744, and then I believe the BIND specification > should remain silent on the topic, and the issue should be raised > against 3744 for resolution. > > Cheers, > Geoff OK, issue tracked at: Potential resolution: new paragraph: 9. Relationship to WebDAV Access Control Protocol BIND and REBIND behave the same as MOVE with respect to the DAV:acl property (see [RFC3744], section 7.3). Feedback appreciated, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Feb 4 15:28:44 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01806 for ; Fri, 4 Feb 2005 15:28:44 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CxA3o-0002Mp-Gw for w3c-dist-auth-dist@listhub.w3.org; Fri, 04 Feb 2005 20:28:12 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CxA3o-0002ML-0a for w3c-dist-auth@listhub.w3.org; Fri, 04 Feb 2005 20:28:12 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CxA3d-0001od-2x for w3c-dist-auth@w3.org; Fri, 04 Feb 2005 20:28:01 +0000 Received: (qmail invoked by alias); 04 Feb 2005 20:27:37 -0000 Received: from mnsr-d9b9cd50.pool.mediaWays.net (EHLO [217.185.205.80]) (217.185.205.80) by mail.gmx.net (mp012) with SMTP; 04 Feb 2005 21:27:37 +0100 X-Authenticated: #1915285 Message-ID: <4203DAB0.9010009@gmx.de> Date: Fri, 04 Feb 2005 21:27:28 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: Geoffrey M Clemm , webdav References: <4e565dcc2d8dc53a996627c438b4cd67@osafoundation.org> <4202AC61.6010400@gmx.de> <8feaf014125a657b53d94c713c8c95da@osafoundation.org> In-Reply-To: <8feaf014125a657b53d94c713c8c95da@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: BIND and access control lists X-Archived-At: http://www.w3.org/mid/4203DAB0.9010009@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9413 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 04 Feb 2005 20:28:12 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > Let's say the user creates resource 'myresume.doc' and puts it into a > collection 'http://example.org/~lisa/public/'. Further, let's say that > the public nature of this collection involves inherited permissions > which make the new document publicly readable. > > In step 2, the user does a BIND to also bind 'myresume.doc' into > 'http://example.org/~lisa/career/'. This new location is a private > folder, but let's assume that 'myresume.doc' remains publicly readable > because of its membership in the public folder. (This is where the BIND > language would come in but this behavior seems consistent with that.) > > In step 3, when the user does UNBIND and removes the binding into the > public collection, does the document remain public? That's the question > for which I'm looking for additional specification requirements. I guess all we can say is that we don't know, just like for MOVE, BIND and REBIND. But if this is the case for UNBIND, it also applies to DELETE. So should we state that? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Feb 4 18:19:01 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18555 for ; Fri, 4 Feb 2005 18:19:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CxChl-0005fs-LC for w3c-dist-auth-dist@listhub.w3.org; Fri, 04 Feb 2005 23:17:37 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CxChk-0005f8-Bx for w3c-dist-auth@listhub.w3.org; Fri, 04 Feb 2005 23:17:36 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CxChZ-0005KX-EP for w3c-dist-auth@w3.org; Fri, 04 Feb 2005 23:17:25 +0000 Received: (qmail invoked by alias); 04 Feb 2005 23:17:02 -0000 Received: from pD95353EA.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.83.234) by mail.gmx.net (mp011) with SMTP; 05 Feb 2005 00:17:02 +0100 X-Authenticated: #1915285 Message-ID: <4204026B.1070104@gmx.de> Date: Sat, 05 Feb 2005 00:16:59 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Hildebrand CC: webdav References: <1aef7c87a3636e35da541fba00215c3c@jabber.com> In-Reply-To: <1aef7c87a3636e35da541fba00215c3c@jabber.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Status of working group last call on BIND X-Archived-At: http://www.w3.org/mid/4204026B.1070104@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9414 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 04 Feb 2005 23:17:37 +0000 Content-Transfer-Encoding: 7bit Joe Hildebrand wrote: > > Please send a note to the list if you reviewed BIND for the last call. > I'd like to make sure we had enough eyes on it. > > If there are any outstanding issues that, for whatever reason, didn't > make it into Bugzilla, please enter them ASAP. I've seen a couple go by > on the list that I don't see in the system. > > Here is a list of the issues I see on bugzilla. > > --- > http://ietf.webdav.org:8080/bugzilla/show_bug.cgi?id=2 > "Bindings needs to completely describe how bindings interact with > locks." > > I see consensus for the clarification text proposed and wordsmithed here > on the list. > > --- > http://ietf.webdav.org:8080/bugzilla/show_bug.cgi?id=5 > "Bindings and DeltaV aren't fully interspecified" > > Of the text I've seen for this, that says that the interaction is > unspecified, I don't see enough consensus on that suggestion to hold > things up. > > --- > http://ietf.webdav.org:8080/bugzilla/show_bug.cgi?id=71 > "Clarify what servers may and may not do with privileges when BIND is > used" > > I don't see consensus for making a change. However, I want to make sure > I understand the issue before I predict how the IESG will react to this > during their last call. I'll post a message to the list with some > thoughts. Thanks Joe, from my p.o.v.: #2) Should be closed: consensus for the change made with #5) Should be closed: has 0 votes on it #71) Should be closed: has only 1 vote on it from Elias, and he's satisfied with the explanations and changes made (). #71b) The question raised by you, Joe, in is IMHO a distinct issue, it's being tracked with , you may want to open a new BugZilla issue if you feel that there's a risk that we're not following up properly. Regarding the three issues raised post-last-call: please give guidance on how to proceed. So far, there aren't any votes on them, and it doesn't seem any new feedback is coming in. I think we still should plan to submit a document for publication in time before the IETF, which is roughly two weeks from now. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sun Feb 6 10:37:22 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01237 for ; Sun, 6 Feb 2005 10:37:22 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CxoR4-0007kv-Nb for w3c-dist-auth-dist@listhub.w3.org; Sun, 06 Feb 2005 15:34:54 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CxoR3-0007kI-L2 for w3c-dist-auth@listhub.w3.org; Sun, 06 Feb 2005 15:34:53 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CxoR3-0004qb-AJ for w3c-dist-auth@w3.org; Sun, 06 Feb 2005 15:34:53 +0000 Received: (qmail invoked by alias); 06 Feb 2005 15:34:18 -0000 Received: from pD9FF0486.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.4.134) by mail.gmx.net (mp009) with SMTP; 06 Feb 2005 16:34:18 +0100 X-Authenticated: #1915285 Message-ID: <420638E2.90003@gmx.de> Date: Sun, 06 Feb 2005 16:33:54 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bugzilla@soe.ucsc.edu CC: w3c-dist-auth@w3.org References: <200501301552.j0UFqncl009712@ietf.cse.ucsc.edu> In-Reply-To: <200501301552.j0UFqncl009712@ietf.cse.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 74] New: Remove UUID generation instructions X-Archived-At: http://www.w3.org/mid/420638E2.90003@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9415 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sun, 06 Feb 2005 15:34:54 +0000 Content-Transfer-Encoding: 7bit OK, for "draft-reschke-webdav-locking", I'm tracking this as and rewrote the section like this: Appendix D. 'opaquelocktoken' URI Scheme The opaquelocktoken URI scheme is designed to be unique across all resources for all time. Due to this uniqueness quality, a client may submit an opaque lock token in an If header on a resource other than the one that returned it. All resources MUST recognize the opaquelocktoken scheme and, at minimum, recognize that the lock token does not refer to an outstanding lock on the resource. In order to guarantee uniqueness across all resources for all time the opaquelocktoken requires the use of the Universal Unique Identifier (UUID) mechanism, as described in Section 4 of [draft-mealling-uuid-urn]. OpaqueLockToken-URI = "opaquelocktoken:" UUID [path] ; UUID: see [draft-mealling-uuid-urn], Section 3. ; path: see [RFC3986], Section 3.3. This change gets rid of 2 pages of spec text that this WG can't do as good as the URN UUID authors anyway; and also replaces an ISO spec reference with a reference to an IETF standards track document. I propose the same resolution in RFC2518bis. Feedback appreciated, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sun Feb 6 10:40:02 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01576 for ; Sun, 6 Feb 2005 10:40:02 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CxoVT-0008VG-Bp for w3c-dist-auth-dist@listhub.w3.org; Sun, 06 Feb 2005 15:39:27 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CxoVT-0008UT-57 for w3c-dist-auth@listhub.w3.org; Sun, 06 Feb 2005 15:39:27 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CxoVS-0005j4-TI for w3c-dist-auth@w3.org; Sun, 06 Feb 2005 15:39:27 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j16FdP7b000443; Sun, 6 Feb 2005 07:39:25 -0800 Date: Sun, 6 Feb 2005 07:39:25 -0800 Message-Id: <200502061539.j16FdP7b000443@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 74] Remove UUID generation instructions X-Archived-At: http://www.w3.org/mid/200502061539.j16FdP7b000443@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9416 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sun, 06 Feb 2005 15:39:27 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=74 ------- Additional Comments From julian.reschke@greenbytes.de 2005-02-06 07:39 ------- Suggested replacement text: Appendix D. 'opaquelocktoken' URI Scheme The opaquelocktoken URI scheme is designed to be unique across all resources for all time. Due to this uniqueness quality, a client may submit an opaque lock token in an If header on a resource other than the one that returned it. All resources MUST recognize the opaquelocktoken scheme and, at minimum, recognize that the lock token does not refer to an outstanding lock on the resource. In order to guarantee uniqueness across all resources for all time the opaquelocktoken requires the use of the Universal Unique Identifier (UUID) mechanism, as described in Section 4 of [draft-mealling-uuid-urn]. OpaqueLockToken-URI = "opaquelocktoken:" UUID [path] ; UUID: see [draft-mealling-uuid-urn], Section 3. ; path: see [RFC3986], Section 3.3. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Mon Feb 7 18:39:20 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16431 for ; Mon, 7 Feb 2005 18:39:20 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CyIRX-00041g-NY for w3c-dist-auth-dist@listhub.w3.org; Mon, 07 Feb 2005 23:37:23 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CyIRW-00041C-J4 for w3c-dist-auth@listhub.w3.org; Mon, 07 Feb 2005 23:37:22 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by lisa.w3.org with esmtp (Exim 4.34) id 1CyIRW-0006iD-BG for w3c-dist-auth@w3.org; Mon, 07 Feb 2005 23:37:22 +0000 Received: from [192.168.1.151] ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 7 Feb 2005 15:36:50 -0800 In-Reply-To: <41F3953C.9060702@gmx.de> References: <95C2A37A-6B2A-11D9-A835-000A95AACED2@xythos.com> <41F3953C.9060702@gmx.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <23C5C89A-7961-11D9-84E6-000A95AACED2@xythos.com> Content-Transfer-Encoding: 7bit Cc: WebDAV WG From: Brian Korver Date: Mon, 7 Feb 2005 15:36:50 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 07 Feb 2005 23:36:50.0340 (UTC) FILETIME=[E587B640:01C50D6D] Received-SPF: none (lisa.w3.org: domain of briank@xythos.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on draft-ietf-webdav-quota-05.txt, Was: Fwd: I-D ACTION:draft-ietf-webdav-quota-05.txt X-Archived-At: http://www.w3.org/mid/23C5C89A-7961-11D9-84E6-000A95AACED2@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9417 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 07 Feb 2005 23:37:23 +0000 Content-Transfer-Encoding: 7bit Julian, Comments in-line... On Jan 23, 2005, at 4:14 AM, Julian Reschke wrote: > Hi, > > below is my updated issues list. In general, this draft is a real > improvement, and besides mainly editorial questions, the main issue > the working group should consider is whether the Quota spec should > handle disk limits (right now it does implicitly). I personally would > prefer if it either wouldn't do it at all, or do it explicitly > (through at least a different set of precondition names). > > Best regards, Julian > > - snip - > > Issues with draft-ietf-webdav-quota-05.txt > > Content > > 01-C03 quota vs disk space > 0439.html> > 0460.html> > 0184.html> > 0193.html> > > The spec says that servers may expose physical disk limits as quota. > > a) This is incompatible with NFS from which we're borrowing the > semantics (it treats disk limits as a separate property, and so should > we) > > Update -04: this still appears in the text, but is less critical now > that authorability of the quota is gone. I'd still like to see the > working group make an explicit decision to keep this, because it's > IMHO clearly outside the scope of this spec (I'd prefer separate > properties). > > > 04-C06, section 3, DAV:quota-available-bytes > > "The DAV:quota-available-bytes property value is the value in octets > representing the amount of additional disk space beyond the current > allocation that can be allocated to this file or directory before > further allocations will be refused. It is understood that this > space may be consumed by allocations to other files or directories." > > Replace "file or directory" by "resource". Note that neither "file" or > "directory" exist in WebDAV terminology. (same in section 4) fixed in -05 > > > 04-C07, section 3, DAV:quota-available-bytes > > -05.html#rfc.section.3> > > "Support for this property is REQUIRED on collections, and OPTIONAL > on > other resources. A server SHOULD implement this property for each > resource that has the DAV:quota-used-bytes property." > > What's the motivation for the distinction? (same in section 4) > > Update -05: this is actually in contradiction to Section 3 which says: > " Implementing both DAV:quota-available-bytes and DAV:quota-used-bytes > on all resources is RECOMMENDED." (note OPTIONAL != RECOMMENDED). In > general, I think it would be wiser to have these requirements in a > single place (so the spec can't contradict itself), whatever they are. Good catch. Fixed in -06. > > > 04-C11, section 7 > > "The total size of a collection, DAV:quota-used-bytes, is not > necessarily a sum of the DAV:getcontentlength properties for > resources stored in the collection." > > Actually, it won't be in most cases I'm aware of. Please either > rephrase it (so this doesn't sound like an edge case) or drop the > point. Fixed in -05 > > > 05-C01, Section 4, last para > > -05.html#rfc.section.4.p.5> > > "Support for this property enhances the client experience, because > together with DAV:quota-available-bytes, the client has a chance of > managing its files to avoid running out of allocated storage space. > Clients may not be able to calculate the value as accurately on their > own, depending on how total space used is calculated by the server." > > I think this is fluff; if you want say something like that, move it > into the Introduction (where the motivation for the whole spec is > explained). Sure, fixed in -06 > > > 05-C02, Section 4 > > -05.html#rfc.section.4> > > I think this property is "computed" (as defined in RFC3253), and the > spec should say so. > > > > > 05-E01, section 1.2 > > -05.html#rfc.section.1.2> > > I'd move those parts that "import" terminology from RFC2518/3253 into > a separate subsection ("Terminology"), and also refer to the def of > "computed" property (I think we need that later). > > > 05-E02, section 1.2 > > -05.html#rfc.section.1.2> > > "In order to work best with repositories that support quotas, client > software should be able to determine and display the > DAV:quota-available-bytes on collections." > > That is a forward reference. Either add "(defined below in ...)", or > rewrite as: > > "In order to work best with repositories that support quotas, client > software should be able to determine and display the new live > properties defined below." fixed in -06 > > > 05-E02, section 5 > > -05.html#rfc.section.5> > > The artwork in the request is too wide for RFC publication and should > be re-indented (the response isn't too wide but should be re-indented > for consistency nevertheless). > Fixed in -06. If it's still not to your liking, let me know how and I'll change it. > > 05-E03, section 7 > > -05.html#rfc.section.7> > > In the list, please make punctuation consistent. Fixed in -06. > > > > > > -brian briank@xythos.com From w3c-dist-auth-request@w3.org Mon Feb 7 18:41:09 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16545 for ; Mon, 7 Feb 2005 18:41:09 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CyIUe-0005Ib-BX for w3c-dist-auth-dist@listhub.w3.org; Mon, 07 Feb 2005 23:40:36 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CyIUe-0005I2-3B for w3c-dist-auth@listhub.w3.org; Mon, 07 Feb 2005 23:40:36 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by bart.w3.org with esmtp (Exim 4.34) id 1CyIUd-0008Mt-UJ for w3c-dist-auth@w3.org; Mon, 07 Feb 2005 23:40:36 +0000 Received: from [192.168.1.151] ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 7 Feb 2005 15:40:01 -0800 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <41F3953C.9060702@gmx.de> References: <95C2A37A-6B2A-11D9-A835-000A95AACED2@xythos.com> <41F3953C.9060702@gmx.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <96006C58-7961-11D9-84E6-000A95AACED2@xythos.com> Content-Transfer-Encoding: 7bit From: Brian Korver Date: Mon, 7 Feb 2005 15:40:01 -0800 To: WebDAV WG X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 07 Feb 2005 23:40:01.0950 (UTC) FILETIME=[57BD13E0:01C50D6E] Received-SPF: none (bart.w3.org: domain of briank@xythos.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on draft-ietf-webdav-quota-05.txt, Was: Fwd: I-D ACTION:draft-ietf-webdav-quota-05.txt X-Archived-At: http://www.w3.org/mid/96006C58-7961-11D9-84E6-000A95AACED2@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9418 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 07 Feb 2005 23:40:36 +0000 Content-Transfer-Encoding: 7bit On Jan 23, 2005, at 4:14 AM, Julian Reschke wrote: [...] > 05-E01, section 1.2 > > -05.html#rfc.section.1.2> > > I'd move those parts that "import" terminology from RFC2518/3253 into > a separate subsection ("Terminology"), and also refer to the def of > "computed" property (I think we need that later). [...] This document doesn't use the notion of "computed" properties. Should it be importing the concept of "computed properties" from DeltaV? Julian says yes, but what about the rest of the group? -brian briank@xythos.com From w3c-dist-auth-request@w3.org Tue Feb 8 03:32:02 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15269 for ; Tue, 8 Feb 2005 03:32:02 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CyQlK-0007u5-5h for w3c-dist-auth-dist@listhub.w3.org; Tue, 08 Feb 2005 08:30:22 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CyQlI-0007tT-Rf for w3c-dist-auth@listhub.w3.org; Tue, 08 Feb 2005 08:30:20 +0000 Received: from [217.5.201.10] (helo=greenbytes.de) by bart.w3.org with esmtp (Exim 4.34) id 1CyQlI-0008LL-GR for w3c-dist-auth@w3.org; Tue, 08 Feb 2005 08:30:20 +0000 Received: from [192.168.1.26] by greenbytes.de (Cipher TLSv1:RC4-MD5:128) (MDaemon.PRO.v7.2.3.R) with ESMTP id md50000081538.msg for ; Tue, 08 Feb 2005 09:29:22 +0100 In-Reply-To: <96006C58-7961-11D9-84E6-000A95AACED2@xythos.com> References: <95C2A37A-6B2A-11D9-A835-000A95AACED2@xythos.com> <41F3953C.9060702@gmx.de> <96006C58-7961-11D9-84E6-000A95AACED2@xythos.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: WebDAV WG From: Stefan Eissing Date: Tue, 8 Feb 2005 09:29:20 +0100 To: Brian Korver X-Mailer: Apple Mail (2.619.2) X-Authenticated-Sender: se@greenbytes.de X-Spam-Processed: greenbytes.de, Tue, 08 Feb 2005 09:29:22 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.1.26 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Received-SPF: none (bart.w3.org: domain of stefan.eissing@greenbytes.de does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on draft-ietf-webdav-quota-05.txt, Was: Fwd: I-D ACTION:draft-ietf-webdav-quota-05.txt X-Archived-At: http://www.w3.org/mid/bd071bc406df9a86974bb79da9229d96@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9419 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 08 Feb 2005 08:30:22 +0000 Content-Transfer-Encoding: 7bit Am 08.02.2005 um 00:40 schrieb Brian Korver: > > On Jan 23, 2005, at 4:14 AM, Julian Reschke wrote: > [...] >> 05-E01, section 1.2 >> >> > -05.html#rfc.section.1.2> >> >> I'd move those parts that "import" terminology from RFC2518/3253 into >> a separate subsection ("Terminology"), and also refer to the def of >> "computed" property (I think we need that later). > [...] > > This document doesn't use the notion of "computed" properties. > Should it be importing the concept of "computed properties" from > DeltaV? Julian says yes, but what about the rest of the group? +1, i think its good terminology and can be applied here as well. From w3c-dist-auth-request@w3.org Wed Feb 9 15:35:10 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10905 for ; Wed, 9 Feb 2005 15:35:09 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CyyW8-0005PY-GH for w3c-dist-auth-dist@listhub.w3.org; Wed, 09 Feb 2005 20:32:56 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CyyW7-0005P4-8D for w3c-dist-auth@listhub.w3.org; Wed, 09 Feb 2005 20:32:55 +0000 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by lisa.w3.org with esmtp (Exim 4.34) id 1CyyW6-0002lU-Vk for w3c-dist-auth@w3.org; Wed, 09 Feb 2005 20:32:55 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10713; Wed, 9 Feb 2005 15:32:51 -0500 (EST) Message-Id: <200502092032.PAA10713@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Date: Wed, 09 Feb 2005 15:32:51 -0500 Received-SPF: none (lisa.w3.org: domain of dinaras@cnri.reston.va.us does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: I-D ACTION:draft-ietf-webdav-quota-06.txt X-Archived-At: http://www.w3.org/mid/200502092032.PAA10713@ietf.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9420 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 09 Feb 2005 20:32:56 +0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. Title : Quota and Size Properties for DAV Collections Author(s) : B. Korver, et al. Filename : draft-ietf-webdav-quota-06.txt Pages : 10 Date : 2005-2-9 WebDAV servers are frequently deployed with quota (size) limitations. This document discusses the properties and minor behaviors needed for clients to interoperate with quota (size) implementations on WebDAV repositories. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-quota-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-webdav-quota-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-webdav-quota-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-9150459.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-quota-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-quota-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-9150459.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Thu Feb 10 15:34:07 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04761 for ; Thu, 10 Feb 2005 15:34:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CzKyE-00079M-Tn for w3c-dist-auth-dist@listhub.w3.org; Thu, 10 Feb 2005 20:31:26 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CzKyD-00078n-LN for w3c-dist-auth@listhub.w3.org; Thu, 10 Feb 2005 20:31:25 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CzKyD-00069m-8Y for w3c-dist-auth@w3.org; Thu, 10 Feb 2005 20:31:25 +0000 Received: (qmail invoked by alias); 10 Feb 2005 20:30:52 -0000 Received: from pD9E51897.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.24.151) by mail.gmx.net (mp011) with SMTP; 10 Feb 2005 21:30:52 +0100 X-Authenticated: #1915285 Message-ID: <420BC477.5060207@gmx.de> Date: Thu, 10 Feb 2005 21:30:47 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Korver CC: WebDAV WG References: <95C2A37A-6B2A-11D9-A835-000A95AACED2@xythos.com> <41F3953C.9060702@gmx.de> <23C5C89A-7961-11D9-84E6-000A95AACED2@xythos.com> In-Reply-To: <23C5C89A-7961-11D9-84E6-000A95AACED2@xythos.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on draft-ietf-webdav-quota-05.txt, Was: Fwd: I-D ACTION:draft-ietf-webdav-quota-05.txt X-Archived-At: http://www.w3.org/mid/420BC477.5060207@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9421 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 10 Feb 2005 20:31:26 +0000 Content-Transfer-Encoding: 7bit Brian Korver wrote: > ... >> 04-C11, section 7 >> >> "The total size of a collection, DAV:quota-used-bytes, is not >> necessarily a sum of the DAV:getcontentlength properties for >> resources stored in the collection." >> >> Actually, it won't be in most cases I'm aware of. Please either >> rephrase it (so this doesn't sound like an edge case) or drop the point. > > > Fixed in -05 It's now saying "The total size of a collection, DAV:quota-used-bytes, may not be a sum of the DAV:getcontentlength properties for resources stored in the collection." ...which isn't that different... > ... >> 05-E02, section 5 >> >> > -05.html#rfc.section.5> >> >> The artwork in the request is too wide for RFC publication and should >> be re-indented (the response isn't too wide but should be re-indented >> for consistency nevertheless). >> > > Fixed in -06. If it's still not to your liking, let me know how > and I'll change it. Seems to be fine now. > ... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Feb 10 15:54:20 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06479 for ; Thu, 10 Feb 2005 15:54:20 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CzLJQ-0006oM-KL for w3c-dist-auth-dist@listhub.w3.org; Thu, 10 Feb 2005 20:53:20 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CzLJQ-0006ns-90 for w3c-dist-auth@listhub.w3.org; Thu, 10 Feb 2005 20:53:20 +0000 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by bart.w3.org with esmtp (Exim 4.34) id 1CzLJQ-0002Ob-0l for w3c-dist-auth@w3.org; Thu, 10 Feb 2005 20:53:20 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06371; Thu, 10 Feb 2005 15:53:14 -0500 (EST) Message-Id: <200502102053.PAA06371@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Date: Thu, 10 Feb 2005 15:53:14 -0500 Received-SPF: none (bart.w3.org: domain of dinaras@cnri.reston.va.us does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: I-D ACTION:draft-ietf-webdav-redirectref-protocol-11.txt X-Archived-At: http://www.w3.org/mid/200502102053.PAA06371@ietf.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9423 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 10 Feb 2005 20:53:20 +0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. Title : Web Distributed Authoring and Versioning (WebDAV) Redirect Reference Resources Author(s) : J. Whitehead, et al. Filename : draft-ietf-webdav-redirectref-protocol-11.txt Pages : 34 Date : 2005-2-10 This specification defines redirect reference resources. A redirect reference resource is a resource whose default response is an HTTP/ 1.1 3xx (Redirection) status code (see RFC2616, Section 10.3), redirecting the client to a different resource, the target resource. A redirect reference makes it possible to access the target resource indirectly, through any URI mapped to the redirect reference resource. There are no integrity guarantees associated with redirect reference resources. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-redirectref-protocol-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-webdav-redirectref-protocol-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-webdav-redirectref-protocol-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-10160003.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-redirectref-protocol-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-redirectref-protocol-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-10160003.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Thu Feb 10 16:19:31 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04762 for ; Thu, 10 Feb 2005 15:34:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CzKzN-0007Tk-9g for w3c-dist-auth-dist@listhub.w3.org; Thu, 10 Feb 2005 20:32:37 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CzKzN-0007TB-10 for w3c-dist-auth@listhub.w3.org; Thu, 10 Feb 2005 20:32:37 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.34) id 1CzKzM-0005xw-Li for w3c-dist-auth@w3.org; Thu, 10 Feb 2005 20:32:36 +0000 Received: (qmail invoked by alias); 10 Feb 2005 20:32:04 -0000 Received: from pD9E51897.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.24.151) by mail.gmx.net (mp010) with SMTP; 10 Feb 2005 21:32:04 +0100 X-Authenticated: #1915285 Message-ID: <420BC4BF.9070301@gmx.de> Date: Thu, 10 Feb 2005 21:31:59 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <200502092032.PAA10713@ietf.org> In-Reply-To: <200502092032.PAA10713@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Review of quota-06, Re: I-D ACTION:draft-ietf-webdav-quota-06.txt X-Archived-At: http://www.w3.org/mid/420BC4BF.9070301@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9422 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 10 Feb 2005 20:32:37 +0000 Content-Transfer-Encoding: 7bit Hi, below is my updated issues list... Best regards, Julian -- snip -- Issues with draft-ietf-webdav-quota-06.txt Content 01-C03 quota vs disk space The spec says that servers may expose physical disk limits as quota. a) This is incompatible with NFS from which we're borrowing the semantics (it treats disk limits as a separate property, and so should we) Update -04: this still appears in the text, but is less critical now that authorability of the quota is gone. I'd still like to see the working group make an explicit decision to keep this, because it's IMHO clearly outside the scope of this spec (I'd prefer separate properties). 04-C07, section 3, DAV:quota-available-bytes "Support for this property is REQUIRED on collections, and OPTIONAL on other resources. A server SHOULD implement this property for each resource that has the DAV:quota-used-bytes property." What's the motivation for the distinction? (same in section 4) 04-C11, section 7 "The total size of a collection, DAV:quota-used-bytes, is not necessarily a sum of the DAV:getcontentlength properties for resources stored in the collection." Actually, it won't be in most cases I'm aware of. Please either rephrase it (so this doesn't sound like an edge case) or drop the point. Update -06: It's now saying "The total size of a collection, DAV:quota-used-bytes, may not be a sum of the DAV:getcontentlength properties for resources stored in the collection." ...which isn't that different... 05-C02, Section 4 I think this property is "computed" (as defined in RFC3253), and the spec should say so. 05-E01, section 1.2 I'd move those parts that "import" terminology from RFC2518/3253 into a separate subsection ("Terminology"), and also refer to the def of "computed" property (I think we need that later). From w3c-dist-auth-request@w3.org Thu Feb 10 16:26:56 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13562 for ; Thu, 10 Feb 2005 16:26:56 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CzLow-0006gW-Bl for w3c-dist-auth-dist@listhub.w3.org; Thu, 10 Feb 2005 21:25:54 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CzLow-0006fx-0q for w3c-dist-auth@listhub.w3.org; Thu, 10 Feb 2005 21:25:54 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CzLov-0006fj-N7 for w3c-dist-auth@w3.org; Thu, 10 Feb 2005 21:25:53 +0000 Received: (qmail invoked by alias); 10 Feb 2005 21:25:21 -0000 Received: from pD9E51897.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.24.151) by mail.gmx.net (mp002) with SMTP; 10 Feb 2005 22:25:21 +0100 X-Authenticated: #1915285 Message-ID: <420BD13A.9080204@gmx.de> Date: Thu, 10 Feb 2005 22:25:14 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <200502102053.PAA06371@ietf.org> In-Reply-To: <200502102053.PAA06371@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: I-D ACTION:draft-ietf-webdav-redirectref-protocol-11.txt X-Archived-At: http://www.w3.org/mid/420BD13A.9080204@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9424 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 10 Feb 2005 21:25:54 +0000 Content-Transfer-Encoding: 7bit This draft revision assembles a set of mainly editorial changes and was made so that there's an up-to-date version online in time before the next IETF. Changes are: Add and resolve issues "13_allprop" and "rfc2396bis". Use the term "Request-URI" throughout (this is what RFC2616 defines). Center some of the artwork. Add and resolve issue "abnf". Closed Issues: C.1 abnf Type: change julian.reschke@greenbytes.de (2005-02-09): Use ABNF syntax from RFC2234. Resolution (2005-02-09): Done. C.2 rfc2396bis Type: change julian.reschke@greenbytes.de (2004-10-22): Update to RFC2396bis (this needs to be done carefully because we are using the term "relative URI reference" which does not exist in RFC2396bis anymore). Resolution (2005-01-25): Agreed (draft-rfc2396bis has been published as RFC3986). C.3 13_allprop Type: change julian.reschke@greenbytes.de (2004-11-13): Make the spec consistent with RFC3253, RFC3648 and RFC3744 (new properties not returned upon PROPFIND/allprop requests). Resolution (2004-11-13): Add statement about PROPFIND/allprop behaviour. Open Issues remaining: D.1 edit Type: edit julian.reschke@greenbytes.de (2004-10-03): Umbrella issue for editorial changes. D.2 old_clients Type: change julian.reschke@greenbytes.de (2003-11-10): There are (at least) two major design goals, but unfortunately both are in direct contradiction: #1: Maximum consistency with HTTP/1.1 (RFC2616). This means that any request that addresses a redirect reference resource MUST result in a 3xx status code (obviously the whole point is that GET MUST result in a redirection, and if it does, it's hard to say why other methods such as PUT or DELETE should behave differently). Therefore, the redirect reference protocol introduces a new request header ("Apply-To-Redirect-Ref") through which a client can indicate that the request indeed should be applied to the redirect reference resource itself. #2: Maximum usability with existing clients. For instance, the Microsoft Webfolder client will not be able to DELETE a redirect reference resource unless the server deviates from #1. Right now I'm not sure about the best way to resolve this. Currently the spec chooses #1 (back when this decision was made, there was probably the assumption that existing clients would quickly be updated -- something that probably isn't true today). However this may result in implementers either just ignoring these rules, or adding special workarounds based on "User Agent" detection. Best regards, Julian From w3c-dist-auth-request@w3.org Thu Feb 10 16:35:09 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15401 for ; Thu, 10 Feb 2005 16:35:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CzLwr-0000ia-MF for w3c-dist-auth-dist@listhub.w3.org; Thu, 10 Feb 2005 21:34:05 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CzLwr-0000i3-DK for w3c-dist-auth@listhub.w3.org; Thu, 10 Feb 2005 21:34:05 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CzLwr-0007ah-34 for w3c-dist-auth@w3.org; Thu, 10 Feb 2005 21:34:05 +0000 Received: (qmail invoked by alias); 10 Feb 2005 21:33:32 -0000 Received: from pD9E51897.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.24.151) by mail.gmx.net (mp018) with SMTP; 10 Feb 2005 22:33:32 +0100 X-Authenticated: #1915285 Message-ID: <420BD326.4090805@gmx.de> Date: Thu, 10 Feb 2005 22:33:26 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke CC: Joe Hildebrand , webdav References: <1aef7c87a3636e35da541fba00215c3c@jabber.com> <4204026B.1070104@gmx.de> In-Reply-To: <4204026B.1070104@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Status of working group last call on BIND X-Archived-At: http://www.w3.org/mid/420BD326.4090805@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9425 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 10 Feb 2005 21:34:05 +0000 Content-Transfer-Encoding: 7bit Julian Reschke wrote: > Thanks Joe, > > from my p.o.v.: > > #2) Should be closed: consensus for the change made with > > > > #5) Should be closed: has 0 votes on it > > #71) Should be closed: has only 1 vote on it from Elias, and he's > satisfied with the explanations and changes made > (). > > #71b) The question raised by you, Joe, in > > is IMHO a distinct issue, it's being tracked with > , > you may want to open a new BugZilla issue if you feel that there's a > risk that we're not following up properly. > > > Regarding the three issues raised post-last-call: please give guidance > on how to proceed. So far, there aren't any votes on them, and it > doesn't seem any new feedback is coming in. I think we still should plan > to submit a document for publication in time before the IETF, which is > roughly two weeks from now. I note that no further discussion has taken place since the issues were entered (and replied to). There are also no votes on them so far. Unless there's any new discussion on these topics, I'll submit the current spec before the end of the next week and ask the WG chairs to submit it to the IESG for last call. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Feb 10 18:00:08 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03433 for ; Thu, 10 Feb 2005 18:00:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CzNGp-0005Mu-Ka for w3c-dist-auth-dist@listhub.w3.org; Thu, 10 Feb 2005 22:58:47 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CzNGn-0005Lv-FJ for w3c-dist-auth@listhub.w3.org; Thu, 10 Feb 2005 22:58:45 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1CzNGn-0001oy-5m for w3c-dist-auth@w3.org; Thu, 10 Feb 2005 22:58:45 +0000 Received: (qmail invoked by alias); 10 Feb 2005 22:58:10 -0000 Received: from pD9E51897.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.24.151) by mail.gmx.net (mp002) with SMTP; 10 Feb 2005 23:58:10 +0100 X-Authenticated: #1915285 Message-ID: <420BE6FA.9090200@gmx.de> Date: Thu, 10 Feb 2005 23:58:02 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Mogul CC: ietf-http-wg@w3.org, w3c-dist-auth@w3.org References: <200501211938.j0LJcBmo001217@wera.hpl.hp.com> In-Reply-To: <200501211938.j0LJcBmo001217@wera.hpl.hp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Defining extensions for the "Expect" header X-Archived-At: http://www.w3.org/mid/420BE6FA.9090200@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9426 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 10 Feb 2005 22:58:47 +0000 Content-Transfer-Encoding: 7bit Jeffrey Mogul wrote: > ... > Note that RFC2817, which defined the status code registry, > was titled "Upgrading to TLS Within HTTP/1.1". I think it > is generally a mistake to define a generic registry within > the specification of a specific protocol ... maybe someone > thought it would be easier to get one RFC blessed than two, > but if the IESG doesn't like the specific protocol, then > the registry definition could be held hostage until they are > happy about the protocol. > ... Jeffrey, thanks for the feedback. RFC2817 is really interesting, it states: "7.1 HTTP Status Code Registry The HTTP Status Code Registry defines the name space for the Status- Code token in the Status line of an HTTP response. The initial values for this name space are those specified by: 1. Draft Standard for HTTP/1.1 [1] 2. Web Distributed Authoring and Versioning [4] [defines 420-424] 3. WebDAV Advanced Collections [5] (Work in Progress) [defines 425] 4. Section 6 [defines 426] Values to be added to this name space SHOULD be subject to review in the form of a standards track document within the IETF Applications Area. Any such document SHOULD be traceable through statuses of either 'Obsoletes' or 'Updates' to the Draft Standard for HTTP/1.1 [1]." Note, - RFC2518 [4] defined 422-424 and 507, but not 420 and 421 (and was published before RFC2817) () - The only document that actually *does* update RFC2616 is RFC2817 :-) The WebDAV WG is indeed working on a document that defines new status codes (): should it indeed say that it updates RFC2616? Speaking of which: is there a registry for HTTP method names (almost all specs produced by the WebDAV WG define new method names...)? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Feb 10 23:39:51 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29288 for ; Thu, 10 Feb 2005 23:39:51 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CzSYz-0000LP-Ep for w3c-dist-auth-dist@listhub.w3.org; Fri, 11 Feb 2005 04:37:53 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CzSYy-0000Ks-5y for w3c-dist-auth@listhub.w3.org; Fri, 11 Feb 2005 04:37:52 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by bart.w3.org with esmtp (Exim 4.34) id 1CzSYy-000889-0e for w3c-dist-auth@w3.org; Fri, 11 Feb 2005 04:37:52 +0000 Received: from [192.168.1.151] ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 10 Feb 2005 20:37:17 -0800 In-Reply-To: <420BC477.5060207@gmx.de> References: <95C2A37A-6B2A-11D9-A835-000A95AACED2@xythos.com> <41F3953C.9060702@gmx.de> <23C5C89A-7961-11D9-84E6-000A95AACED2@xythos.com> <420BC477.5060207@gmx.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9BD9E20C-7BE6-11D9-84E6-000A95AACED2@xythos.com> Content-Transfer-Encoding: 7bit Cc: WebDAV WG From: Brian Korver Date: Thu, 10 Feb 2005 20:37:17 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 11 Feb 2005 04:37:17.0767 (UTC) FILETIME=[5DF40570:01C50FF3] Received-SPF: none (bart.w3.org: domain of briank@xythos.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on draft-ietf-webdav-quota-05.txt, Was: Fwd: I-D ACTION:draft-ietf-webdav-quota-05.txt X-Archived-At: http://www.w3.org/mid/9BD9E20C-7BE6-11D9-84E6-000A95AACED2@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9427 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 11 Feb 2005 04:37:53 +0000 Content-Transfer-Encoding: 7bit On Feb 10, 2005, at 12:30 PM, Julian Reschke wrote: > Brian Korver wrote: >> ... >>> 04-C11, section 7 >>> >>> "The total size of a collection, DAV:quota-used-bytes, is not >>> necessarily a sum of the DAV:getcontentlength properties for >>> resources stored in the collection." >>> >>> Actually, it won't be in most cases I'm aware of. Please either >>> rephrase it (so this doesn't sound like an edge case) or drop the >>> point. >> Fixed in -05 > > It's now saying > > "The total size of a collection, DAV:quota-used-bytes, may not be a > sum of the DAV:getcontentlength properties for resources stored in the > collection." > > ...which isn't that different... Ok, then what wording would you suggest? > > >> ... >>> 05-E02, section 5 >>> >>> >> -05.html#rfc.section.5> >>> >>> The artwork in the request is too wide for RFC publication and >>> should be re-indented (the response isn't too wide but should be >>> re-indented for consistency nevertheless). >>> >> Fixed in -06. If it's still not to your liking, let me know how >> and I'll change it. > > Seems to be fine now. > > > ... > > > Best regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -brian briank@xythos.com From w3c-dist-auth-request@w3.org Fri Feb 11 03:32:46 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07993 for ; Fri, 11 Feb 2005 03:32:46 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CzWCz-0004sq-62 for w3c-dist-auth-dist@listhub.w3.org; Fri, 11 Feb 2005 08:31:25 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CzWCy-0004s0-0c for w3c-dist-auth@listhub.w3.org; Fri, 11 Feb 2005 08:31:24 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1CzWCx-0007y1-LT for w3c-dist-auth@w3.org; Fri, 11 Feb 2005 08:31:23 +0000 Received: (qmail invoked by alias); 11 Feb 2005 08:30:50 -0000 Received: from pD9E51897.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.24.151) by mail.gmx.net (mp025) with SMTP; 11 Feb 2005 09:30:50 +0100 X-Authenticated: #1915285 Message-ID: <420C6D36.7040205@gmx.de> Date: Fri, 11 Feb 2005 09:30:46 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Korver CC: WebDAV WG References: <95C2A37A-6B2A-11D9-A835-000A95AACED2@xythos.com> <41F3953C.9060702@gmx.de> <23C5C89A-7961-11D9-84E6-000A95AACED2@xythos.com> <420BC477.5060207@gmx.de> <9BD9E20C-7BE6-11D9-84E6-000A95AACED2@xythos.com> In-Reply-To: <9BD9E20C-7BE6-11D9-84E6-000A95AACED2@xythos.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on draft-ietf-webdav-quota-05.txt, Was: Fwd: I-D ACTION:draft-ietf-webdav-quota-05.txt X-Archived-At: http://www.w3.org/mid/420C6D36.7040205@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9428 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 11 Feb 2005 08:31:25 +0000 Content-Transfer-Encoding: 7bit Brian Korver wrote: > > On Feb 10, 2005, at 12:30 PM, Julian Reschke wrote: > >> Brian Korver wrote: >> >>> ... >>> >>>> 04-C11, section 7 >>>> >>>> "The total size of a collection, DAV:quota-used-bytes, is not >>>> necessarily a sum of the DAV:getcontentlength properties for >>>> resources stored in the collection." >>>> >>>> Actually, it won't be in most cases I'm aware of. Please either >>>> rephrase it (so this doesn't sound like an edge case) or drop the >>>> point. >>> >>> Fixed in -05 >> >> >> It's now saying >> >> "The total size of a collection, DAV:quota-used-bytes, may not be a >> sum of the DAV:getcontentlength properties for resources stored in the >> collection." >> >> ...which isn't that different... > > > Ok, then what wording would you suggest? Fact is: - in many quota implementations, there will be connection whatsoever between both (because members do not count to the size of a collection), - even if they do, usually the collection itself and metadata will use space that may be counted. The easiest fix is not to say anything here. > ... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sun Feb 13 08:47:08 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24446 for ; Sun, 13 Feb 2005 08:47:07 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D0K33-0001vm-6K for w3c-dist-auth-dist@listhub.w3.org; Sun, 13 Feb 2005 13:44:29 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D0K31-0001vD-TQ for w3c-dist-auth@listhub.w3.org; Sun, 13 Feb 2005 13:44:27 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1D0K31-0001Qx-IM for w3c-dist-auth@w3.org; Sun, 13 Feb 2005 13:44:27 +0000 Received: (qmail invoked by alias); 13 Feb 2005 13:43:55 -0000 Received: from pD9FF0A59.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.10.89) by mail.gmx.net (mp008) with SMTP; 13 Feb 2005 14:43:55 +0100 X-Authenticated: #1915285 Message-ID: <420F598B.5070204@gmx.de> Date: Sun, 13 Feb 2005 14:43:39 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: State of a lock X-Archived-At: http://www.w3.org/mid/420F598B.5070204@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9429 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sun, 13 Feb 2005 13:44:29 +0000 Content-Transfer-Encoding: 7bit Hi, in , I just extended the description of the status of a WebDAV lock to also contain information about the authenticated principal on whose behalf the lock was created. To clarify the role of "Lock Owner", I renamed that subsection to "Client-supplied Lock Owner Information". Both changes should now make it clear that the state of a lock indeed may include both pieces of information (which may have little relation to each other). The new text reads: 2.5.5 Client-supplied Lock Owner Information (optional) Clients can submit information about the lock owner when creating a lock. This information should be sufficient for either directly contacting a principal (such as a telephone number or email URI), or for discovering the principal (such as the URL of a homepage). Owner information is kept with the lock so that it can be returned in the DAV:lockdiscovery property upon request. Note that this information is entirely client-controlled, thus a server MUST store the information faithfully just like if it appeared in a WebDAV dead property (see [RFC2518], section 4). 2.5.6 Lock Creator (optional) When a lock has been created by an authenticated principal, the server SHOULD keep information about that principal with the lock. This enables the server to subsequently check whether a lock identified by a lock token submitted in a request belongs to the same principal on whose behalf the lock was initially created (see Section 8.2.1 below). (Change tracked at ). Feedback appreciated, Julian From w3c-dist-auth-request@w3.org Sun Feb 13 14:01:22 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15568 for ; Sun, 13 Feb 2005 14:01:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D0OyA-0003zr-SE for w3c-dist-auth-dist@listhub.w3.org; Sun, 13 Feb 2005 18:59:46 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D0Oy9-0003zE-GV for w3c-dist-auth@listhub.w3.org; Sun, 13 Feb 2005 18:59:45 +0000 Received: from e4.ny.us.ibm.com ([32.97.182.144]) by lisa.w3.org with esmtp (Exim 4.34) id 1D0Oy9-0003jG-Bx for w3c-dist-auth@w3.org; Sun, 13 Feb 2005 18:59:45 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j1DIxEoM024026 for ; Sun, 13 Feb 2005 13:59:14 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1DIxERr281812 for ; Sun, 13 Feb 2005 13:59:14 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1DIxE5m006394 for ; Sun, 13 Feb 2005 13:59:14 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1DIxE2T006391 for ; Sun, 13 Feb 2005 13:59:14 -0500 In-Reply-To: <420F598B.5070204@gmx.de> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Sun, 13 Feb 2005 13:59:12 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 02/13/2005 13:59:14, Serialize complete at 02/13/2005 13:59:14 Content-Type: multipart/alternative; boundary="=_alternative 00684CD585256FA7_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.144 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: State of a lock X-Archived-At: http://www.w3.org/mid/OF485F699C.337DBD6A-ON85256FA7.00683A7C-85256FA7.00684CD9@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9430 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sun, 13 Feb 2005 18:59:46 +0000 This is a multipart message in MIME format. --=_alternative 00684CD585256FA7_= Content-Type: text/plain; charset="US-ASCII" Sounds reasonable to me. Cheers, Geoff Julian wrote on 02/13/2005 08:43:39 AM: > > Hi, > > in > , > I just extended the description of the status of a WebDAV lock to also > contain information about the authenticated principal on whose behalf > the lock was created. To clarify the role of "Lock Owner", I renamed > that subsection to "Client-supplied Lock Owner Information". Both > changes should now make it clear that the state of a lock indeed may > include both pieces of information (which may have little relation to > each other). > > The new text reads: > > 2.5.5 Client-supplied Lock Owner Information (optional) > > Clients can submit information about the lock owner when creating a > lock. This information should be sufficient for either directly > contacting a principal (such as a telephone number or email URI), or > for discovering the principal (such as the URL of a homepage). > > Owner information is kept with the lock so that it can be returned in > the DAV:lockdiscovery property upon request. Note that this > information is entirely client-controlled, thus a server MUST store > the information faithfully just like if it appeared in a WebDAV dead > property (see [RFC2518], section 4). > > 2.5.6 Lock Creator (optional) > > When a lock has been created by an authenticated principal, the > server SHOULD keep information about that principal with the lock. > This enables the server to subsequently check whether a lock > identified by a lock token submitted in a request belongs to the same > principal on whose behalf the lock was initially created (see > Section 8.2.1 below). > > > (Change tracked at > latest.html#rfc.issue.lock_state_auth_principal>). > > Feedback appreciated, > > Julian > --=_alternative 00684CD585256FA7_= Content-Type: text/html; charset="US-ASCII"
Sounds reasonable to me.

Cheers,
Geoff

Julian wrote on 02/13/2005 08:43:39 AM:
>
> Hi,
>
> in
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html>,
> I just extended the description of the status of a WebDAV lock to also
> contain information about the authenticated principal on whose behalf
> the lock was created. To clarify the role of "Lock Owner", I renamed
> that subsection to "Client-supplied Lock Owner Information". Both
> changes should now make it clear that the state of a lock indeed may
> include both pieces of information (which may have little relation to
> each other).
>
> The new text reads:
>
> 2.5.5  Client-supplied Lock Owner Information (optional)
>
>     Clients can submit information about the lock owner when creating a
>     lock.  This information should be sufficient for either directly
>     contacting a principal (such as a telephone number or email URI), or
>     for discovering the principal (such as the URL of a homepage).
>
>     Owner information is kept with the lock so that it can be returned in
>     the DAV:lockdiscovery property upon request.  Note that this
>     information is entirely client-controlled, thus a server MUST store
>     the information faithfully just like if it appeared in a WebDAV dead
>     property (see [RFC2518], section 4).
>
> 2.5.6  Lock Creator (optional)
>
>     When a lock has been created by an authenticated principal, the
>     server SHOULD keep information about that principal with the lock.
>     This enables the server to subsequently check whether a lock
>     identified by a lock token submitted in a request belongs to the same
>     principal on whose behalf the lock was initially created (see
>     Section 8.2.1 below).
>
>
> (Change tracked at
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-
> latest.html#rfc.issue.lock_state_auth_principal>).
>
> Feedback appreciated,
>
> Julian
>
--=_alternative 00684CD585256FA7_=-- From w3c-dist-auth-request@w3.org Tue Feb 15 07:03:16 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22295 for ; Tue, 15 Feb 2005 07:03:16 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D11Oa-0006T4-QB for w3c-dist-auth-dist@listhub.w3.org; Tue, 15 Feb 2005 12:01:36 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D11OZ-0006SY-Fy for w3c-dist-auth@listhub.w3.org; Tue, 15 Feb 2005 12:01:35 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1D11OZ-0008BR-5R for w3c-dist-auth@w3.org; Tue, 15 Feb 2005 12:01:35 +0000 Received: (qmail invoked by alias); 15 Feb 2005 12:01:03 -0000 Received: from p50824ABC.dip0.t-ipconnect.de (EHLO [192.168.1.87]) (80.130.74.188) by mail.gmx.net (mp009) with SMTP; 15 Feb 2005 13:01:03 +0100 X-Authenticated: #1915285 Message-ID: <4211E478.8070907@gmx.de> Date: Tue, 15 Feb 2005 13:00:56 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/4211E478.8070907@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9431 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 15 Feb 2005 12:01:36 +0000 Content-Transfer-Encoding: 7bit (fyi) -------- Original Message -------- > ... Hi, recently different communities (caldav/groupdav, atompup (protocol part)) have been discussing how to use HTTP to author new resources when the URL namespace is completely server-controlled, thus PUT just doesn't fit well. A simple approach would be to define a new HTTP method which is *almost* like PUT, except that the server chooses the URL to create (and returns it in the Location header). I've submitted a first draft as "draft-reschke-http-addmember-00". Note that it also contains an appendix covering possible alternative approaches. Feedback appreciated, Julian HTML version: Latest edits will be at: bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Feb 15 17:04:22 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17820 for ; Tue, 15 Feb 2005 17:04:22 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1AmO-0005kE-1v for w3c-dist-auth-dist@listhub.w3.org; Tue, 15 Feb 2005 22:02:48 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D1AmM-0005iZ-2Y for w3c-dist-auth@listhub.w3.org; Tue, 15 Feb 2005 22:02:46 +0000 Received: from bsl-rtr.day.com ([212.249.34.130] helo=picanmix.dev.day.com) by bart.w3.org with esmtp (Exim 4.34) id 1D1AmL-0002iU-Np for w3c-dist-auth@w3.org; Tue, 15 Feb 2005 22:02:46 +0000 Received: from eu-mail.day.com (eu-mail.dev.day.com [10.0.0.30]) by picanmix.dev.day.com (DAY) with ESMTP id j1FM2hf13389; Tue, 15 Feb 2005 23:02:43 +0100 (MET) Received: from [10.2.8.58] ([10.2.8.58]) by eu-mail.day.com (Lotus Domino Release 5.0.8) with ESMTP id 2005021523024187:42346 ; Tue, 15 Feb 2005 23:02:41 +0100 In-Reply-To: <4211E478.8070907@gmx.de> References: <4211E478.8070907@gmx.de> Mime-Version: 1.0 (Apple Message framework v619.2) Message-Id: Cc: w3c-dist-auth@w3.org From: "Roy T. Fielding" Date: Tue, 15 Feb 2005 14:02:40 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.619.2) X-MIMETrack: Itemize by SMTP Server on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 02/15/2005 11:02:42 PM, Serialize by Router on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 02/15/2005 11:02:43 PM, Serialize complete at 02/15/2005 11:02:43 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Received-SPF: none (bart.w3.org: domain of fielding@gbiv.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/bec41da6eccca39db310305f01126357@gbiv.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9432 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 15 Feb 2005 22:02:48 +0000 Content-Transfer-Encoding: 7bit On Feb 15, 2005, at 4:00 AM, Julian Reschke wrote: > recently different communities (caldav/groupdav, atompup (protocol > part)) have been discussing how to use HTTP to author new resources > when > the URL namespace is completely server-controlled, thus PUT just > doesn't > fit well. > > A simple approach would be to define a new HTTP method which is > *almost* > like PUT, except that the server chooses the URL to create (and returns > it in the Location header). > > I've submitted a first draft as "draft-reschke-http-addmember-00". Note > that it also contains an appendix covering possible alternative > approaches. Julian, POST to a collection resource is already defined as adding a member resource. That was its very first definition (hence, named after NNTP's post) and remains applicable today. Cheers, Roy T. Fielding Chief Scientist, Day Software From nobody@thnux2.thaihostsave.com Wed Feb 16 09:13:30 2005 Received: from thnux2.thaihostsave.com (202.57.163.164.rev-ip.isp-thailand.com [202.57.163.164] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12070 for ; Wed, 16 Feb 2005 09:13:29 -0500 (EST) Received: from thnux2.thaihostsave.com (thnux2 [127.0.0.1]) by thnux2.thaihostsave.com (8.12.8/8.12.8) with ESMTP id j1H3q5hE015996; Wed, 16 Feb 2005 20:52:11 -0700 Received: (from nobody@localhost) by thnux2.thaihostsave.com (8.12.8/8.12.8/Submit) id j1H3m2hw015374; Wed, 16 Feb 2005 20:48:02 -0700 Date: Wed, 16 Feb 2005 20:48:02 -0700 Message-Id: <200502170348.j1H3m2hw015374@thnux2.thaihostsave.com> Subject: PERSONAL From: briancummings X-Priority: 3 (Normal) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: RLSP Mailer Content-Transfer-Encoding: 7bit NUEVO ORO LOTTO COMPANY S.L CALLE LIMA 27. MADRID 28081 SPAIN. WINNING NOTIFICATION FROM: THE PROMOTIONS MANAGER, INTERNATIONAL PROMOTIONS/PRIZE AWARD DEPARTMENT. REF: NL/3167084000127/04 BATCH: 17/00421/IPD RE: AWARD NOTICE. We are pleased to inform you of the announcement, of winners of the: NUEVO LOTERIA/INTERNATIONAL PROMOTION PROGRAM held on 20TH January,2005. Your contact is attached to ticket number 106-007225644647, with serial number 114876 drew the lucky numbers 07-13-27-29-31-47, and consequently won the lottery in the 1A category. You have therefore been approved for a lump sum pay out of One Million Six Hundred and fourty-Seven Thousand, Eight Hundred and Twenty Eight Euros and Eighty-Seven Euro Cents.(EUROS 1.647.828.87) in cash credited to file No:LP/26510460037/02. For all our international winners the value of the amount comes to ($2.045.238.63 USD) Two Million Fouty-Five thousand,two hundred and thrity-eight United States Dollars and Sixty three cents. This is from total prize money of EUROS 47.640.120.00 shared among the Fifty three local and international winners in all the categories. All participants were selected through a computer ballot system drawn form 116,000 names from Australia, New Zealand, Africa, Europe, North and South America and Asia as part of International Promotions Program, which is conducted annually. CONGRATULATIONS!!! Your fund is now insured to your contact. Due to the computer mix up of some numbers and contacts, we ask that you keep this award strictly from public notice until your claim has been processed and your money remitted to your account. This is part of our security protocol to avoid double claiming or unscrupulous acts by participants of this program. We hope with a part of you prize, you will participate in our end of year high stakes Euros 1.1 billion International Lottery. To begin your claim, please contact the undersigned. Since all we have now is the winning ticket number and your contact which was attached to the ticket number, we shall thus await further directives from you on how to have your winning paid to you. For due processing and remittance of your prize money to a designated account . We also want to apologise for this late notification which was due a computer mix up. Remember, all prize money must be claimed not later than 25TH February 2005. After this date, all funds will be returned as unclaimed. NOTE: In order to avoid unnecessary delays and complications, please remember to quote your reference and batch numbers in every one of your correspondences with us. Furthermore, should there be any change of your address, do inform your claims agent as soon as possible. Congratulations again from all our staff and thank you for being part of our promotions program. Sincerely, BRIAN CUMMINGS To file for your claim, please contact our fiduciary agent Mr. Antonio Pablo EMAIL:agentantonio90@netscape.net NUEVO ORO LOTTO COMPANY S.L CALLE LIMA 27. MADRID 28081 SPAIN ___________________________________________________________________________ ¨´ËÁÒ¨ҡºÃÔ¡Òà Web mail á¼¹¡ªèҧ¹µì ÇÔ·ÂÒÅÑÂà·¤¹Ô¤¨Ñ¹·ºØÃÕ http://www.autochan.in.th From w3c-dist-auth-request@w3.org Wed Feb 16 12:49:35 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05477 for ; Wed, 16 Feb 2005 12:49:35 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1TGA-0003r4-66 for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Feb 2005 17:46:46 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D1TG8-0003qX-UB for w3c-dist-auth@listhub.w3.org; Wed, 16 Feb 2005 17:46:44 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by bart.w3.org with esmtp (Exim 4.34) id 1D1TG8-0006ey-LV for w3c-dist-auth@w3.org; Wed, 16 Feb 2005 17:46:44 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id j1GHkbZ5015167; Wed, 16 Feb 2005 09:46:37 -0800 (PST) Message-Id: <200502161746.j1GHkbZ5015167@services.cse.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'Roy T. Fielding'" , "'Julian Reschke'" Cc: Date: Wed, 16 Feb 2005 09:46:30 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcUTqj7dYBr/YgpxS5+46jTO9E5xMQApOIYg Received-SPF: none (bart.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/200502161746.j1GHkbZ5015167@services.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9433 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 16 Feb 2005 17:46:46 +0000 Content-Transfer-Encoding: 7bit Julian, Thanks for writing this draft -- I've been thinking along similar lines recently. Roy Fielding writes: > Julian, POST to a collection resource is already defined as > adding a member resource. That was its very first definition > (hence, named after NNTP's post) and remains applicable today. RFC 2616 states: "The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI." >From a client perspective this makes POST unreliable, and leads to the desire to define a new method. Besides, despite what RFC 2616 actually says, POST is really the protocol tunneling and form submission method. - Jim From w3c-dist-auth-request@w3.org Wed Feb 16 12:52:57 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06406 for ; Wed, 16 Feb 2005 12:52:57 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1TKl-0005gO-Rd for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Feb 2005 17:51:31 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D1TKl-0005fb-Gm for w3c-dist-auth@listhub.w3.org; Wed, 16 Feb 2005 17:51:31 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1D1TKl-0007RY-5a for w3c-dist-auth@w3.org; Wed, 16 Feb 2005 17:51:31 +0000 Received: (qmail invoked by alias); 16 Feb 2005 17:50:59 -0000 Received: from p5082478F.dip0.t-ipconnect.de (EHLO [192.168.1.87]) (80.130.71.143) by mail.gmx.net (mp014) with SMTP; 16 Feb 2005 18:50:59 +0100 X-Authenticated: #1915285 Message-ID: <42138800.1050602@gmx.de> Date: Wed, 16 Feb 2005 18:50:56 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-http-wg@w3.org CC: ejw@soe.ucsc.edu, w3c-dist-auth@w3.org References: <200502161746.j1GHkbZ5015167@services.cse.ucsc.edu> In-Reply-To: <200502161746.j1GHkbZ5015167@services.cse.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/42138800.1050602@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9434 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 16 Feb 2005 17:51:31 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > Julian, > > Thanks for writing this draft -- I've been thinking along similar lines > recently. > > Roy Fielding writes: > >>Julian, POST to a collection resource is already defined as >>adding a member resource. That was its very first definition >>(hence, named after NNTP's post) and remains applicable today. > > > RFC 2616 states: > "The actual function performed by the POST method is determined by the > server and is usually dependent on the Request-URI." > >>From a client perspective this makes POST unreliable, and leads to the > desire to define a new method. > > Besides, despite what RFC 2616 actually says, POST is really the protocol > tunneling and form submission method. Thanks Roy and Jim for the feedback. When I sent the announcement, I forgot to redirect feedback to a single place, which should be (which I include in this reply). Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Feb 16 15:41:21 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21286 for ; Wed, 16 Feb 2005 15:41:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1Vx7-0008HS-4G for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Feb 2005 20:39:17 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D1Vx5-0008Gu-QL for w3c-dist-auth@listhub.w3.org; Wed, 16 Feb 2005 20:39:15 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1D1Vx5-0000tD-Fl for w3c-dist-auth@w3.org; Wed, 16 Feb 2005 20:39:15 +0000 Received: (qmail invoked by alias); 16 Feb 2005 20:38:41 -0000 Received: from pD9E51A67.dip.t-dialin.net (EHLO [192.168.0.3]) (217.229.26.103) by mail.gmx.net (mp022) with SMTP; 16 Feb 2005 21:38:41 +0100 X-Authenticated: #1915285 Message-ID: <4213AF4C.3080101@gmx.de> Date: Wed, 16 Feb 2005 21:38:36 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <420F598B.5070204@gmx.de> In-Reply-To: <420F598B.5070204@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: draft-reschke-webdav-locking-07, was: State of a lock X-Archived-At: http://www.w3.org/mid/4213AF4C.3080101@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9435 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 16 Feb 2005 20:39:17 +0000 Content-Transfer-Encoding: 7bit Hi, a new version (-07) of my experimental stand-alone WebDAV locking spec has been submitted and is available from . Changes were: --snip-- Appendix F. Resolved issues (to be removed by RFC Editor before publication) Issues that were either rejected or resolved in this version of this document. F.1 lock_state_auth_principal Type: change julian.reschke@greenbytes.de (2005-02-13): Mention the principal that was authenticated when the lock was created as part of the state of a lock; disambiguate with what previously was called "lock owner". Resolution (2005-02-13): Done. F.2 abnf Type: change julian.reschke@greenbytes.de (2005-02-12): Clarify BNF syntax (Notation, and when used). Resolution (2005-02-13): Done. F.3 uri_draft_ref Type: edit julian.reschke@greenbytes.de (2005-01-01): Fix reference to draft-fielding-uri-rfc2396bis-07. Resolution (2005-01-25): Update to RFC3986. F.4 D_delegate_UUID_definition Type: change julian.reschke@greenbytes.de (2005-01-30): Delegate the definition of UUIDs to draft-mealling-uuid-urn. Resolution (2005-02-06): Done. See also http://lists.w3.org/ Archives/Public/w3c-dist-auth/2005JanMar/0187.html. --snip-- Edits continue on . Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Feb 17 00:56:29 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18741 for ; Thu, 17 Feb 2005 00:56:29 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1ecF-00017O-HR for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Feb 2005 05:54:19 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D1ecE-00015r-5M for w3c-dist-auth@listhub.w3.org; Thu, 17 Feb 2005 05:54:18 +0000 Received: from scorpio.lunarpages.com ([64.235.234.122]) by lisa.w3.org with esmtp (Exim 4.34) id 1D1ecE-0007d4-06 for w3c-dist-auth@w3.org; Thu, 17 Feb 2005 05:54:18 +0000 Received: from wsip-24-248-98-242.oc.oc.cox.net ([24.248.98.242] helo=[10.2.8.58]) by scorpio.lunarpages.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.44) id 1D1ecB-0006j1-8Y; Wed, 16 Feb 2005 21:54:15 -0800 In-Reply-To: <200502161746.j1GHkbZ5015167@services.cse.ucsc.edu> References: <200502161746.j1GHkbZ5015167@services.cse.ucsc.edu> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <09334919a9cfa987692a0e20b90f5810@gbiv.com> Content-Transfer-Encoding: 7bit Cc: "'Julian Reschke'" , From: "Roy T. Fielding" Date: Wed, 16 Feb 2005 21:54:16 -0800 To: X-Mailer: Apple Mail (2.619.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - scorpio.lunarpages.com X-AntiAbuse: Original Domain - w3.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - gbiv.com Received-SPF: none (lisa.w3.org: domain of fielding@gbiv.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/09334919a9cfa987692a0e20b90f5810@gbiv.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9436 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 17 Feb 2005 05:54:19 +0000 Content-Transfer-Encoding: 7bit On Feb 16, 2005, at 9:46 AM, Jim Whitehead wrote: > RFC 2616 states: > "The actual function performed by the POST method is determined by the > server and is usually dependent on the Request-URI." > > From a client perspective this makes POST unreliable, and leads to the > desire to define a new method. The action will either succeed or fail. If it succeeds, the client will receive the exact same response from POST that it would have received from a new method. If it fails, the client will receive the same potential set of failure responses as it might have from a new method. The only way you could claim that a new method would be more reliable is if the client knows the exact implementation of the resource being requested, which is something that a client does not know with HTTP, and even if it did, it is far more likely that it will know how the server and all intermediaries will respond to the existing POST method than it could know about their response to a new method that has zero deployment. ....Roy From w3c-dist-auth-request@w3.org Thu Feb 17 04:30:27 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28368 for ; Thu, 17 Feb 2005 04:30:27 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1hyH-0007vh-Bz for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Feb 2005 09:29:17 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D1hyG-0007ul-31 for w3c-dist-auth@listhub.w3.org; Thu, 17 Feb 2005 09:29:16 +0000 Received: from server3a.software-ag.de ([193.26.193.83]) by lisa.w3.org with esmtp (Exim 4.34) id 1D1hyF-0000XV-Sm for w3c-dist-auth@w3.org; Thu, 17 Feb 2005 09:29:16 +0000 Received: from server3a.software-ag.de (localhost [127.0.0.1]) by localhost.software-ag.de (Postfix) with ESMTP id 3EEF7535F2 for ; Thu, 17 Feb 2005 10:28:39 +0100 (CET) Received: from DAEMSG03.eur.ad.sag (daemsg03a.eur.ad.sag [10.20.160.61]) by server3a.software-ag.de (Postfix) with ESMTP id 2D364535E9 for ; Thu, 17 Feb 2005 10:28:39 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Feb 2005 10:28:40 +0100 Message-ID: <76EEB38C72AE1D4EA2FE2753766EB5148D20A9@DAEMSG03.eur.ad.sag> Thread-Topic: Content encoding and MS Word ... Thread-Index: AcUU0zThJPuNPADJRCWPLHdvmF54AA== From: To: Received-SPF: none (lisa.w3.org: domain of Peter.Nevermann@softwareag.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Content encoding and MS Word ... X-Archived-At: http://www.w3.org/mid/76EEB38C72AE1D4EA2FE2753766EB5148D20A9@DAEMSG03.eur.ad.sag Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9437 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 17 Feb 2005 09:29:17 +0000 Content-Transfer-Encoding: quoted-printable Hi, in a project using Slide/Tamino which I am coaching, XHTML documents are stored using MS Word, where it is important to know the encoding of the content. Unfortunately, MS Word 2003 does *not* sent the encoding in the Content-Type header like: Content-Type: text/html; charset=3Dwindows-1252 but only sends the mime-type. As a consequence, the encoding is not available as part of the value of the DAV:getcontenttype property. Has anybody an idea how to make MS Word sending the encoding? Thanks & regards, Peter P.S.: As a workaround, I have written a servlet filter to "correct Word's fault" ... but possibly there is a better solution? From w3c-dist-auth-request@w3.org Thu Feb 17 07:34:30 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15672 for ; Thu, 17 Feb 2005 07:34:30 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1kqG-0000tk-NB for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Feb 2005 12:33:12 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D1kqF-0000sk-8Q for w3c-dist-auth@listhub.w3.org; Thu, 17 Feb 2005 12:33:11 +0000 Received: from e4.ny.us.ibm.com ([32.97.182.144]) by lisa.w3.org with esmtp (Exim 4.34) id 1D1kqF-0006ZD-2z for w3c-dist-auth@w3.org; Thu, 17 Feb 2005 12:33:11 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j1HCWeTp011038 for ; Thu, 17 Feb 2005 07:32:40 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1HCWeji220750 for ; Thu, 17 Feb 2005 07:32:40 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1HCWe72026012 for ; Thu, 17 Feb 2005 07:32:40 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1HCWeJx026006 for ; Thu, 17 Feb 2005 07:32:40 -0500 In-Reply-To: <09334919a9cfa987692a0e20b90f5810@gbiv.com> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Thu, 17 Feb 2005 07:32:44 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 02/17/2005 07:32:39, Serialize complete at 02/17/2005 07:32:39 Content-Type: multipart/alternative; boundary="=_alternative 0044E89E85256FAB_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.144 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/OF84C37498.FC31F4CA-ON85256FAB.0043FEB2-85256FAB.0044E8A3@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9438 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 17 Feb 2005 12:33:12 +0000 This is a multipart message in MIME format. --=_alternative 0044E89E85256FAB_= Content-Type: text/plain; charset="US-ASCII" I believe the problem arises when you are trying to apply the addmember function to a resource that already handles POST as meaning "do the operation specifies in the body of the POST". To use POST to perform an addmember to that resource, you would need to have some special encoding of the addmember function in the body of the POST. But this special encoding only works on resources that support that particular encoding for POST calls. So that would mean that for a client to use POST to perform addmember, it would need to know whether or not a resource already interprets POST in a certain way, and then would need to know the encoding in the body that would be understood by that resource as meaning "addmember". I may be missing something obvious here (and if so, I'm counting on Roy pointing it out :-), but if not, it seems that POST cannot be defined to perform any particular operation, since it already is being used by some resources to mean "perform the operation specified in the body". Cheers, Geoff Roy wrote on 02/17/2005 12:54:16 AM: > > On Feb 16, 2005, at 9:46 AM, Jim Whitehead wrote: > > RFC 2616 states: > > "The actual function performed by the POST method is determined by the > > server and is usually dependent on the Request-URI." > > > > From a client perspective this makes POST unreliable, and leads to the > > desire to define a new method. > > The action will either succeed or fail. If it succeeds, the client > will receive the exact same response from POST that it would have > received from a new method. If it fails, the client will receive > the same potential set of failure responses as it might have from > a new method. > > The only way you could claim that a new method would be more reliable > is if the client knows the exact implementation of the resource > being requested, which is something that a client does not know > with HTTP, and even if it did, it is far more likely that it will > know how the server and all intermediaries will respond to the > existing POST method than it could know about their response to > a new method that has zero deployment. > > ....Roy > > --=_alternative 0044E89E85256FAB_= Content-Type: text/html; charset="US-ASCII"
I believe the problem arises when you are trying to apply the
addmember function to a resource that already handles POST as meaning
"do the operation specifies in the body of the POST".
To use POST to perform an addmember to that resource, you would
need to have some special encoding of the addmember function in
the body of the POST.  But this special encoding only works on
resources that support that particular encoding for POST calls.
So that would mean that for a client to use POST to perform addmember,
it would need to know whether or not a resource already interprets
POST in a certain way, and then would need to know the encoding in
the body that would be understood by that resource as meaning "addmember".

I may be missing something obvious here (and if so, I'm counting on
Roy pointing it out :-), but if not, it seems that POST cannot be
defined to perform any particular operation, since it already is
being used by some resources to mean "perform the operation specified
in the body".

Cheers,
Geoff

Roy wrote on 02/17/2005 12:54:16 AM:
>
> On Feb 16, 2005, at 9:46 AM, Jim Whitehead wrote:
> > RFC 2616 states:
> > "The actual function performed by the POST method is determined by the
> > server and is usually dependent on the Request-URI."
> >
> > From a client perspective this makes POST unreliable, and leads to the
> > desire to define a new method.
>
> The action will either succeed or fail.  If it succeeds, the client
> will receive the exact same response from POST that it would have
> received from a new method.  If it fails, the client will receive
> the same potential set of failure responses as it might have from
> a new method.
>
> The only way you could claim that a new method would be more reliable
> is if the client knows the exact implementation of the resource
> being requested, which is something that a client does not know
> with HTTP, and even if it did, it is far more likely that it will
> know how the server and all intermediaries will respond to the
> existing POST method than it could know about their response to
> a new method that has zero deployment.
>
> ....Roy
>
>
--=_alternative 0044E89E85256FAB_=-- From w3c-dist-auth-request@w3.org Thu Feb 17 08:00:24 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17841 for ; Thu, 17 Feb 2005 08:00:24 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1lFl-0003ZN-LT for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Feb 2005 12:59:33 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D1lFl-0003Yo-D5 for w3c-dist-auth@listhub.w3.org; Thu, 17 Feb 2005 12:59:33 +0000 Received: from [217.5.201.10] (helo=greenbytes.de) by bart.w3.org with esmtp (Exim 4.34) id 1D1lFk-0003tA-TT for w3c-dist-auth@w3.org; Thu, 17 Feb 2005 12:59:33 +0000 Received: from [192.168.1.26] by greenbytes.de (Cipher TLSv1:RC4-MD5:128) (MDaemon.PRO.v7.2.3.R) with ESMTP id md50000083743.msg for ; Thu, 17 Feb 2005 13:58:48 +0100 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <2844d19383802290887bde5ef6e22e11@greenbytes.de> Content-Transfer-Encoding: quoted-printable From: Stefan Eissing Date: Thu, 17 Feb 2005 13:58:58 +0100 To: webdav X-Mailer: Apple Mail (2.619.2) X-Authenticated-Sender: se@greenbytes.de X-Spam-Processed: greenbytes.de, Thu, 17 Feb 2005 13:58:48 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.1.26 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Received-SPF: none (bart.w3.org: domain of stefan.eissing@greenbytes.de does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/2844d19383802290887bde5ef6e22e11@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9439 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 17 Feb 2005 12:59:33 +0000 Content-Transfer-Encoding: quoted-printable I think What Would Make The World A Better Place is a mechanism that=20 generic clients can discover POST service points where they can persist=20= new entities. There is nothing wrong with POST, it is just that a=20 client cannot discover if and where a server supports that feature. Atom solves this problem by embedding the POST service uri into the=20 feed document. That is fine, but a) has low reusablity for other protocols/applications b) has no usability from the view of a generic client I think this is what Julian tries to address with ADDMEMBER, since=20 this method will be visible in an OPTIONS response. Alternatively, an=20= OPTIONS reponse could carry an extra Header with the URI of such a POST=20= service. On second thought, this could also be nicely wrapped up inside a site=20 description and the pointer to the site could be a header in an OPTIONS=20= response. Then a small, extensible site description document (XML)=20 could do the job nicely. //Stefan Am 17.02.2005 um 13:32 schrieb Geoffrey M Clemm: > > I believe the problem arises when you are trying to apply the > addmember function to a resource that already handles POST as meaning > "do the operation specifies in the body of the POST". > To use POST to perform an addmember to that resource, you would > need to have some special encoding of the addmember function in > the body of the POST. =A0But this special encoding only works on > resources that support that particular encoding for POST calls. > So that would mean that for a client to use POST to perform addmember, > it would need to know whether or not a resource already interprets > POST in a certain way, and then would need to know the encoding in > the body that would be understood by that resource as meaning=20 > "addmember". > > I may be missing something obvious here (and if so, I'm counting on > Roy pointing it out :-), but if not, it seems that POST cannot be > defined to perform any particular operation, since it already is > being used by some resources to mean "perform the operation specified > in the body". > > Cheers, > Geoff > > Roy wrote on 02/17/2005 12:54:16 AM: > > > > On Feb 16, 2005, at 9:46 AM, Jim Whitehead wrote: > > > RFC 2616 states: > > > "The actual function performed by the POST method is determined=20= > by the > > > server and is usually dependent on the Request-URI." > > > > > > =46rom a client perspective this makes POST unreliable, and leads=20= > to the > > > desire to define a new method. > > > > The action will either succeed or fail. =A0If it succeeds, the = client > > will receive the exact same response from POST that it would have > > received from a new method. =A0If it fails, the client will receive > > the same potential set of failure responses as it might have from > > a new method. > > > > The only way you could claim that a new method would be more=20 > reliable > > is if the client knows the exact implementation of the resource > > being requested, which is something that a client does not know > > with HTTP, and even if it did, it is far more likely that it will > > know how the server and all intermediaries will respond to the > > existing POST method than it could know about their response to > > a new method that has zero deployment. > > > > ....Roy > > > > From w3c-dist-auth-request@w3.org Thu Feb 17 08:05:48 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18483 for ; Thu, 17 Feb 2005 08:05:47 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1lL3-0006SX-Tl for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Feb 2005 13:05:01 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D1lL3-0006Rp-LW for w3c-dist-auth@listhub.w3.org; Thu, 17 Feb 2005 13:05:01 +0000 Received: from e4.ny.us.ibm.com ([32.97.182.144]) by bart.w3.org with esmtp (Exim 4.34) id 1D1lL3-0004sj-FQ for w3c-dist-auth@w3.org; Thu, 17 Feb 2005 13:05:01 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j1HD4Tsr023642 for ; Thu, 17 Feb 2005 08:04:30 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1HD4Tji238676 for ; Thu, 17 Feb 2005 08:04:29 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1HD4TK1020562 for ; Thu, 17 Feb 2005 08:04:29 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1HD4T9S020553 for ; Thu, 17 Feb 2005 08:04:29 -0500 In-Reply-To: <2844d19383802290887bde5ef6e22e11@greenbytes.de> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Thu, 17 Feb 2005 08:04:34 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 02/17/2005 08:04:29, Serialize complete at 02/17/2005 08:04:29 Content-Type: multipart/alternative; boundary="=_alternative 0047D2B185256FAB_=" Received-SPF: pass (bart.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.144 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/OFBAA6B9D4.E32BED1E-ON85256FAB.00478A57-85256FAB.0047D2B5@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9440 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 17 Feb 2005 13:05:01 +0000 This is a multipart message in MIME format. --=_alternative 0047D2B185256FAB_= Content-Type: text/plain; charset="US-ASCII" Stefan: How does your proposal below address the problem of performing an addmember function against a resource that already interprets POST as meaning "execute the function specified in some special format in the body of this POST call". You don't want to have to introduce a new resource just to perform an addmember function against that resource. Cheers, Geoff Stefan wrote on 02/17/2005 07:58:58 AM: > > I think What Would Make The World A Better Place is a mechanism that > generic clients can discover POST service points where they can persist > new entities. There is nothing wrong with POST, it is just that a > client cannot discover if and where a server supports that feature. > > Atom solves this problem by embedding the POST service uri into the > feed document. That is fine, but > a) has low reusablity for other protocols/applications > b) has no usability from the view of a generic client > > I think this is what Julian tries to address with ADDMEMBER, since > this method will be visible in an OPTIONS response. Alternatively, an > OPTIONS reponse could carry an extra Header with the URI of such a POST > service. > > On second thought, this could also be nicely wrapped up inside a site > description and the pointer to the site could be a header in an OPTIONS > response. Then a small, extensible site description document (XML) > could do the job nicely. > > //Stefan > > Am 17.02.2005 um 13:32 schrieb Geoffrey M Clemm: > > > > > I believe the problem arises when you are trying to apply the > > addmember function to a resource that already handles POST as meaning > > "do the operation specifies in the body of the POST". > > To use POST to perform an addmember to that resource, you would > > need to have some special encoding of the addmember function in > > the body of the POST. But this special encoding only works on > > resources that support that particular encoding for POST calls. > > So that would mean that for a client to use POST to perform addmember, > > it would need to know whether or not a resource already interprets > > POST in a certain way, and then would need to know the encoding in > > the body that would be understood by that resource as meaning > > "addmember". > > > > I may be missing something obvious here (and if so, I'm counting on > > Roy pointing it out :-), but if not, it seems that POST cannot be > > defined to perform any particular operation, since it already is > > being used by some resources to mean "perform the operation specified > > in the body". > > > > Cheers, > > Geoff > > > > Roy wrote on 02/17/2005 12:54:16 AM: > > > > > > On Feb 16, 2005, at 9:46 AM, Jim Whitehead wrote: > > > > RFC 2616 states: > > > > "The actual function performed by the POST method is determined > > by the > > > > server and is usually dependent on the Request-URI." > > > > > > > > From a client perspective this makes POST unreliable, and leads > > to the > > > > desire to define a new method. > > > > > > The action will either succeed or fail. If it succeeds, the client > > > will receive the exact same response from POST that it would have > > > received from a new method. If it fails, the client will receive > > > the same potential set of failure responses as it might have from > > > a new method. > > > > > > The only way you could claim that a new method would be more > > reliable > > > is if the client knows the exact implementation of the resource > > > being requested, which is something that a client does not know > > > with HTTP, and even if it did, it is far more likely that it will > > > know how the server and all intermediaries will respond to the > > > existing POST method than it could know about their response to > > > a new method that has zero deployment. > > > > > > ....Roy > > > > > > > > > --=_alternative 0047D2B185256FAB_= Content-Type: text/html; charset="US-ASCII"
Stefan: How does your proposal below address the problem of performing
an addmember function against a resource that already interprets POST
as meaning "execute the function specified in some special format in
the body of this POST call".  You don't want to have to introduce a new
resource just to perform an addmember function against that resource.

Cheers,
Geoff

Stefan wrote on 02/17/2005 07:58:58 AM:
>
> I think What Would Make The World A Better Place is a mechanism that
> generic clients can discover POST service points where they can persist
> new entities. There is nothing wrong with POST, it is just that a
> client cannot discover if and where a server supports that feature.
>
> Atom solves this problem by embedding the POST service uri into the
> feed document. That is fine, but
> a) has low reusablity for other protocols/applications
> b) has no usability from the view of a generic client
>
>   I think this is what Julian tries to address with ADDMEMBER, since
> this method will  be visible in an OPTIONS response. Alternatively, an
> OPTIONS reponse could carry an extra Header with the URI of such a POST
> service.
>
> On second thought, this could also be nicely wrapped up inside a site
> description and the pointer to the site could be a header in an OPTIONS
> response. Then a small, extensible site description document (XML)
> could do the job nicely.
>
> //Stefan
>
> Am 17.02.2005 um 13:32 schrieb Geoffrey M Clemm:
>
> >
> > I believe the problem arises when you are trying to apply the
> > addmember function to a resource that already handles POST as meaning
> > "do the operation specifies in the body of the POST".
> > To use POST to perform an addmember to that resource, you would
> > need to have some special encoding of the addmember function in
> > the body of the POST.  But this special encoding only works on
> > resources that support that particular encoding for POST calls.
> > So that would mean that for a client to use POST to perform addmember,
> > it would need to know whether or not a resource already interprets
> > POST in a certain way, and then would need to know the encoding in
> > the body that would be understood by that resource as meaning
> > "addmember".
> >
> > I may be missing something obvious here (and if so, I'm counting on
> > Roy pointing it out :-), but if not, it seems that POST cannot be
> > defined to perform any particular operation, since it already is
> > being used by some resources to mean "perform the operation specified
> > in the body".
> >
> > Cheers,
> > Geoff
> >
> > Roy wrote on 02/17/2005 12:54:16 AM:
> >  >
> >  > On Feb 16, 2005, at 9:46 AM, Jim Whitehead wrote:
> >  > > RFC 2616 states:
> >  > > "The actual function performed by the POST method is determined
> > by the
> >  > > server and is usually dependent on the Request-URI."
> >  > >
> >  > > From a client perspective this makes POST unreliable, and leads
> > to the
> >  > > desire to define a new method.
> >  >
> >  > The action will either succeed or fail.  If it succeeds, the client
> >  > will receive the exact same response from POST that it would have
> >  > received from a new method.  If it fails, the client will receive
> >  > the same potential set of failure responses as it might have from
> >  > a new method.
> >  >
> >  > The only way you could claim that a new method would be more
> > reliable
> >  > is if the client knows the exact implementation of the resource
> >  > being requested, which is something that a client does not know
> >  > with HTTP, and even if it did, it is far more likely that it will
> >  > know how the server and all intermediaries will respond to the
> >  > existing POST method than it could know about their response to
> >  > a new method that has zero deployment.
> >  >
> >  > ....Roy
> >  >
> >  >
>
>
>
--=_alternative 0047D2B185256FAB_=-- From w3c-dist-auth-request@w3.org Thu Feb 17 08:26:28 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20665 for ; Thu, 17 Feb 2005 08:26:28 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1lew-0007E0-8A for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Feb 2005 13:25:34 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D1lev-0007DW-II for w3c-dist-auth@listhub.w3.org; Thu, 17 Feb 2005 13:25:33 +0000 Received: from [217.5.201.10] (helo=greenbytes.de) by bart.w3.org with esmtp (Exim 4.34) id 1D1leu-0000di-VH for w3c-dist-auth@w3.org; Thu, 17 Feb 2005 13:25:33 +0000 Received: from [192.168.1.26] by greenbytes.de (Cipher TLSv1:RC4-MD5:128) (MDaemon.PRO.v7.2.3.R) with ESMTP id md50000083758.msg for ; Thu, 17 Feb 2005 14:24:58 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <8d7ef5836e41c608cd40f298dd6b6d3a@greenbytes.de> Content-Transfer-Encoding: quoted-printable Cc: " webdav" From: Stefan Eissing Date: Thu, 17 Feb 2005 14:25:05 +0100 To: Geoffrey M Clemm X-Mailer: Apple Mail (2.619.2) X-Authenticated-Sender: se@greenbytes.de X-Spam-Processed: greenbytes.de, Thu, 17 Feb 2005 14:24:58 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.1.26 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Received-SPF: none (bart.w3.org: domain of stefan.eissing@greenbytes.de does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/8d7ef5836e41c608cd40f298dd6b6d3a@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9441 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 17 Feb 2005 13:25:34 +0000 Content-Transfer-Encoding: quoted-printable Geoff, i do not see a problem with introducing a new URI should the server=20 wish to support POST for other purposes. Example: http://example.com/collection/ supports POST for other purposes, then one solution is that OPTIONS /collection/ HTTP/1.1 Host: example.com HTTP/1.1 200 Ok Allow: GET, HEAD, OPTIONS, POST WhatEverTheHeaderName: http://example.com/collection/?function=3DAddMember= Of course, in the case of embedding the Post service URI in a site=20 description, there would be one URI for all resources belonging to that=20= site and the client is not able to control in which collection the=20 resource will appear. But I do not see that as an issue... I see beauty in describing such functions inside a site description=20 resource. It is cacheable again, it can habe ETags, it can be target of=20= conditional retrieval and it can even be authorable via WebDAV should=20 some crazy people want to do that. //Stefan Am 17.02.2005 um 14:04 schrieb Geoffrey M Clemm: > > Stefan: How does your proposal below address the problem of performing > an addmember function against a resource that already interprets POST > as meaning "execute the function specified in some special format in > the body of this POST call". =A0You don't want to have to introduce a = new > resource just to perform an addmember function against that resource. > > Cheers, > Geoff > > Stefan wrote on 02/17/2005 07:58:58 AM: > > > > I think What Would Make The World A Better Place is a mechanism = that > > generic clients can discover POST service points where they can=20 > persist > > new entities. There is nothing wrong with POST, it is just that a > > client cannot discover if and where a server supports that feature. > > > > Atom solves this problem by embedding the POST service uri into the > > feed document. That is fine, but > > a) has low reusablity for other protocols/applications > > b) has no usability from the view of a generic client > > > > =A0 I think this is what Julian tries to address with ADDMEMBER, = since > > this method will =A0be visible in an OPTIONS response. = Alternatively,=20 > an > > OPTIONS reponse could carry an extra Header with the URI of such a=20= > POST > > service. > > > > On second thought, this could also be nicely wrapped up inside a=20 > site > > description and the pointer to the site could be a header in an=20 > OPTIONS > > response. Then a small, extensible site description document (XML) > > could do the job nicely. > > > > //Stefan > > > > Am 17.02.2005 um 13:32 schrieb Geoffrey M Clemm: > > > > > > > > I believe the problem arises when you are trying to apply the > > > addmember function to a resource that already handles POST as=20 > meaning > > > "do the operation specifies in the body of the POST". > > > To use POST to perform an addmember to that resource, you would > > > need to have some special encoding of the addmember function in > > > the body of the POST. =A0But this special encoding only works on > > > resources that support that particular encoding for POST calls. > > > So that would mean that for a client to use POST to perform=20 > addmember, > > > it would need to know whether or not a resource already = interprets > > > POST in a certain way, and then would need to know the encoding = in > > > the body that would be understood by that resource as meaning > > > "addmember". > > > > > > I may be missing something obvious here (and if so, I'm counting=20= > on > > > Roy pointing it out :-), but if not, it seems that POST cannot be > > > defined to perform any particular operation, since it already is > > > being used by some resources to mean "perform the operation=20 > specified > > > in the body". > > > > > > Cheers, > > > Geoff > > > > > > Roy wrote on 02/17/2005 12:54:16 AM: > > > =A0> > > > =A0> On Feb 16, 2005, at 9:46 AM, Jim Whitehead wrote: > > > =A0> > RFC 2616 states: > > > =A0> > "The actual function performed by the POST method is=20 > determined > > > by the > > > =A0> > server and is usually dependent on the Request-URI." > > > =A0> > > > > =A0> > =46rom a client perspective this makes POST unreliable, = and=20 > leads > > > to the > > > =A0> > desire to define a new method. > > > =A0> > > > =A0> The action will either succeed or fail. =A0If it succeeds, = the=20 > client > > > =A0> will receive the exact same response from POST that it would=20= > have > > > =A0> received from a new method. =A0If it fails, the client will=20= > receive > > > =A0> the same potential set of failure responses as it might have=20= > from > > > =A0> a new method. > > > =A0> > > > =A0> The only way you could claim that a new method would be more > > > reliable > > > =A0> is if the client knows the exact implementation of the = resource > > > =A0> being requested, which is something that a client does not = know > > > =A0> with HTTP, and even if it did, it is far more likely that it=20= > will > > > =A0> know how the server and all intermediaries will respond to = the > > > =A0> existing POST method than it could know about their response = to > > > =A0> a new method that has zero deployment. > > > =A0> > > > =A0> ....Roy > > > =A0> > > > =A0> > > > > > > From w3c-dist-auth-request@w3.org Thu Feb 17 08:56:26 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24716 for ; Thu, 17 Feb 2005 08:56:26 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1m7m-0003gI-Km for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Feb 2005 13:55:22 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D1m7l-0003fa-Va for w3c-dist-auth@listhub.w3.org; Thu, 17 Feb 2005 13:55:21 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1D1m7l-0005D4-KP for w3c-dist-auth@w3.org; Thu, 17 Feb 2005 13:55:21 +0000 Received: (qmail invoked by alias); 17 Feb 2005 13:54:47 -0000 Received: from p508243CD.dip0.t-ipconnect.de (EHLO [192.168.1.87]) (80.130.67.205) by mail.gmx.net (mp001) with SMTP; 17 Feb 2005 14:54:47 +0100 X-Authenticated: #1915285 Message-ID: <4214A21E.5070804@gmx.de> Date: Thu, 17 Feb 2005 14:54:38 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Roy T. Fielding" CC: Mark Baker , HTTP Working Group , CalDAV DevList , WebDAV References: <4211E442.40209@gmx.de> <27514C16D36854827D284790@ninevah.cyrusoft.com> <42121E4A.3080007@gmx.de> <62F35864CD746B25C06E1A19@ninevah.cyrusoft.com> <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> In-Reply-To: <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/4214A21E.5070804@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9442 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 17 Feb 2005 13:55:22 +0000 Content-Transfer-Encoding: 7bit Roy T. Fielding wrote: > POST is always an attempt to store state. It is the response that > tells you whether the state has been stored. No POST can be > interpreted by intermediaries, just as no "ADDMEMBER" can either. > The system gains nothing from adding a new method. It might have > gained something by not allowing HTML forms to use POST for safe > actions, but that debate ended years ago. Creating new unsafe > actions that do the same as what POST has already been defined > to do is absurd. Well, ADDMEMBER does not do the same thing. It's specced to do *one* very specific thing, while POST basically allows the server to do anything it likes. >> Had HTTP a means for extending a method to declare this additional >> expectation (as described in the draft's A.3 using RFC 2774), I agree >> that POST + extension would be appropriate. > > > It doesn't because it never needed it. OK, let's step back and look at the situation that caused me to make this proposal. Two separate communities (CalDAV/GroupDav and Atompub) encountered the same issue: what's the best way to create a new resource on an HTTP server when I can't use PUT as the URI space may be entirely server-controlled? 1) CalDav's approach is: use PUT to an arbitrary member URI of the container; then let the server automagically move it somewhere else, and report that in the Location response header (). 2) Atom's approach is to use service URIs to which the client can POST, and to discover these service URIs by parting entity (feed) bodies. Somehow I have the (perhaps naive) wish that identical requirements should lead to common protocol constructs. 1) Seems to break PUT semantics; 2) Is specific to Atom and not applicable to other protocols. > ... > The media type is not limited in HTTP and it is not equivalent > to data format. The media type tells the recipient how to process > the message given the method semantics. That is why sending the > same data as "text/html" is functionally different from sending it > as "text/plain" -- the two messages have different semantics. > > That will hold for anything compliant with HTTP/1.1. So what would be your recommendation to the authors of CalDav and the Atom Publishing Protocol? What's the best way to add a new member to a container (storing the entity just like PUT, but letting the server decide on the URI)? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Feb 17 09:04:54 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25626 for ; Thu, 17 Feb 2005 09:04:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1mGG-00076t-Nd for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Feb 2005 14:04:08 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D1mGG-00076P-Fk for w3c-dist-auth@listhub.w3.org; Thu, 17 Feb 2005 14:04:08 +0000 Received: from e3.ny.us.ibm.com ([32.97.182.143]) by lisa.w3.org with esmtp (Exim 4.34) id 1D1mGG-0004fQ-8v for w3c-dist-auth@w3.org; Thu, 17 Feb 2005 14:04:08 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j1HE3bpE032233 for ; Thu, 17 Feb 2005 09:03:37 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1HE3b3x217890 for ; Thu, 17 Feb 2005 09:03:37 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1HE3bs2031660 for ; Thu, 17 Feb 2005 09:03:37 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1HE3bJe031656 for ; Thu, 17 Feb 2005 09:03:37 -0500 In-Reply-To: <8d7ef5836e41c608cd40f298dd6b6d3a@greenbytes.de> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Thu, 17 Feb 2005 09:03:45 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 02/17/2005 09:03:36, Serialize complete at 02/17/2005 09:03:36 Content-Type: multipart/alternative; boundary="=_alternative 004D3E1085256FAB_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.143 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/OF7ABB1CC5.74319D51-ON85256FAB.004BD9BA-85256FAB.004D3E11@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9443 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 17 Feb 2005 14:04:08 +0000 This is a multipart message in MIME format. --=_alternative 004D3E1085256FAB_= Content-Type: text/plain; charset="US-ASCII" The benefit of using a new method name to define a new method is that you can re-use all of the existing machinery (both syntactic and semantic) that keys off of the method name. Although SOAP has gone down the "embed the method name in the body of the POST" approach, WebDAV has taken the "use the method name as the method name" approach. If you use some other technique (such as embedding the method name in the request-URI), you need to re-invent new machinery to do all the same things that the existing machinery does with method names. Cheers, Geoff Stefan Eissing wrote on 02/17/2005 08:25:05 AM: > Geoff, > > i do not see a problem with introducing a new URI should the server > wish to support POST for other purposes. Example: > > http://example.com/collection/ > > supports POST for other purposes, then one solution is that > > OPTIONS /collection/ HTTP/1.1 > Host: example.com > > HTTP/1.1 200 Ok > Allow: GET, HEAD, OPTIONS, POST > WhatEverTheHeaderName: http://example.com/collection/?function=AddMember > > Of course, in the case of embedding the Post service URI in a site > description, there would be one URI for all resources belonging to that > site and the client is not able to control in which collection the > resource will appear. But I do not see that as an issue... > > I see beauty in describing such functions inside a site description > resource. It is cacheable again, it can habe ETags, it can be target of > conditional retrieval and it can even be authorable via WebDAV should > some crazy people want to do that. > > //Stefan > > Am 17.02.2005 um 14:04 schrieb Geoffrey M Clemm: > > > > > Stefan: How does your proposal below address the problem of performing > > an addmember function against a resource that already interprets POST > > as meaning "execute the function specified in some special format in > > the body of this POST call". You don't want to have to introduce a new > > resource just to perform an addmember function against that resource. > > > > Cheers, > > Geoff > > > > Stefan wrote on 02/17/2005 07:58:58 AM: > > > > > > I think What Would Make The World A Better Place is a mechanism that > > > generic clients can discover POST service points where they can > > persist > > > new entities. There is nothing wrong with POST, it is just that a > > > client cannot discover if and where a server supports that feature. > > > > > > Atom solves this problem by embedding the POST service uri into the > > > feed document. That is fine, but > > > a) has low reusablity for other protocols/applications > > > b) has no usability from the view of a generic client > > > > > > I think this is what Julian tries to address with ADDMEMBER, since > > > this method will be visible in an OPTIONS response. Alternatively, > > an > > > OPTIONS reponse could carry an extra Header with the URI of such a > > POST > > > service. > > > > > > On second thought, this could also be nicely wrapped up inside a > > site > > > description and the pointer to the site could be a header in an > > OPTIONS > > > response. Then a small, extensible site description document (XML) > > > could do the job nicely. > > > > > > //Stefan > > > > > > Am 17.02.2005 um 13:32 schrieb Geoffrey M Clemm: > > > > > > > > > > > I believe the problem arises when you are trying to apply the > > > > addmember function to a resource that already handles POST as > > meaning > > > > "do the operation specifies in the body of the POST". > > > > To use POST to perform an addmember to that resource, you would > > > > need to have some special encoding of the addmember function in > > > > the body of the POST. But this special encoding only works on > > > > resources that support that particular encoding for POST calls. > > > > So that would mean that for a client to use POST to perform > > addmember, > > > > it would need to know whether or not a resource already interprets > > > > POST in a certain way, and then would need to know the encoding in > > > > the body that would be understood by that resource as meaning > > > > "addmember". > > > > > > > > I may be missing something obvious here (and if so, I'm counting > > on > > > > Roy pointing it out :-), but if not, it seems that POST cannot be > > > > defined to perform any particular operation, since it already is > > > > being used by some resources to mean "perform the operation > > specified > > > > in the body". > > > > > > > > Cheers, > > > > Geoff > > > > > > > > Roy wrote on 02/17/2005 12:54:16 AM: > > > > > > > > > > On Feb 16, 2005, at 9:46 AM, Jim Whitehead wrote: > > > > > > RFC 2616 states: > > > > > > "The actual function performed by the POST method is > > determined > > > > by the > > > > > > server and is usually dependent on the Request-URI." > > > > > > > > > > > > From a client perspective this makes POST unreliable, and > > leads > > > > to the > > > > > > desire to define a new method. > > > > > > > > > > The action will either succeed or fail. If it succeeds, the > > client > > > > > will receive the exact same response from POST that it would > > have > > > > > received from a new method. If it fails, the client will > > receive > > > > > the same potential set of failure responses as it might have > > from > > > > > a new method. > > > > > > > > > > The only way you could claim that a new method would be more > > > > reliable > > > > > is if the client knows the exact implementation of the resource > > > > > being requested, which is something that a client does not know > > > > > with HTTP, and even if it did, it is far more likely that it > > will > > > > > know how the server and all intermediaries will respond to the > > > > > existing POST method than it could know about their response to > > > > > a new method that has zero deployment. > > > > > > > > > > ....Roy > > > > > > > > > > > > > > > > > > > > > --=_alternative 004D3E1085256FAB_= Content-Type: text/html; charset="US-ASCII"
The benefit of using a new method name to define a new method is that you
can re-use all of the existing machinery (both syntactic and semantic) that
keys off of the method name.  

Although SOAP has gone down the "embed the method name in the body of the POST"
approach, WebDAV has taken the "use the method name as the method name" approach.

If you use some other technique (such as embedding the method name in the
request-URI), you need to re-invent new machinery to do all the same things
that the existing machinery does with method names.

Cheers,
Geoff


Stefan Eissing <stefan.eissing@greenbytes.de> wrote on 02/17/2005 08:25:05 AM:

> Geoff,
>
> i do not see a problem with introducing a new URI should the server
> wish to support POST for other purposes. Example:
>
> http://example.com/collection/
>
> supports POST for other purposes, then one solution is that
>
> OPTIONS /collection/ HTTP/1.1
> Host: example.com
>
> HTTP/1.1 200 Ok
> Allow: GET, HEAD, OPTIONS, POST
> WhatEverTheHeaderName: http://example.com/collection/?function=AddMember
>
> Of course, in the case of embedding the Post service URI in a site
> description, there would be one URI for all resources belonging to that
> site and the client is not able to control in which collection the
> resource will appear. But I do not see that as an issue...
>
> I see beauty in describing such functions inside a site description
> resource. It is cacheable again, it can habe ETags, it can be target of
> conditional retrieval and it can even be authorable via WebDAV should
> some crazy people want to do that.
>
> //Stefan
>
> Am 17.02.2005 um 14:04 schrieb Geoffrey M Clemm:
>
> >
> > Stefan: How does your proposal below address the problem of performing
> > an addmember function against a resource that already interprets POST
> > as meaning "execute the function specified in some special format in
> > the body of this POST call".  You don't want to have to introduce a new
> > resource just to perform an addmember function against that resource.
> >
> > Cheers,
> >  Geoff
> >
> > Stefan wrote on 02/17/2005 07:58:58 AM:
> >  >
> >  > I think What Would Make The World A Better Place is a mechanism that
> >  > generic clients can discover POST service points where they can
> > persist
> >  > new entities. There is nothing wrong with POST, it is just that a
> >  > client cannot discover if and where a server supports that feature.
> >  >
> >  > Atom solves this problem by embedding the POST service uri into the
> >  > feed document. That is fine, but
> >  > a) has low reusablity for other protocols/applications
> >  > b) has no usability from the view of a generic client
> >  >
> >  >   I think this is what Julian tries to address with ADDMEMBER, since
> >  > this method will  be visible in an OPTIONS response. Alternatively,
> > an
> >  > OPTIONS reponse could carry an extra Header with the URI of such a
> > POST
> >  > service.
> >  >
> >  > On second thought, this could also be nicely wrapped up inside a
> > site
> >  > description and the pointer to the site could be a header in an
> > OPTIONS
> >  > response. Then a small, extensible site description document (XML)
> >  > could do the job nicely.
> >  >
> >  > //Stefan
> >  >
> >  > Am 17.02.2005 um 13:32 schrieb Geoffrey M Clemm:
> >  >
> >  > >
> >  > > I believe the problem arises when you are trying to apply the
> >  > > addmember function to a resource that already handles POST as
> > meaning
> >  > > "do the operation specifies in the body of the POST".
> >  > > To use POST to perform an addmember to that resource, you would
> >  > > need to have some special encoding of the addmember function in
> >  > > the body of the POST.  But this special encoding only works on
> >  > > resources that support that particular encoding for POST calls.
> >  > > So that would mean that for a client to use POST to perform
> > addmember,
> >  > > it would need to know whether or not a resource already interprets
> >  > > POST in a certain way, and then would need to know the encoding in
> >  > > the body that would be understood by that resource as meaning
> >  > > "addmember".
> >  > >
> >  > > I may be missing something obvious here (and if so, I'm counting
> > on
> >  > > Roy pointing it out :-), but if not, it seems that POST cannot be
> >  > > defined to perform any particular operation, since it already is
> >  > > being used by some resources to mean "perform the operation
> > specified
> >  > > in the body".
> >  > >
> >  > > Cheers,
> >  > > Geoff
> >  > >
> >  > > Roy wrote on 02/17/2005 12:54:16 AM:
> >  > >  >
> >  > >  > On Feb 16, 2005, at 9:46 AM, Jim Whitehead wrote:
> >  > >  > > RFC 2616 states:
> >  > >  > > "The actual function performed by the POST method is
> > determined
> >  > > by the
> >  > >  > > server and is usually dependent on the Request-URI."
> >  > >  > >
> >  > >  > > From a client perspective this makes POST unreliable, and
> > leads
> >  > > to the
> >  > >  > > desire to define a new method.
> >  > >  >
> >  > >  > The action will either succeed or fail.  If it succeeds, the
> > client
> >  > >  > will receive the exact same response from POST that it would
> > have
> >  > >  > received from a new method.  If it fails, the client will
> > receive
> >  > >  > the same potential set of failure responses as it might have
> > from
> >  > >  > a new method.
> >  > >  >
> >  > >  > The only way you could claim that a new method would be more
> >  > > reliable
> >  > >  > is if the client knows the exact implementation of the resource
> >  > >  > being requested, which is something that a client does not know
> >  > >  > with HTTP, and even if it did, it is far more likely that it
> > will
> >  > >  > know how the server and all intermediaries will respond to the
> >  > >  > existing POST method than it could know about their response to
> >  > >  > a new method that has zero deployment.
> >  > >  >
> >  > >  > ....Roy
> >  > >  >
> >  > >  >
> >  >
> >  >
> >  >
>
>
--=_alternative 004D3E1085256FAB_=-- From w3c-dist-auth-request@w3.org Thu Feb 17 09:47:03 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00327 for ; Thu, 17 Feb 2005 09:47:02 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1muu-0002O2-Dh for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Feb 2005 14:46:08 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D1mut-0002NL-OT for w3c-dist-auth@listhub.w3.org; Thu, 17 Feb 2005 14:46:07 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1D1mut-0003j2-D3 for w3c-dist-auth@w3.org; Thu, 17 Feb 2005 14:46:07 +0000 Received: (qmail invoked by alias); 17 Feb 2005 14:45:35 -0000 Received: from p508243CD.dip0.t-ipconnect.de (EHLO [192.168.1.87]) (80.130.67.205) by mail.gmx.net (mp006) with SMTP; 17 Feb 2005 15:45:35 +0100 X-Authenticated: #1915285 Message-ID: <4214AE0E.4080202@gmx.de> Date: Thu, 17 Feb 2005 15:45:34 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jamie Lokier CC: "Roy T. Fielding" , Mark Baker , HTTP Working Group , CalDAV DevList , WebDAV References: <42121E4A.3080007@gmx.de> <62F35864CD746B25C06E1A19@ninevah.cyrusoft.com> <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> <20050217143606.GA14754@mail.shareable.org> In-Reply-To: <20050217143606.GA14754@mail.shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/4214AE0E.4080202@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9444 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 17 Feb 2005 14:46:08 +0000 Content-Transfer-Encoding: 7bit Jamie Lokier wrote: > Julian Reschke wrote: > >>2) Atom's approach is to use service URIs to which the client can POST, >>and to discover these service URIs by parting entity (feed) bodies. > > ... > >>2) Is specific to Atom and not applicable to other protocols. > > > ADDMEMBER is no different from POST in this respect: > > You still have to "discover the service URI" to use with ADDMEMBER. No, it would be the container resource itself. For CalDav, the calendar collection; for Atompub, the feed resource itself. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Feb 17 09:58:24 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01556 for ; Thu, 17 Feb 2005 09:58:24 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1n5p-0000Ah-0U for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Feb 2005 14:57:25 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D1n5o-0000AD-OR for w3c-dist-auth@listhub.w3.org; Thu, 17 Feb 2005 14:57:24 +0000 Received: from sophia.inria.fr ([138.96.64.20]) by bart.w3.org with esmtp (Exim 4.34) id 1D1n5o-0000HD-DI for w3c-dist-auth@w3.org; Thu, 17 Feb 2005 14:57:24 +0000 Received: from localhost (localhost [127.0.0.1]) by sophia.inria.fr (8.12.10/8.12.9) with ESMTP id j1HEuj18021818; Thu, 17 Feb 2005 15:56:45 +0100 Received: from tarantula.inria.fr (tarantula.inria.fr [138.96.10.3]) by sophia.inria.fr (8.12.10/8.12.9) with ESMTP id j1HEtohh021537; Thu, 17 Feb 2005 15:55:50 +0100 Received: (from ylafon@localhost) by tarantula.inria.fr (8.12.10/8.12.5) id j1HEtnSj003795; Thu, 17 Feb 2005 15:55:49 +0100 (MET) Date: Thu, 17 Feb 2005 15:55:48 +0100 (MET) From: Yves Lafon X-X-Sender: ylafon@tarantula.inria.fr To: Geoffrey M Clemm cc: webdav In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-959030623-1108652148=:3731" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (sophia.inria.fr [138.96.64.20]); Thu, 17 Feb 2005 15:55:50 +0100 (MET) X-Virus-Scanned: by amavisd-new at sophia.inria.fr Received-SPF: none (bart.w3.org: domain of Yves.Lafon@sophia.inria.fr does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/Pine.GSO.4.62.0502171553040.3731@gnenaghyn.vaevn.se Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9445 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 17 Feb 2005 14:57:25 +0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-959030623-1108652148=:3731 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 17 Feb 2005, Geoffrey M Clemm wrote: > Although SOAP has gone down the "embed the method name in the body of=20 > the POST" approach, WebDAV has taken the "use the method name as the=20 > method name" approach. That is not true. In SOAP, you may stuff everything in the SOAP envelope,= =20 or use the request URI of the underlying protocol in use to identify what= =20 will be done with this SOAP envelope. --=20 Yves Lafon - W3C "Baroula que barouleras, au ti=E9u toujou t'entourneras." ---559023410-959030623-1108652148=:3731-- From w3c-dist-auth-request@w3.org Thu Feb 17 10:58:44 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10260 for ; Thu, 17 Feb 2005 10:58:44 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1o23-0003DF-HJ for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Feb 2005 15:57:35 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D1o22-0003Ce-8g for w3c-dist-auth@listhub.w3.org; Thu, 17 Feb 2005 15:57:34 +0000 Received: from server3a.software-ag.de ([193.26.193.83]) by lisa.w3.org with esmtp (Exim 4.34) id 1D1o21-00007J-V9 for w3c-dist-auth@w3.org; Thu, 17 Feb 2005 15:57:34 +0000 Received: from server3a.software-ag.de (localhost [127.0.0.1]) by localhost.software-ag.de (Postfix) with ESMTP id 630AA5371C for ; Thu, 17 Feb 2005 16:57:02 +0100 (CET) Received: from DAEMSG03.eur.ad.sag (daemsg03a.eur.ad.sag [10.20.160.61]) by server3a.software-ag.de (Postfix) with ESMTP id 4E28B55890 for ; Thu, 17 Feb 2005 16:57:02 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Feb 2005 16:57:02 +0100 Message-ID: <4A56A7900065A44BB559A2C929597BB74264BD@DAEMSG03.eur.ad.sag> Thread-Topic: Question about DAV:getlastmodified property Thread-Index: AcUVCVG/F2wBMzteQiK92bT7y8Hv9Q== From: To: Received-SPF: none (lisa.w3.org: domain of Heiko.Weber@softwareag.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Question about DAV:getlastmodified property X-Archived-At: http://www.w3.org/mid/4A56A7900065A44BB559A2C929597BB74264BD@DAEMSG03.eur.ad.sag Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9446 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 17 Feb 2005 15:57:35 +0000 Content-Transfer-Encoding: quoted-printable Hello everyone, I have a question about the value of the DAV:getlastmodified property. If I have a WebDAV server which uses an underlying file system, then the values of that property are pretty much given by that system. If however I have a WebDAV server which implements the resources itself, is there some recommendation what the DAV:getlastmodified should reflect? Changes to the contents of a resource obviously will affect the modification date, but which properties do also do that? A rename on Linux for example will not change the modification date. Should a PROPPATCH on DAV:displayname also not change the modification date of a resource? What about acquiring a LOCK or setting ACLs on a resource? Has anybody created a list of properties which should lead to an update of the modification date, if they are changed? Should changes to dead properties always lead to a change in the modification date? regards, Heiko Weber =3D=3D=3D Software AG Tamino Development From w3c-dist-auth-request@w3.org Thu Feb 17 11:05:39 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11712 for ; Thu, 17 Feb 2005 11:05:39 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1o92-00084M-Pt for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Feb 2005 16:04:48 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D1o92-00083r-H6 for w3c-dist-auth@listhub.w3.org; Thu, 17 Feb 2005 16:04:48 +0000 Received: from [217.5.201.10] (helo=greenbytes.de) by bart.w3.org with esmtp (Exim 4.34) id 1D1o91-00046N-P5 for w3c-dist-auth@w3.org; Thu, 17 Feb 2005 16:04:48 +0000 Received: from [192.168.1.26] by greenbytes.de (Cipher TLSv1:RC4-MD5:128) (MDaemon.PRO.v7.2.3.R) with ESMTP id md50000083818.msg for ; Thu, 17 Feb 2005 17:04:14 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <5809f18d42c69d9c0e534dfb2ebcafbe@greenbytes.de> Content-Transfer-Encoding: quoted-printable Cc: " webdav" From: Stefan Eissing Date: Thu, 17 Feb 2005 17:04:24 +0100 To: Geoffrey M Clemm X-Mailer: Apple Mail (2.619.2) X-Authenticated-Sender: se@greenbytes.de X-Spam-Processed: greenbytes.de, Thu, 17 Feb 2005 17:04:14 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.1.26 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Received-SPF: none (bart.w3.org: domain of stefan.eissing@greenbytes.de does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/5809f18d42c69d9c0e534dfb2ebcafbe@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9447 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 17 Feb 2005 16:04:48 +0000 Content-Transfer-Encoding: quoted-printable Geoff, it is certainly true that WebDAV has introduced new methods for almost=20= everything. I sometimes feel however that reusing existing methods in=20 some cases would have its benefits. A GETtable PROPFIND multistatus is=20= one of them (with last-modified and etags maybe, yummy!). In order to stamp out any meta discussion and can openers: the=20 discussion about ADDMEMBER and POST seems to hint the POST was intended=20= to do what ADDMEMBER addresses. The only thing that is missing is the=20 auto discovery feature. That's why I injected my proposal here. As with any architecture, you can build around small set of primitives=20= or make lots of specifics. Finding the optimal balance is the fun=20 thing. You cannot say: as we went that way in the past, it will only=20 get better when we continue in that direction. Its not a linear=20 topology or else software could easily optimize it for us... //Stefan Am 17.02.2005 um 15:03 schrieb Geoffrey M Clemm: > > The benefit of using a new method name to define a new method is that=20= > you > can re-use all of the existing machinery (both syntactic and semantic)=20= > that > keys off of the method name. =A0 > > Although SOAP has gone down the "embed the method name in the body of=20= > the POST" > approach, WebDAV has taken the "use the method name as the method=20 > name" approach. > > If you use some other technique (such as embedding the method name in=20= > the > request-URI), you need to re-invent new machinery to do all the same=20= > things > that the existing machinery does with method names. > > Cheers, > Geoff > > > Stefan Eissing wrote on 02/17/2005=20 > 08:25:05 AM: > > > Geoff, > > > > i do not see a problem with introducing a new URI should the server > > wish to support POST for other purposes. Example: > > > > http://example.com/collection/ > > > > supports POST for other purposes, then one solution is that > > > > OPTIONS /collection/ HTTP/1.1 > > Host: example.com > > > > HTTP/1.1 200 Ok > > Allow: GET, HEAD, OPTIONS, POST > > WhatEverTheHeaderName:=20 > http://example.com/collection/?function=3DAddMember > > > > Of course, in the case of embedding the Post service URI in a site > > description, there would be one URI for all resources belonging to=20= > that > > site and the client is not able to control in which collection the > > resource will appear. But I do not see that as an issue... > > > > I see beauty in describing such functions inside a site description > > resource. It is cacheable again, it can habe ETags, it can be=20 > target of > > conditional retrieval and it can even be authorable via WebDAV=20 > should > > some crazy people want to do that. > > > > //Stefan > > > > Am 17.02.2005 um 14:04 schrieb Geoffrey M Clemm: > > > > > > > > Stefan: How does your proposal below address the problem of=20 > performing > > > an addmember function against a resource that already interprets=20= > POST > > > as meaning "execute the function specified in some special format=20= > in > > > the body of this POST call". =A0You don't want to have to = introduce=20 > a new > > > resource just to perform an addmember function against that=20 > resource. > > > > > > Cheers, > > > =A0Geoff > > > > > > Stefan wrote on 02/17/2005 07:58:58 AM: > > > =A0> > > > =A0> I think What Would Make The World A Better Place is a=20 > mechanism that > > > =A0> generic clients can discover POST service points where they = can > > > persist > > > =A0> new entities. There is nothing wrong with POST, it is just=20= > that a > > > =A0> client cannot discover if and where a server supports that=20= > feature. > > > =A0> > > > =A0> Atom solves this problem by embedding the POST service uri=20= > into the > > > =A0> feed document. That is fine, but > > > =A0> a) has low reusablity for other protocols/applications > > > =A0> b) has no usability from the view of a generic client > > > =A0> > > > =A0> =A0 I think this is what Julian tries to address with = ADDMEMBER,=20 > since > > > =A0> this method will =A0be visible in an OPTIONS response.=20 > Alternatively, > > > an > > > =A0> OPTIONS reponse could carry an extra Header with the URI of=20= > such a > > > POST > > > =A0> service. > > > =A0> > > > =A0> On second thought, this could also be nicely wrapped up = inside=20 > a > > > site > > > =A0> description and the pointer to the site could be a header in = an > > > OPTIONS > > > =A0> response. Then a small, extensible site description document=20= > (XML) > > > =A0> could do the job nicely. > > > =A0> > > > =A0> //Stefan > > > =A0> > > > =A0> Am 17.02.2005 um 13:32 schrieb Geoffrey M Clemm: > > > =A0> > > > =A0> > > > > =A0> > I believe the problem arises when you are trying to apply = the > > > =A0> > addmember function to a resource that already handles POST = as > > > meaning > > > =A0> > "do the operation specifies in the body of the POST". > > > =A0> > To use POST to perform an addmember to that resource, you=20= > would > > > =A0> > need to have some special encoding of the addmember = function=20 > in > > > =A0> > the body of the POST. =A0But this special encoding only = works=20 > on > > > =A0> > resources that support that particular encoding for POST=20= > calls. > > > =A0> > So that would mean that for a client to use POST to = perform > > > addmember, > > > =A0> > it would need to know whether or not a resource already=20 > interprets > > > =A0> > POST in a certain way, and then would need to know the=20 > encoding in > > > =A0> > the body that would be understood by that resource as = meaning > > > =A0> > "addmember". > > > =A0> > > > > =A0> > I may be missing something obvious here (and if so, I'm=20 > counting > > > on > > > =A0> > Roy pointing it out :-), but if not, it seems that POST=20 > cannot be > > > =A0> > defined to perform any particular operation, since it=20 > already is > > > =A0> > being used by some resources to mean "perform the = operation > > > specified > > > =A0> > in the body". > > > =A0> > > > > =A0> > Cheers, > > > =A0> > Geoff > > > =A0> > > > > =A0> > Roy wrote on 02/17/2005 12:54:16 AM: > > > =A0> > =A0> > > > =A0> > =A0> On Feb 16, 2005, at 9:46 AM, Jim Whitehead wrote: > > > =A0> > =A0> > RFC 2616 states: > > > =A0> > =A0> > "The actual function performed by the POST method = is > > > determined > > > =A0> > by the > > > =A0> > =A0> > server and is usually dependent on the = Request-URI." > > > =A0> > =A0> > > > > =A0> > =A0> > =46rom a client perspective this makes POST = unreliable,=20 > and > > > leads > > > =A0> > to the > > > =A0> > =A0> > desire to define a new method. > > > =A0> > =A0> > > > =A0> > =A0> The action will either succeed or fail. =A0If it = succeeds,=20 > the > > > client > > > =A0> > =A0> will receive the exact same response from POST that = it=20 > would > > > have > > > =A0> > =A0> received from a new method. =A0If it fails, the = client will > > > receive > > > =A0> > =A0> the same potential set of failure responses as it = might=20 > have > > > from > > > =A0> > =A0> a new method. > > > =A0> > =A0> > > > =A0> > =A0> The only way you could claim that a new method would = be=20 > more > > > =A0> > reliable > > > =A0> > =A0> is if the client knows the exact implementation of = the=20 > resource > > > =A0> > =A0> being requested, which is something that a client = does=20 > not know > > > =A0> > =A0> with HTTP, and even if it did, it is far more likely = that=20 > it > > > will > > > =A0> > =A0> know how the server and all intermediaries will = respond=20 > to the > > > =A0> > =A0> existing POST method than it could know about their=20= > response to > > > =A0> > =A0> a new method that has zero deployment. > > > =A0> > =A0> > > > =A0> > =A0> ....Roy > > > =A0> > =A0> > > > =A0> > =A0> > > > =A0> > > > =A0> > > > =A0> > > > > From w3c-dist-auth-request@w3.org Thu Feb 17 11:10:50 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12808 for ; Thu, 17 Feb 2005 11:10:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1oEF-0002ld-OK for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Feb 2005 16:10:11 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D1oEF-0002l4-Gz for w3c-dist-auth@listhub.w3.org; Thu, 17 Feb 2005 16:10:11 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1D1oEF-0002UO-5O for w3c-dist-auth@w3.org; Thu, 17 Feb 2005 16:10:11 +0000 Received: (qmail invoked by alias); 17 Feb 2005 16:09:38 -0000 Received: from p508243CD.dip0.t-ipconnect.de (EHLO [192.168.1.87]) (80.130.67.205) by mail.gmx.net (mp020) with SMTP; 17 Feb 2005 17:09:38 +0100 X-Authenticated: #1915285 Message-ID: <4214C1BD.4040309@gmx.de> Date: Thu, 17 Feb 2005 17:09:33 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Heiko.Weber@softwareag.com CC: w3c-dist-auth@w3.org References: <4A56A7900065A44BB559A2C929597BB74264BD@DAEMSG03.eur.ad.sag> In-Reply-To: <4A56A7900065A44BB559A2C929597BB74264BD@DAEMSG03.eur.ad.sag> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Question about DAV:getlastmodified property X-Archived-At: http://www.w3.org/mid/4214C1BD.4040309@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9448 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 17 Feb 2005 16:10:11 +0000 Content-Transfer-Encoding: 7bit Heiko.Weber@softwareag.com wrote: > Hello everyone, Hallo! > I have a question about the value of the DAV:getlastmodified property. > > If I have a WebDAV server which uses an underlying file system, then the > values of that property are pretty much given by that system. If however > I have a WebDAV server which implements the resources itself, is there > some recommendation what the DAV:getlastmodified should reflect? > > Changes to the contents of a resource obviously will affect the > modification date, but which properties do also do that? A rename on > Linux for example will not change the modification date. Should a Because that doesn't really change the state of the file, but the one of it's parent collection (which will have an updated date)... > PROPPATCH on DAV:displayname also not change the modification date of a > resource? What about acquiring a LOCK or setting ACLs on a resource? Has > anybody created a list of properties which should lead to an update of > the modification date, if they are changed? Should changes to dead > properties always lead to a change in the modification date? > > regards, > Heiko Weber In general, the only thing clients can rely on is that *if* getlastmodified is present, it will change anytime the GETtable content changes (within timer resolution...). So on the other hand, servers have a lot of implementation freedom, as long as they don't break that contract. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Feb 17 11:36:03 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18109 for ; Thu, 17 Feb 2005 11:36:02 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1ocP-0008GH-0h for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Feb 2005 16:35:09 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D1ocO-0008EU-Gd; Thu, 17 Feb 2005 16:35:08 +0000 Received: from [217.5.201.10] (helo=greenbytes.de) by bart.w3.org with esmtp (Exim 4.34) id 1D1ocO-0001WU-4B; Thu, 17 Feb 2005 16:35:08 +0000 Received: from [192.168.1.26] by greenbytes.de (Cipher TLSv1:RC4-MD5:128) (MDaemon.PRO.v7.2.3.R) with ESMTP id md50000083833.msg; Thu, 17 Feb 2005 17:33:49 +0100 In-Reply-To: References: <4211E442.40209@gmx.de> <27514C16D36854827D284790@ninevah.cyrusoft.com> <42121E4A.3080007@gmx.de> <62F35864CD746B25C06E1A19@ninevah.cyrusoft.com> <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Julian Reschke , CalDAV DevList , Mark Baker , "Roy T. Fielding" , WebDAV , HTTP Working Group From: Stefan Eissing Date: Thu, 17 Feb 2005 17:34:02 +0100 To: Cyrus Daboo X-Mailer: Apple Mail (2.619.2) X-Authenticated-Sender: se@greenbytes.de X-Spam-Processed: greenbytes.de, Thu, 17 Feb 2005 17:33:49 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.1.26 X-Return-Path: stefan.eissing@greenbytes.de Received-SPF: none (bart.w3.org: domain of stefan.eissing@greenbytes.de does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/a8c1a689cddf0615009d67ec3f8e1df5@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9449 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 17 Feb 2005 16:35:09 +0000 Content-Transfer-Encoding: 7bit Am 17.02.2005 um 17:05 schrieb Cyrus Daboo: > Hi Julian, > > --On February 17, 2005 2:54:38 PM +0100 Julian Reschke > wrote: > >> 1) CalDav's approach is: use PUT to an arbitrary member URI of the >> container; then let the server automagically move it somewhere else, >> and >> report that in the Location response header >> (> -00.html#r >> fc.section.A.2>). > > I want to add that in the CalDAV case this URI naming restriction will > also apply to COPY and MOVE methods too, not just PUT. So we do need > to come up with a solution that at least works with those methods too. > Of course it is possible to emulate COPY and MOVE using PUT (client > downloads original data, creates it in new location) and DELETE > (remove old data in the case of MOVE) - but we should really have the > proper atomic operations for this. It seems to me that however you solve the PUT/ADDMEMBER/POST problem, it can be used to solve the MOVE and COPY scenarios as well, at least for single, plain resources: PUT/ADDMEMBER/POST a new, empty resource -> 201 with Location COPY/MOVE to that new Location Would this work? //Stefan From w3c-dist-auth-request@w3.org Thu Feb 17 12:20:12 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27532 for ; Thu, 17 Feb 2005 12:20:12 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1pIs-0004Kc-Kk for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Feb 2005 17:19:02 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D1pIr-0004Gh-IF for w3c-dist-auth@listhub.w3.org; Thu, 17 Feb 2005 17:19:01 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1D1pIr-000648-5s for w3c-dist-auth@w3.org; Thu, 17 Feb 2005 17:19:01 +0000 Received: (qmail invoked by alias); 17 Feb 2005 17:18:27 -0000 Received: from p508243CD.dip0.t-ipconnect.de (EHLO [192.168.1.87]) (80.130.67.205) by mail.gmx.net (mp026) with SMTP; 17 Feb 2005 18:18:27 +0100 X-Authenticated: #1915285 Message-ID: <4214D1E1.9030700@gmx.de> Date: Thu, 17 Feb 2005 18:18:25 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jamie Lokier CC: "Roy T. Fielding" , Mark Baker , HTTP Working Group , CalDAV DevList , WebDAV References: <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> In-Reply-To: <20050217164142.GA17013@mail.shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/4214D1E1.9030700@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9450 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 17 Feb 2005 17:19:02 +0000 Content-Transfer-Encoding: 7bit Jamie Lokier wrote: > Julian Reschke wrote: > >>>>2) Atom's approach is to use service URIs to which the client can POST, >>>>and to discover these service URIs by parting entity (feed) bodies. >>> >>>... >>> >>> >>>>2) Is specific to Atom and not applicable to other protocols. >>> >>> >>>ADDMEMBER is no different from POST in this respect: >>> >>>You still have to "discover the service URI" to use with ADDMEMBER. >> >>No, it would be the container resource itself. For CalDav, the calendar >>collection; for Atompub, the feed resource itself. > > > Why can't you POST to the container resource? > > That's what POST is for, after all. Because in general, I will have no idea what the server will do with the POST. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Feb 17 12:20:39 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27606 for ; Thu, 17 Feb 2005 12:20:39 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1pJx-0005XT-1l for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Feb 2005 17:20:09 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D1pJw-0005Wd-Dx for w3c-dist-auth@listhub.w3.org; Thu, 17 Feb 2005 17:20:08 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.34) id 1D1pJw-0001IZ-4M for w3c-dist-auth@w3.org; Thu, 17 Feb 2005 17:20:08 +0000 Received: (qmail invoked by alias); 17 Feb 2005 17:19:36 -0000 Received: from p508243CD.dip0.t-ipconnect.de (EHLO [192.168.1.87]) (80.130.67.205) by mail.gmx.net (mp022) with SMTP; 17 Feb 2005 18:19:36 +0100 X-Authenticated: #1915285 Message-ID: <4214D227.9020607@gmx.de> Date: Thu, 17 Feb 2005 18:19:35 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cyrus Daboo CC: Jamie Lokier , Mark Baker , "Roy T. Fielding" , WebDAV , HTTP Working Group , CalDAV DevList References: <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> <788C984DF503C81DC332E7DB@ninevah.cyrusoft.com> In-Reply-To: <788C984DF503C81DC332E7DB@ninevah.cyrusoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/4214D227.9020607@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9451 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 17 Feb 2005 17:20:09 +0000 Content-Transfer-Encoding: 7bit Cyrus Daboo wrote: > Hi Jamie, > > --On February 17, 2005 4:41:42 PM +0000 Jamie Lokier > wrote: > >>> No, it would be the container resource itself. For CalDav, the calendar >>> collection; for Atompub, the feed resource itself. >> >> >> Why can't you POST to the container resource? >> >> That's what POST is for, after all. > > > The WebDAV rfc has the following statement in it in Section 5.3 as a > justification for creating a new method (MKCOL in this case) rather than > using a special POST operation: > >> While the POST method is sufficiently open-ended that a "create a >> collection" POST command could be constructed, this is undesirable >> because it would be difficult to separate access control for >> collection creation from other uses of POST. > > > Wouldn't the same issue be relevant here? > > Interestingly the current WebDAV ACL document does not appear to mention > POST at all - even in the 'Normative' Method Privilege Table in Appendix > B. Is there a reason for that? Yes. As you can do anything with POST, it's impossible to state what privileges you'll need. > Whatever solution we come up with it ideally needs to work seamlessly > with WebDAV ACL. That would be preferrable. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Feb 17 12:42:58 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03341 for ; Thu, 17 Feb 2005 12:42:58 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1pfL-0005AI-G2 for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Feb 2005 17:42:15 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D1pfK-00059d-6i for w3c-dist-auth@listhub.w3.org; Thu, 17 Feb 2005 17:42:14 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by bart.w3.org with esmtp (Exim 4.34) id 1D1pfJ-0004mx-VG for w3c-dist-auth@w3.org; Thu, 17 Feb 2005 17:42:14 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1HHg2aa008044 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 17 Feb 2005 09:42:02 -0800 In-Reply-To: <2844d19383802290887bde5ef6e22e11@greenbytes.de> References: <2844d19383802290887bde5ef6e22e11@greenbytes.de> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: webdav WG , Atom From: Lisa Dusseault Date: Thu, 17 Feb 2005 09:41:55 -0800 To: Stefan Eissing X-Mailer: Apple Mail (2.619.2) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (bart.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/d7593c8a3deb4a6fbf36b4284093afd1@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9452 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 17 Feb 2005 17:42:15 +0000 Content-Transfer-Encoding: 7bit On Feb 17, 2005, at 4:58 AM, Stefan Eissing wrote: > > I think What Would Make The World A Better Place is a mechanism that > generic clients can discover POST service points where they can > persist new entities. There is nothing wrong with POST, it is just > that a client cannot discover if and where a server supports that > feature. > > Atom solves this problem by embedding the POST service uri into the > feed document. That is fine, but > a) has low reusablity for other protocols/applications > b) has no usability from the view of a generic client Not only that, the Atom approach makes it very difficult for a client to synchronize a set of items such as a blog in such a way that the blog can be authored offline and synched with both local changes and server changes. It might be possible for a specialized Atom client but certainly not for an out-of-the-box WebDAV client. That's what concerns me for the feature of adding a new resource and letting the server choose a location -- it would be nice for a tool like Sitecopy to still be able to work. I'm using that more and more to get content to and from sites like ietf.webav.org. > > I think this is what Julian tries to address with ADDMEMBER, since > this method will be visible in an OPTIONS response. Alternatively, an > OPTIONS reponse could carry an extra Header with the URI of such a > POST service. I think ADDMEMBER would be worthwhile if it did have more of an extensibility model and provide the ability to support specialized applications. For example, some calendar servers need to reject non-iCalendar formatted submissions. ADDMEMBER reminds me a lot of MKRESOURCE if it leans in that direction. Lisa From w3c-dist-auth-request@w3.org Thu Feb 17 12:51:12 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05221 for ; Thu, 17 Feb 2005 12:51:12 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1pnM-0000s6-6I for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Feb 2005 17:50:32 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D1pnL-0000rY-TT for w3c-dist-auth@listhub.w3.org; Thu, 17 Feb 2005 17:50:31 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1D1pnL-00032D-IU for w3c-dist-auth@w3.org; Thu, 17 Feb 2005 17:50:31 +0000 Received: (qmail invoked by alias); 17 Feb 2005 17:49:59 -0000 Received: from p508243CD.dip0.t-ipconnect.de (EHLO [192.168.1.87]) (80.130.67.205) by mail.gmx.net (mp008) with SMTP; 17 Feb 2005 18:49:59 +0100 X-Authenticated: #1915285 Message-ID: <4214D946.5000803@gmx.de> Date: Thu, 17 Feb 2005 18:49:58 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: Stefan Eissing , webdav WG , Atom References: <2844d19383802290887bde5ef6e22e11@greenbytes.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/4214D946.5000803@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9453 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 17 Feb 2005 17:50:32 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > ... > I think ADDMEMBER would be worthwhile if it did have more of an > extensibility model and provide the ability to support specialized > applications. For example, some calendar servers need to reject > non-iCalendar formatted submissions. ADDMEMBER reminds me a lot of > MKRESOURCE if it leans in that direction. Well, we just killed MKRESOURCE for good reasons :-) Anyway; nothing is preventing a server to restrict the applicable content types for ADDMEMBER... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Feb 17 13:01:43 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08040 for ; Thu, 17 Feb 2005 13:01:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1pwy-0004xR-BW for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Feb 2005 18:00:28 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D1pwy-0004ws-3q for w3c-dist-auth@listhub.w3.org; Thu, 17 Feb 2005 18:00:28 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by bart.w3.org with esmtp (Exim 4.34) id 1D1pwx-0000Df-SZ for w3c-dist-auth@w3.org; Thu, 17 Feb 2005 18:00:28 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1HI0Faa010330 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 17 Feb 2005 10:00:16 -0800 In-Reply-To: <4214C1BD.4040309@gmx.de> References: <4A56A7900065A44BB559A2C929597BB74264BD@DAEMSG03.eur.ad.sag> <4214C1BD.4040309@gmx.de> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <485a5f64bd82e0a6d176e65b662e0c4f@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org, Heiko.Weber@softwareag.com From: Lisa Dusseault Date: Thu, 17 Feb 2005 10:00:08 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.619.2) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (bart.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Question about DAV:getlastmodified property X-Archived-At: http://www.w3.org/mid/485a5f64bd82e0a6d176e65b662e0c4f@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9454 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 17 Feb 2005 18:00:28 +0000 Content-Transfer-Encoding: 7bit > >> PROPPATCH on DAV:displayname also not change the modification date of >> a >> resource? What about acquiring a LOCK or setting ACLs on a resource? >> Has >> anybody created a list of properties which should lead to an update of >> the modification date, if they are changed? Should changes to dead >> properties always lead to a change in the modification date? >> regards, >> Heiko Weber > > In general, the only thing clients can rely on is that *if* > getlastmodified is present, it will change anytime the GETtable > content changes (within timer resolution...). So on the other hand, > servers have a lot of implementation freedom, as long as they don't > break that contract. > Julian's right, and there's another couple things to point out: while servers have a lot of implementation freedom, there are couple things to consider particularly when interoperating with HTTP clients unaware of properties. 1. Consider whether your getlastmodified will be changed everytime the ETag changes -- or perhaps you're not supporting ETags. If they change together or ETags aren't supported, then there are cache update and lost update considerations (2 and 3). If the getlastmodified and the ETag change at different times, then that might not cause problems but they do need to be considered separately. 2. HTTP clients refresh their caches of resource bodies using the getlastmodified date (or the ETag if that's available and they feel like it). If the getlastmodified date changes whenever properties change (or ACL or lock state), then HTTP clients will have to download the resource body unnecessarily. That might not be a problem if properties change rarely or if resource bodies are small, but it is certainly the minimalist approach to change the getlastmodified or ETag only when the body changes. 3. WebDAV clients (and possibly even HTTP clients) use the getlastmodified date (or the ETag) to determine whether they can take local changes and apply them to the resource, or whether the local changes will conflict with changes made by another user since the resource was downloaded. If the getlastmodified date changes because of property value changes, then the client might have to throw away resource body changes unnecessarily. I'd say that the ETag SHOULD NOT change when the lock state changes because WebDAV clients use that to see if they have to throw away changes. And that means that if the ETag and getlastmodified behave the same way then getlastmodified shouldn't change either. (Consider the case where a client LOCKs and UNLOCKs the resource without changing anything.) Note that the problem of telling when properties change is completely unsolved. Clients can't rely on getlastmodified or ETag because some servers don't change those when properties change. It's pretty well unfeasible to support offline use and synchronization of a decent number of actively changing properties without some extension. Lisa From w3c-dist-auth-request@w3.org Thu Feb 17 13:22:48 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13620 for ; Thu, 17 Feb 2005 13:22:48 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1qHX-0005LJ-1c for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Feb 2005 18:21:43 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D1qHW-0005Kp-EI for w3c-dist-auth@listhub.w3.org; Thu, 17 Feb 2005 18:21:42 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1D1qHW-0000JZ-3l for w3c-dist-auth@w3.org; Thu, 17 Feb 2005 18:21:42 +0000 Received: (qmail invoked by alias); 17 Feb 2005 18:21:09 -0000 Received: from p508243CD.dip0.t-ipconnect.de (EHLO [192.168.1.87]) (80.130.67.205) by mail.gmx.net (mp025) with SMTP; 17 Feb 2005 19:21:09 +0100 X-Authenticated: #1915285 Message-ID: <4214E092.5040400@gmx.de> Date: Thu, 17 Feb 2005 19:21:06 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: algermissen@acm.org CC: Jamie Lokier , "Roy T. Fielding" , Mark Baker , HTTP Working Group , CalDAV DevList , WebDAV References: <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> <4214D1E1.9030700@gmx.de> <4214DD0E.6040709@topicmapping.com> In-Reply-To: <4214DD0E.6040709@topicmapping.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/4214E092.5040400@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9455 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 17 Feb 2005 18:21:43 +0000 Content-Transfer-Encoding: 7bit Jan Algermissen wrote: > Julian Reschke wrote > >> Because in general, I will have no idea what the server will do with >> the POST. > > > Hmm...the meaning of POST is that the server will process the message. > If you receive a 201, > the server has created a resource. But *what* does it contain? In general, I can not assume it will store the entity as sent (like PUT). > ... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Feb 17 13:40:34 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18000 for ; Thu, 17 Feb 2005 13:40:33 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1qZ2-00038w-3o for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Feb 2005 18:39:48 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D1qZ0-00034X-Da for w3c-dist-auth@listhub.w3.org; Thu, 17 Feb 2005 18:39:46 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1D1qZ0-0000OL-0S for w3c-dist-auth@w3.org; Thu, 17 Feb 2005 18:39:46 +0000 Received: (qmail invoked by alias); 17 Feb 2005 18:39:14 -0000 Received: from p508243CD.dip0.t-ipconnect.de (EHLO [192.168.1.87]) (80.130.67.205) by mail.gmx.net (mp007) with SMTP; 17 Feb 2005 19:39:14 +0100 X-Authenticated: #1915285 Message-ID: <4214E4D0.80408@gmx.de> Date: Thu, 17 Feb 2005 19:39:12 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Lawrence CC: Cyrus Daboo , Jamie Lokier , Mark Baker , "Roy T. Fielding" , WebDAV , HTTP Working Group , CalDAV DevList References: <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> <788C984DF503C81DC332E7DB@ninevah.cyrusoft.com> <4214D227.9020607@gmx.de> <1108663634.11773.28.camel@sukothai.pingtel.com> In-Reply-To: <1108663634.11773.28.camel@sukothai.pingtel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/4214E4D0.80408@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9456 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 17 Feb 2005 18:39:48 +0000 Content-Transfer-Encoding: 7bit Scott Lawrence wrote: > That statement misses the point - it may be true that it's difficult to > express the access control based just on the method, but that doesn't > mean that it's difficult to implement appropriate access control in > either the client or the server. The method alone does not specify the > operation - indeed, in the case of POST the full specification of the > operation is deliberately expanded to include the body mime type and the > body content. > > I don't think you've shown how what you're trying to do is any different > from what POST has always done. It's a aubset with well-defined semantics. I consider this a feature. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Feb 17 13:44:01 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18401 for ; Thu, 17 Feb 2005 13:44:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1qcc-0005E8-6e for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Feb 2005 18:43:30 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D1qcb-0005DR-Qi for w3c-dist-auth@listhub.w3.org; Thu, 17 Feb 2005 18:43:29 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1D1qcb-00059g-Go for w3c-dist-auth@w3.org; Thu, 17 Feb 2005 18:43:29 +0000 Received: (qmail invoked by alias); 17 Feb 2005 18:42:58 -0000 Received: from p508243CD.dip0.t-ipconnect.de (EHLO [192.168.1.87]) (80.130.67.205) by mail.gmx.net (mp029) with SMTP; 17 Feb 2005 19:42:58 +0100 X-Authenticated: #1915285 Message-ID: <4214E5B0.8060302@gmx.de> Date: Thu, 17 Feb 2005 19:42:56 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jamie Lokier CC: "Roy T. Fielding" , Mark Baker , HTTP Working Group , CalDAV DevList , WebDAV References: <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> <4214D1E1.9030700@gmx.de> <20050217182505.GA18275@mail.shareable.org> In-Reply-To: <20050217182505.GA18275@mail.shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/4214E5B0.8060302@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9457 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 17 Feb 2005 18:43:30 +0000 Content-Transfer-Encoding: 7bit Jamie Lokier wrote: > Julian Reschke wrote: > >>Because in general, I will have no idea what the server will do with the >>POST. > > > In general, you don't know what it will do with ADDMEMBER either. I do, because I'll make the assumption that a server that advertises support for ADDMEMBER indeed implements what the spec says. Are you saying that I can't make that assumption? > This is better illustrated with PUT. Clearly, PUT is intended for > creating or modifying an entity at a client-specific URI. > > I have the impression you expect this is literally what PUT should do: > that afterwards, GET from that URI, if permitted, will return the last > entity that was put. Yes. > Plenty of HTTP servers which don't work like that. Often, you can PUT > to a URI ending in ".cgi" or ".php" for example, and (possibly > depending on the put'd content type, possibly not) GET will not return > the same entity; instead it will initiate processing using the > resource now present at that URI. I'd consider that a bug. > You can PUT to a URI ending in ".html" and with content-type > "text/html" even, but with some servers, GET from the same URI will > initiate content negotiation and may return that entity, a different > one, a transcoded one, a tidied one, etc., according to server-defined > rules. (Section 5.4 of WebDAV, RFC 2518 has more to say on this). In which case the server shouldn't have supported PUT on that URI in the first place. > Given that PUT has somewhat open-ended semantics - won't ADDMEMBER > have similarly open-ended semantics? I don't agree that it has open-ended semantics. But it's good that you raise this issue, because it's essential to understand the rational for ADDMEMBER. > How is an ADDMEMBER whose effect is as open-ended as PUT, but which > creates a resource at a server-selected URI, any different from POST - > even for access control? > > It seems to me that if you're considering making access control > decisions on the difference between ADDMEMBER and POST, then you > should really be making those decisions on the known behaviour of the > request URI. If you don't recognise the request URI, then you don't > really know what ADDMEMMER _or_ POST will do, in general. See above. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Feb 17 13:49:07 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18973 for ; Thu, 17 Feb 2005 13:49:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1qhP-0000R0-Jk for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Feb 2005 18:48:27 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D1qhP-0000QQ-92 for w3c-dist-auth@listhub.w3.org; Thu, 17 Feb 2005 18:48:27 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.34) id 1D1qhO-0006Tl-VM for w3c-dist-auth@w3.org; Thu, 17 Feb 2005 18:48:27 +0000 Received: (qmail invoked by alias); 17 Feb 2005 18:47:55 -0000 Received: from p508243CD.dip0.t-ipconnect.de (EHLO [192.168.1.87]) (80.130.67.205) by mail.gmx.net (mp016) with SMTP; 17 Feb 2005 19:47:55 +0100 X-Authenticated: #1915285 Message-ID: <4214E6D9.8010706@gmx.de> Date: Thu, 17 Feb 2005 19:47:53 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jamie Lokier CC: algermissen@acm.org, "Roy T. Fielding" , Mark Baker , HTTP Working Group , CalDAV DevList , WebDAV References: <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> <4214D1E1.9030700@gmx.de> <4214DD0E.6040709@topicmapping.com> <4214E092.5040400@gmx.de> <20050217183809.GB18275@mail.shareable.org> In-Reply-To: <20050217183809.GB18275@mail.shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/4214E6D9.8010706@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9458 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 17 Feb 2005 18:48:27 +0000 Content-Transfer-Encoding: 7bit Jamie Lokier wrote: > Julian Reschke wrote: > >>>>Because in general, I will have no idea what the server will do with >>>>the POST. >>> >>>Hmm...the meaning of POST is that the server will process the message. >>>If you receive a 201, >>>the server has created a resource. >> >>But *what* does it contain? In general, I can not assume it will store >>the entity as sent (like PUT). > > ^^^^^^^^ > > You cannot assume PUT will store the entity as sent either. > > Read section 5.4 "Source Resources and Output Resources" in RFC 2518, WebDAV. > (That part's not specific to WebDAV; it's a just a good explanation). In fact, it says: "However, if remote editing of the source resource(s) is desired, the source resource(s) should be given a location in the URI namespace. This source location should not be one of the locations at which the generated output is retrievable, since in general it is impossible for the server to differentiate requests for source resources from requests for process output resources." >>From the client's point of view, once you have PUT an entity, in > general you have no way to retrieve that exact entity. Many servers > will process the resource you created to produce the response to GET, > instead of merely returning the entity you sent earlier. > > Because you can't necessarily retrieve the entity sent, you can't make > assumptions about what the server stores. It might store only part of > what you sent, or a transformed version. What it actually stores -- > and the side effects of doing so -- are quite open. You keep saying this, but it would be nice if you could point out where that kind of behaviour is described. RFC2616 says: "The PUT method requests that the enclosed entity be stored under the supplied Request-URI." And that's certainly what today's WebDAV servers implement and WebDAV clients do expect. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Feb 17 15:09:08 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28536 for ; Thu, 17 Feb 2005 15:09:07 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1rwH-0001UP-Jx for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Feb 2005 20:07:53 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D1rwG-0001Th-1y for w3c-dist-auth@listhub.w3.org; Thu, 17 Feb 2005 20:07:52 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1D1rwF-0001Gk-O6 for w3c-dist-auth@w3.org; Thu, 17 Feb 2005 20:07:51 +0000 Received: (qmail invoked by alias); 17 Feb 2005 20:07:19 -0000 Received: from pD9E510FD.dip.t-dialin.net (EHLO [192.168.0.3]) (217.229.16.253) by mail.gmx.net (mp024) with SMTP; 17 Feb 2005 21:07:19 +0100 X-Authenticated: #1915285 Message-ID: <4214F973.9060404@gmx.de> Date: Thu, 17 Feb 2005 21:07:15 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Lawrence CC: Cyrus Daboo , Jamie Lokier , Mark Baker , "Roy T. Fielding" , WebDAV , HTTP Working Group , CalDAV DevList References: <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> <788C984DF503C81DC332E7DB@ninevah.cyrusoft.com> <4214D227.9020607@gmx.de> <1108663634.11773.28.camel@sukothai.pingtel.com> <4214E4D0.80408@gmx.de> <1108670449.11773.33.camel@sukothai.pingtel.com> In-Reply-To: <1108670449.11773.33.camel@sukothai.pingtel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/4214F973.9060404@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9459 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 17 Feb 2005 20:07:53 +0000 Content-Transfer-Encoding: 7bit Scott Lawrence wrote: > On Thu, 2005-02-17 at 19:39 +0100, Julian Reschke wrote: > >>Scott Lawrence wrote: >> >>>That statement misses the point - it may be true that it's difficult to >>>express the access control based just on the method, but that doesn't >>>mean that it's difficult to implement appropriate access control in >>>either the client or the server. The method alone does not specify the >>>operation - indeed, in the case of POST the full specification of the >>>operation is deliberately expanded to include the body mime type and the >>>body content. >>> >>>I don't think you've shown how what you're trying to do is any different >>>from what POST has always done. >> >>It's a aubset with well-defined semantics. I consider this a feature. > > > But you could just as easily and precisely define those semantics by > using POST and defining the mime type and operations it supports. In which case I couldn't use the content-type of my actual request body for the Content-Type request header, right? > You won't get caught be firewalls and proxy servers that think they know > better about what methods are legitimate (which you most assuredly will > if you create a new method - ask the WebDav implementors), and you won't > have changed the semantics of the method at all. I am one of these WebDAV implementors, thanks. I haven't had any issues with issues for a long time. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Feb 17 15:50:41 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03913 for ; Thu, 17 Feb 2005 15:50:41 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1sas-0006m7-Hm for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Feb 2005 20:49:50 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D1sas-0006lM-3I for w3c-dist-auth@listhub.w3.org; Thu, 17 Feb 2005 20:49:50 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1D1sar-0000Y1-OI for w3c-dist-auth@w3.org; Thu, 17 Feb 2005 20:49:50 +0000 Received: (qmail invoked by alias); 17 Feb 2005 20:49:16 -0000 Received: from pD9E510FD.dip.t-dialin.net (EHLO [192.168.0.3]) (217.229.16.253) by mail.gmx.net (mp001) with SMTP; 17 Feb 2005 21:49:16 +0100 X-Authenticated: #1915285 Message-ID: <4215033B.3000206@gmx.de> Date: Thu, 17 Feb 2005 21:48:59 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jamie Lokier CC: algermissen@acm.org, "Roy T. Fielding" , Mark Baker , HTTP Working Group , CalDAV DevList , WebDAV References: <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> <4214D1E1.9030700@gmx.de> <4214DD0E.6040709@topicmapping.com> <4214E092.5040400@gmx.de> <20050217183809.GB18275@mail.shareable.org> <4214E6D9.8010706@gmx.de> <20050217201029.GH18275@mail.shareable.org> In-Reply-To: <20050217201029.GH18275@mail.shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/4215033B.3000206@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9460 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 17 Feb 2005 20:49:50 +0000 Content-Transfer-Encoding: 7bit Jamie Lokier wrote: > ... > And so, for ADDMEMBER to be useful, you need to specify it more > tightly than "PUT except the created resource URI is selected > differently". > > If you do that, it makes sense. If you don't, then ADDMEMBER is no > different from POST. > ... OK, to summarize: your point is that PUT doesn't have the strict semantics (that I claim it has). Let's just agree that we disagree here. > That said, even if you do specify ADDMEMBER more tightly, I still > don't see how the difference would benefit you. You say it could be > useful to an intermediary, but can you give a plausible example? Did I? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Feb 17 16:05:52 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05140 for ; Thu, 17 Feb 2005 16:05:51 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1spk-0003ZW-RK for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Feb 2005 21:05:12 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D1spj-0003Yx-N6 for w3c-dist-auth@listhub.w3.org; Thu, 17 Feb 2005 21:05:11 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by bart.w3.org with esmtp (Exim 4.34) id 1D1spj-0003Am-EQ for w3c-dist-auth@w3c.org; Thu, 17 Feb 2005 21:05:11 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id j1HL4lXX013061; Thu, 17 Feb 2005 13:04:47 -0800 (PST) Message-Id: <200502172104.j1HL4lXX013061@services.cse.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'Julian Reschke'" Cc: "'Webdav WG'" Date: Thu, 17 Feb 2005 13:04:39 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <4215033B.3000206@gmx.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcUVMkWXdCvNxBRMRuqIF4c3TgqLQQAAVi9Q Received-SPF: none (bart.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/200502172104.j1HL4lXX013061@services.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9461 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 17 Feb 2005 21:05:12 +0000 Content-Transfer-Encoding: 7bit A few comments on extending the functionality defined in -addmember-00: 1) One problem clients currently encounter with PUT is determining whether they have permission to write to a specific location. At present, a client must submit a PUT (or ADDMEMBER) with the entire entity body, then wait for the response, or the authentication challenge. It would be very nice to have a TESTPUT/TESTADDMEMBER method that sees whether a write (via PUT or ADDMEMBER) would succeed, or if an authentication challenge is needed. Yes, a server supporting ACLs could be queries to see if writing were allowed, but it still doesn't provide an easy way to pre-determine the authentication information. 2) It would be very helpful to allow ADDMEMBER to have atomic PUT+PROPPATCH capabilities, to write both the resource and its metadata in one action. - Jim From w3c-dist-auth-request@w3.org Thu Feb 17 16:12:42 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05786 for ; Thu, 17 Feb 2005 16:12:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1sw9-0006Xe-87 for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Feb 2005 21:11:49 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D1sw8-0006Ws-UT for w3c-dist-auth@listhub.w3.org; Thu, 17 Feb 2005 21:11:48 +0000 Received: from medusa.mdlink.de ([213.211.192.34] helo=mail.mdlink.net) by lisa.w3.org with esmtp (Exim 4.34) id 1D1sw8-0001DQ-OO for w3c-dist-auth@w3c.org; Thu, 17 Feb 2005 21:11:48 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 4A1F82DB7EE for ; Thu, 17 Feb 2005 22:10:34 +0100 (CET) Received: from [192.168.1.233] (port-ip-213-211-241-130.reverse.mdcc-fun.de [213.211.241.130]) by mail.mdlink.net (Postfix) with ESMTP id E99452D8D9E for ; Thu, 17 Feb 2005 22:10:33 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <200502172104.j1HL4lXX013061@services.cse.ucsc.edu> References: <200502172104.j1HL4lXX013061@services.cse.ucsc.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <574c8b49ef70b65d510ad7bcf57d0b63@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Date: Thu, 17 Feb 2005 22:11:09 +0100 To: "'Webdav WG'" X-Mailer: Apple Mail (2.619.2) Received-SPF: none (lisa.w3.org: domain of helge.hess@opengroupware.org does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/574c8b49ef70b65d510ad7bcf57d0b63@opengroupware.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9462 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 17 Feb 2005 21:11:49 +0000 Content-Transfer-Encoding: 7bit On 17. Feb 2005, at 22:04 Uhr, Jim Whitehead wrote: > 1) One problem clients currently encounter with PUT is determining > whether > they have permission to write to a specific location. At present, a > client > must submit a PUT (or ADDMEMBER) with the entire entity body, then > wait for > the response, or the authentication challenge. Isn't that already solved with Expect: 100-continue? http://zvon.org/tmRFC/RFC2616/Output/chapter14.html#sub20 Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From w3c-dist-auth-request@w3.org Thu Feb 17 16:45:21 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08973 for ; Thu, 17 Feb 2005 16:45:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1tRj-0008RI-Iv for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Feb 2005 21:44:27 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D1tRg-0008JD-IW for w3c-dist-auth@listhub.w3.org; Thu, 17 Feb 2005 21:44:24 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by bart.w3.org with esmtp (Exim 4.34) id 1D1tPy-0000xG-NI for w3c-dist-auth@w3c.org; Thu, 17 Feb 2005 21:42:38 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3c.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1HLfRab010146 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 17 Feb 2005 13:42:21 -0800 In-Reply-To: <200502172104.j1HL4lXX013061@services.cse.ucsc.edu> References: <200502172104.j1HL4lXX013061@services.cse.ucsc.edu> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "'Julian Reschke'" , "'Webdav WG'" From: Lisa Dusseault Date: Thu, 17 Feb 2005 13:42:21 -0800 To: X-Mailer: Apple Mail (2.619.2) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (bart.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/b379cf31de8e1092e8395b74181c0911@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9463 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 17 Feb 2005 21:44:27 +0000 Content-Transfer-Encoding: 7bit Rather than a new method, an ADDMEMBER specification could require support for the Expect mechanism which solves that problem rather neatly for any method. Lisa On Feb 17, 2005, at 1:04 PM, Jim Whitehead wrote: > > A few comments on extending the functionality defined in -addmember-00: > > 1) One problem clients currently encounter with PUT is determining > whether > they have permission to write to a specific location. At present, a > client > must submit a PUT (or ADDMEMBER) with the entire entity body, then > wait for > the response, or the authentication challenge. It would be very nice > to have > a TESTPUT/TESTADDMEMBER method that sees whether a write (via PUT or > ADDMEMBER) would succeed, or if an authentication challenge is needed. > > Yes, a server supporting ACLs could be queries to see if writing were > allowed, but it still doesn't provide an easy way to pre-determine the > authentication information. > > 2) It would be very helpful to allow ADDMEMBER to have atomic > PUT+PROPPATCH > capabilities, to write both the resource and its metadata in one > action. > > - Jim > > From w3c-dist-auth-request@w3.org Thu Feb 17 16:52:18 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10239 for ; Thu, 17 Feb 2005 16:52:17 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1tYg-0003tn-Au for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Feb 2005 21:51:38 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D1tYe-0003t4-0T for w3c-dist-auth@listhub.w3.org; Thu, 17 Feb 2005 21:51:36 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by lisa.w3.org with esmtp (Exim 4.34) id 1D1tYd-0006UD-O6 for w3c-dist-auth@w3c.org; Thu, 17 Feb 2005 21:51:35 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id j1HLpDoU002154; Thu, 17 Feb 2005 13:51:13 -0800 (PST) Message-Id: <200502172151.j1HLpDoU002154@services.cse.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'Lisa Dusseault'" , Cc: "'Julian Reschke'" , "'Webdav WG'" Date: Thu, 17 Feb 2005 13:51:05 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcUVOZjAmhfb8zshQ766MBLBZT/IgQAARvNw Received-SPF: none (lisa.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/200502172151.j1HLpDoU002154@services.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9464 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 17 Feb 2005 21:51:38 +0000 Content-Transfer-Encoding: 7bit I don't think Expect allows you to easily determine what access control challenge you'll receive. Am I wrong? - Jim > -----Original Message----- > From: Lisa Dusseault [mailto:lisa@osafoundation.org] > Sent: Thursday, February 17, 2005 1:42 PM > To: ejw@soe.ucsc.edu > Cc: 'Julian Reschke'; 'Webdav WG' > Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] > > Rather than a new method, an ADDMEMBER specification could > require support for the Expect mechanism which solves that > problem rather neatly for any method. > > Lisa > > On Feb 17, 2005, at 1:04 PM, Jim Whitehead wrote: > > > > > A few comments on extending the functionality defined in > -addmember-00: > > > > 1) One problem clients currently encounter with PUT is determining > > whether they have permission to write to a specific location. At > > present, a client must submit a PUT (or ADDMEMBER) with the entire > > entity body, then wait for the response, or the authentication > > challenge. It would be very nice to have a TESTPUT/TESTADDMEMBER > > method that sees whether a write (via PUT or > > ADDMEMBER) would succeed, or if an authentication challenge > is needed. > > > > Yes, a server supporting ACLs could be queries to see if > writing were > > allowed, but it still doesn't provide an easy way to > pre-determine the > > authentication information. > > > > 2) It would be very helpful to allow ADDMEMBER to have atomic > > PUT+PROPPATCH > > capabilities, to write both the resource and its metadata in one > > action. > > > > - Jim > > > > > From w3c-dist-auth-request@w3.org Thu Feb 17 17:00:30 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12645 for ; Thu, 17 Feb 2005 17:00:30 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1tgZ-0007Ke-Pf for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Feb 2005 21:59:47 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D1tgU-0007Ix-Gj for w3c-dist-auth@listhub.w3.org; Thu, 17 Feb 2005 21:59:42 +0000 Received: from medusa.mdlink.de ([213.211.192.34] helo=mail.mdlink.net) by bart.w3.org with esmtp (Exim 4.34) id 1D1tgU-0003pl-8O for w3c-dist-auth@w3c.org; Thu, 17 Feb 2005 21:59:42 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id D62412DB83D for ; Thu, 17 Feb 2005 22:58:27 +0100 (CET) Received: from [192.168.1.233] (port-ip-213-211-241-130.reverse.mdcc-fun.de [213.211.241.130]) by mail.mdlink.net (Postfix) with ESMTP id 4E8EF2DB838 for ; Thu, 17 Feb 2005 22:58:27 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <200502172151.j1HLpDoU002154@services.cse.ucsc.edu> References: <200502172151.j1HLpDoU002154@services.cse.ucsc.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Date: Thu, 17 Feb 2005 22:59:08 +0100 To: "'Webdav WG'" X-Mailer: Apple Mail (2.619.2) Received-SPF: none (bart.w3.org: domain of helge.hess@opengroupware.org does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/bf43653a92ff37cd6a9c475389f45773@opengroupware.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9465 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 17 Feb 2005 21:59:47 +0000 Content-Transfer-Encoding: 7bit On 17. Feb 2005, at 22:51 Uhr, Jim Whitehead wrote: > I don't think Expect allows you to easily determine what access control > challenge you'll receive. Am I wrong? Not sure what you mean by "access control challange". It allows you to determine whether authentication is required or valid prior pushing the content. Access control must be determined with WebDAV ACL or something similiar. It goes like this: 1) client sends HTTP request header with expect: 100-continue 2) server checks the 'authorization' header 3) if authorization fails for the given method+header, the server sends a 401 with www-authenticate 4) if auth is OK, it sends a 100 Continue Pretty much what you were asking for initially? Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From w3c-dist-auth-request@w3.org Thu Feb 17 17:07:02 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14051 for ; Thu, 17 Feb 2005 17:07:02 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1tmx-0001Y0-Gx for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Feb 2005 22:06:23 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D1tRo-0008JD-65 for w3c-dist-auth@listhub.w3.org; Thu, 17 Feb 2005 21:44:32 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1D1tD9-0007FY-H5 for w3c-dist-auth@w3c.org; Thu, 17 Feb 2005 21:29:23 +0000 Received: (qmail invoked by alias); 17 Feb 2005 21:28:48 -0000 Received: from pD9E510FD.dip.t-dialin.net (EHLO [192.168.0.3]) (217.229.16.253) by mail.gmx.net (mp023) with SMTP; 17 Feb 2005 22:28:48 +0100 X-Authenticated: #1915285 Message-ID: <42150C83.7030301@gmx.de> Date: Thu, 17 Feb 2005 22:28:35 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Helge Hess CC: "'Webdav WG'" References: <200502172104.j1HL4lXX013061@services.cse.ucsc.edu> <574c8b49ef70b65d510ad7bcf57d0b63@opengroupware.org> In-Reply-To: <574c8b49ef70b65d510ad7bcf57d0b63@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/42150C83.7030301@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9466 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 17 Feb 2005 22:06:23 +0000 Content-Transfer-Encoding: 7bit Helge Hess wrote: > > On 17. Feb 2005, at 22:04 Uhr, Jim Whitehead wrote: > >> 1) One problem clients currently encounter with PUT is determining >> whether >> they have permission to write to a specific location. At present, a >> client >> must submit a PUT (or ADDMEMBER) with the entire entity body, then >> wait for >> the response, or the authentication challenge. > > > Isn't that already solved with Expect: 100-continue? > > http://zvon.org/tmRFC/RFC2616/Output/chapter14.html#sub20 Sort of. The problem is that it's extremely hard to implement using the Java servlet API (but that's "just" an implementation issue...). Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Feb 17 18:07:51 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21704 for ; Thu, 17 Feb 2005 18:07:51 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1ujM-0002GU-Re for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Feb 2005 23:06:44 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D1ujK-0002FA-9m for w3c-dist-auth@listhub.w3.org; Thu, 17 Feb 2005 23:06:42 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1D1ujJ-0008Kc-TG for w3c-dist-auth@w3.org; Thu, 17 Feb 2005 23:06:42 +0000 Received: (qmail invoked by alias); 17 Feb 2005 23:06:08 -0000 Received: from pD9E510FD.dip.t-dialin.net (EHLO [192.168.0.3]) (217.229.16.253) by mail.gmx.net (mp001) with SMTP; 18 Feb 2005 00:06:08 +0100 X-Authenticated: #1915285 Message-ID: <42152354.1090407@gmx.de> Date: Fri, 18 Feb 2005 00:05:56 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jamie Lokier CC: algermissen@acm.org, "Roy T. Fielding" , Mark Baker , HTTP Working Group , CalDAV DevList , WebDAV References: <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> <4214D1E1.9030700@gmx.de> <4214DD0E.6040709@topicmapping.com> <4214E092.5040400@gmx.de> <20050217183809.GB18275@mail.shareable.org> <4214E6D9.8010706@gmx.de> <20050217201029.GH18275@mail.shareable.org> <4215033B.3000206@gmx.de> <20050217224939.GA22967@mail.shareable.org> In-Reply-To: <20050217224939.GA22967@mail.shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/42152354.1090407@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9467 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 17 Feb 2005 23:06:44 +0000 Content-Transfer-Encoding: 7bit Jamie Lokier wrote: > which I took to mean you wanted to be sure of what would happen, > perhaps with a view to a security policy or intermediary behaviour. > My mistake. > > So I'll humbly rephrase my question: > > Even if you do specify ADDMEMBER more tightly (than POST), I still > don't see how the difference would benefit you. You say it is useful > to have an idea what the server will do with a POST, in general. In > general means an arbitrary URI with unknown properties, because if > it's a URI with known properties, you know exactly what POST will do. > > How does specifying ADDMEMBER to have tighter semantics than PUT and > POST benefit you when sending the request to an arbitrary URI with > unknown properties? Can you give an example? The same way as COPY, LOCK, MOVE, VERSION-CONTROL, ... I don't think I understand your point. Any operation *can* be marshalled through POST, but that doesn't mean it's the best way to do it. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Feb 17 18:28:54 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23672 for ; Thu, 17 Feb 2005 18:28:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1v43-00010X-Pr for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Feb 2005 23:28:07 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D1v43-0000zx-AD for w3c-dist-auth@listhub.w3.org; Thu, 17 Feb 2005 23:28:07 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by bart.w3.org with esmtp (Exim 4.34) id 1D1v43-0008C8-1c for w3c-dist-auth@w3c.org; Thu, 17 Feb 2005 23:28:07 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id j1HNS5Xr015269 for ; Thu, 17 Feb 2005 15:28:05 -0800 (PST) Message-Id: <200502172328.j1HNS5Xr015269@services.cse.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'Webdav WG'" Date: Thu, 17 Feb 2005 15:27:57 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcUVPAZtcI0QU5n8QlqLAlZ2DRfqfwADDOLg Received-SPF: none (bart.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/200502172328.j1HNS5Xr015269@services.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9468 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 17 Feb 2005 23:28:07 +0000 Content-Transfer-Encoding: 7bit > Pretty much what you were asking for initially? Er, yes. Thanks. - Jim From w3c-dist-auth-request@w3.org Thu Feb 17 18:51:27 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26608 for ; Thu, 17 Feb 2005 18:51:27 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D1vPs-0000Fb-KZ for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Feb 2005 23:50:40 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D1vPs-0000F6-6J; Thu, 17 Feb 2005 23:50:40 +0000 Received: from scorpio.lunarpages.com ([64.235.234.122]) by bart.w3.org with esmtp (Exim 4.34) id 1D1vPr-0002Bi-UH; Thu, 17 Feb 2005 23:50:40 +0000 Received: from wsip-24-248-98-242.oc.oc.cox.net ([24.248.98.242] helo=[10.2.8.58]) by scorpio.lunarpages.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.44) id 1D1vPp-0000F6-Cr; Thu, 17 Feb 2005 15:50:37 -0800 In-Reply-To: <4214A21E.5070804@gmx.de> References: <4211E442.40209@gmx.de> <27514C16D36854827D284790@ninevah.cyrusoft.com> <42121E4A.3080007@gmx.de> <62F35864CD746B25C06E1A19@ninevah.cyrusoft.com> <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: HTTP Working Group , Mark Baker , CalDAV DevList , WebDAV From: "Roy T. Fielding" Date: Thu, 17 Feb 2005 15:50:39 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.619.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - scorpio.lunarpages.com X-AntiAbuse: Original Domain - w3.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - gbiv.com Received-SPF: none (bart.w3.org: domain of fielding@gbiv.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/d23b29d789b472835a75d0b2038b6ba0@gbiv.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9469 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 17 Feb 2005 23:50:40 +0000 Content-Transfer-Encoding: 7bit On Feb 17, 2005, at 5:54 AM, Julian Reschke wrote: >>> Had HTTP a means for extending a method to declare this additional >>> expectation (as described in the draft's A.3 using RFC 2774), I agree >>> that POST + extension would be appropriate. >> It doesn't because it never needed it. > > OK, let's step back and look at the situation that caused me to make > this proposal. > > Two separate communities (CalDAV/GroupDav and Atompub) encountered the > same issue: what's the best way to create a new resource on an HTTP > server when I can't use PUT as the URI space may be entirely > server-controlled? > > 1) CalDav's approach is: use PUT to an arbitrary member URI of the > container; then let the server automagically move it somewhere else, > and report that in the Location response header > ( -00.html#rfc.section.A.2>). That is not allowed in HTTP. > 2) Atom's approach is to use service URIs to which the client can > POST, and to discover these service URIs by parting entity (feed) > bodies. That is allowed. > Somehow I have the (perhaps naive) wish that identical requirements > should lead to common protocol constructs. > > 1) Seems to break PUT semantics; > > 2) Is specific to Atom and not applicable to other protocols. No, it isn't. The client must "discover" the server's URI somehow, whether that be via hypertext, save under dialogs, or an atom link. They are all equivalent discovery mechanisms. When Atom does a POST it will send a representation of an entry (which happens to be just another resource). When a generic HTTP client does a POST it will send a representation of a resource. The server receives a POST message targeting a URI and containing a representation. It can do one of three things: 1) deny the request with method not allowed (or any other error); 2) treat all POSTs as the same; or 3) decide, based on the URI alone or in combination with the representation, how to process the request. In all cases, the client can assume the addmember semantics of POST without any interoperability issues. It is the server's responsibility to provide resource references to the client that match the actions called for by whatever it is the client is doing, and even if the client picks some random URI the server is more than capable of providing an appropriate response. Geoff asked what happens if the resource already supports POST for some other purpose. The answer is one of 1) if the implementation supports the addmember purpose in addition to its other duties, it will return 201 Created; 2) if the implementation does not allow subsidiary resources to be created, then a) if the implementation is written according to HTTP, it will return 415 Unsupported Media Type; or b) if the implementation is clueless, it will attempt to parse the media type that it expects and will fail with some form of 4xx response. [Note that this is the case whether the method is POST or ADDMEMBER -- clueless implementations do not check the method either.] c) if the implementation is totally ignorant of all things HTTP, it will respond with 200 and a friendly error message about how this site only works with MSIE 5 (again, regardless of the method used). So, the answer to Geoff's question is a new method is not necessary to distinguish one POST from another POST because this was already considered by HTTP in 1992 http://www.w3.org/Protocols/HTTP/Methods/Post.html and codified in RFC 1945, 2068, and 2616. The reason it allows the server so much leeway in its handling of the request is because only the resource can determine, according to its own implementation and purpose in life, the most appropriate way to store subsidiary resources. ANY other specification would assume that an HTTP server is just another form of file server like FTP (which is not its purpose in life, as I've explained a million times before). If the client sends random unsafe requests to a Web server, it will obtain randomly unsafe results regardless of the method used. If the server provides a URI as an authorable resource, then POST to a collection has the semantics of adding a member to that collection -- the semantics have not changed just because webdav chose to ignore that feature of HTTP. ....Roy From w3c-dist-auth-request@w3.org Fri Feb 18 00:12:58 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26832 for ; Fri, 18 Feb 2005 00:12:58 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D20QM-0003dZ-4U for w3c-dist-auth-dist@listhub.w3.org; Fri, 18 Feb 2005 05:11:30 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D20QI-0003br-KK; Fri, 18 Feb 2005 05:11:26 +0000 Received: from e4.ny.us.ibm.com ([32.97.182.144]) by lisa.w3.org with esmtp (Exim 4.34) id 1D20QI-0003Xu-Dw; Fri, 18 Feb 2005 05:11:26 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j1I5Ar34016688; Fri, 18 Feb 2005 00:10:53 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1I5Ar2O245762; Fri, 18 Feb 2005 00:10:53 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1I5AqYN029026; Fri, 18 Feb 2005 00:10:53 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1I5AqeD029023; Fri, 18 Feb 2005 00:10:52 -0500 In-Reply-To: To: WebDAV Cc: CalDAV DevList , HTTP Working Group MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Fri, 18 Feb 2005 00:10:51 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 02/18/2005 00:10:52, Serialize complete at 02/18/2005 00:10:52 Content-Type: multipart/alternative; boundary="=_alternative 001C76B685256FAC_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.144 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: draft-reschke-http-addmember-00 X-Archived-At: http://www.w3.org/mid/OF5A5B41F6.0D254554-ON85256FAC.00181251-85256FAC.001C76B8@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9470 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 18 Feb 2005 05:11:30 +0000 This is a multipart message in MIME format. --=_alternative 001C76B685256FAC_= Content-Type: text/plain; charset="US-ASCII" My main concern is that because of the popularity of SOAP, many/most implementations fall into category 2b (i.e., "clueless"), so a resource will say that it supports the POST operation, but will actually fail it with some kind of 4xx response because it cannot parse the body, or in the worst case, will successfully parse the body and execute some potentially harmful SOAP operation that was never intended by the client (the client just wanted a subsidiary whose content was that body to be created). I'm rather surprised that clueless (e.g., SOAP :-) implementations would parse the body of an unknown method (e.g., ADDMEMBER) and treat it as if it were a POST call. I would have expected SOAP implementations to limit themselves to parsing only POST bodies. But Roy knows way more about that kind of thing than I do ... But even if a clueless implementation will try to parse the body of an unknown method like ADDMEMBER, I assume it is very unlikely that it would say that it supports the ADDMEMBER method on that resource, so that at least would give the client a way of avoiding the problem (i.e., by first asking the resource if it supports the ADDMEMBER function, before attempting it). Cheers, Geoff Roy wrote on 02/17/2005 06:50:39 PM: > > Geoff asked what happens if the resource already supports POST > for some other purpose. The answer is one of > > 1) if the implementation supports the addmember purpose > in addition to its other duties, it will return 201 Created; > > 2) if the implementation does not allow subsidiary resources > to be created, then > > a) if the implementation is written according to HTTP, > it will return 415 Unsupported Media Type; or > > b) if the implementation is clueless, it will attempt to > parse the media type that it expects and will fail with > some form of 4xx response. [Note that this is the case > whether the method is POST or ADDMEMBER -- clueless > implementations do not check the method either.] > > c) if the implementation is totally ignorant of all things > HTTP, it will respond with 200 and a friendly error message > about how this site only works with MSIE 5 (again, > regardless of the method used). > > So, the answer to Geoff's question is a new method is not necessary > to distinguish one POST from another POST because this was already > considered by HTTP in 1992 > > http://www.w3.org/Protocols/HTTP/Methods/Post.html > > and codified in RFC 1945, 2068, and 2616. The reason it allows > the server so much leeway in its handling of the request is because > only the resource can determine, according to its own implementation > and purpose in life, the most appropriate way to store subsidiary > resources. ANY other specification would assume that an HTTP > server is just another form of file server like FTP (which is not > its purpose in life, as I've explained a million times before). > > If the client sends random unsafe requests to a Web server, > it will obtain randomly unsafe results regardless of the method > used. If the server provides a URI as an authorable resource, > then POST to a collection has the semantics of adding a member > to that collection -- the semantics have not changed just because > webdav chose to ignore that feature of HTTP. > > ....Roy > > --=_alternative 001C76B685256FAC_= Content-Type: text/html; charset="US-ASCII"
My main concern is that because of the popularity of SOAP,
many/most implementations fall into category 2b (i.e., "clueless"),
so a resource will say that it supports the POST operation,
but will actually fail it with some kind of 4xx response
because it cannot parse the body, or in the worst case,
will successfully parse the body and execute some potentially
harmful SOAP operation that was never intended by the client
(the client just wanted a subsidiary whose content was that body
to be created).

I'm rather surprised that clueless (e.g., SOAP :-) implementations
would parse the body of an unknown method (e.g., ADDMEMBER)
and treat it as if it were a POST call.  I would have expected
SOAP implementations to limit themselves to parsing only POST bodies.
But Roy knows way more about that kind of thing than I do ...  

But even if a clueless implementation will try to parse the
body of an unknown method like ADDMEMBER, I assume it is very
unlikely that it would say that it supports the ADDMEMBER
method on that resource, so that at least would give the client
a way of avoiding the problem (i.e., by first asking the resource
if it supports the ADDMEMBER function, before attempting it).

Cheers,
Geoff


Roy wrote on 02/17/2005 06:50:39 PM:
>
> Geoff asked what happens if the resource already supports POST
> for some other purpose.  The answer is one of
>
>     1) if the implementation supports the addmember purpose
>        in addition to its other duties, it will return 201 Created;
>
>     2) if the implementation does not allow subsidiary resources
>        to be created, then
>
>        a) if the implementation is written according to HTTP,
>           it will return 415 Unsupported Media Type; or
>
>        b) if the implementation is clueless, it will attempt to
>           parse the media type that it expects and will fail with
>           some form of 4xx response. [Note that this is the case
>           whether the method is POST or ADDMEMBER -- clueless
>           implementations do not check the method either.]
>
>        c) if the implementation is totally ignorant of all things
>           HTTP, it will respond with 200 and a friendly error message
>           about how this site only works with MSIE 5 (again,
>           regardless of the method used).
>
> So, the answer to Geoff's question is a new method is not necessary
> to distinguish one POST from another POST because this was already
> considered by HTTP in 1992
>
>    http://www.w3.org/Protocols/HTTP/Methods/Post.html
>
> and codified in RFC 1945, 2068, and 2616.  The reason it allows
> the server so much leeway in its handling of the request is because
> only the resource can determine, according to its own implementation
> and purpose in life, the most appropriate way to store subsidiary
> resources.  ANY other specification would assume that an HTTP
> server is just another form of file server like FTP (which is not
> its purpose in life, as I've explained a million times before).
>
> If the client sends random unsafe requests to a Web server,
> it will obtain randomly unsafe results regardless of the method
> used.  If the server provides a URI as an authorable resource,
> then POST to a collection has the semantics of adding a member
> to that collection -- the semantics have not changed just because
> webdav chose to ignore that feature of HTTP.
>
> ....Roy
>
>
--=_alternative 001C76B685256FAC_=-- From w3c-dist-auth-request@w3.org Fri Feb 18 03:28:42 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04637 for ; Fri, 18 Feb 2005 03:28:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D23T6-00063s-JV for w3c-dist-auth-dist@listhub.w3.org; Fri, 18 Feb 2005 08:26:32 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D23T4-00062b-NF for w3c-dist-auth@listhub.w3.org; Fri, 18 Feb 2005 08:26:30 +0000 Received: from [217.5.201.10] (helo=greenbytes.de) by bart.w3.org with esmtp (Exim 4.34) id 1D23T4-0003gw-C0 for w3c-dist-auth@w3c.org; Fri, 18 Feb 2005 08:26:30 +0000 Received: from [192.168.1.26] by greenbytes.de (Cipher TLSv1:RC4-MD5:128) (MDaemon.PRO.v7.2.3.R) with ESMTP id md50000083986.msg for ; Fri, 18 Feb 2005 09:25:58 +0100 In-Reply-To: <42150C83.7030301@gmx.de> References: <200502172104.j1HL4lXX013061@services.cse.ucsc.edu> <574c8b49ef70b65d510ad7bcf57d0b63@opengroupware.org> <42150C83.7030301@gmx.de> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7a0fc7fb8ebc2d8bc22664488307dc07@greenbytes.de> Content-Transfer-Encoding: 7bit Cc: "'Webdav WG'" , Helge Hess From: Stefan Eissing Date: Fri, 18 Feb 2005 09:26:10 +0100 To: Julian Reschke X-Mailer: Apple Mail (2.619.2) X-Authenticated-Sender: se@greenbytes.de X-Spam-Processed: greenbytes.de, Fri, 18 Feb 2005 09:25:58 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.1.26 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Received-SPF: none (bart.w3.org: domain of stefan.eissing@greenbytes.de does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/7a0fc7fb8ebc2d8bc22664488307dc07@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9471 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 18 Feb 2005 08:26:32 +0000 Content-Transfer-Encoding: 7bit I think it is also not clear if its a hop-to-hop or end-to-end header. So chances of getting it working in an uncontrolled environment are not good. //Stefan Am 17.02.2005 um 22:28 schrieb Julian Reschke: > > Helge Hess wrote: >> On 17. Feb 2005, at 22:04 Uhr, Jim Whitehead wrote: >>> 1) One problem clients currently encounter with PUT is determining >>> whether >>> they have permission to write to a specific location. At present, a >>> client >>> must submit a PUT (or ADDMEMBER) with the entire entity body, then >>> wait for >>> the response, or the authentication challenge. >> Isn't that already solved with Expect: 100-continue? >> http://zvon.org/tmRFC/RFC2616/Output/chapter14.html#sub20 > > Sort of. The problem is that it's extremely hard to implement using > the Java servlet API (but that's "just" an implementation issue...). > > Best regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Fri Feb 18 04:00:17 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07274 for ; Fri, 18 Feb 2005 04:00:16 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D23yk-000374-Rg for w3c-dist-auth-dist@listhub.w3.org; Fri, 18 Feb 2005 08:59:14 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D23yj-00036E-By for w3c-dist-auth@listhub.w3.org; Fri, 18 Feb 2005 08:59:13 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1D23yj-0002OV-18 for w3c-dist-auth@w3c.org; Fri, 18 Feb 2005 08:59:13 +0000 Received: (qmail invoked by alias); 18 Feb 2005 08:58:40 -0000 Received: from pD9E510FD.dip.t-dialin.net (EHLO [192.168.0.3]) (217.229.16.253) by mail.gmx.net (mp019) with SMTP; 18 Feb 2005 09:58:40 +0100 X-Authenticated: #1915285 Message-ID: <4215AE3C.2070406@gmx.de> Date: Fri, 18 Feb 2005 09:58:36 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stefan Eissing CC: "'Webdav WG'" , Helge Hess References: <200502172104.j1HL4lXX013061@services.cse.ucsc.edu> <574c8b49ef70b65d510ad7bcf57d0b63@opengroupware.org> <42150C83.7030301@gmx.de> <7a0fc7fb8ebc2d8bc22664488307dc07@greenbytes.de> In-Reply-To: <7a0fc7fb8ebc2d8bc22664488307dc07@greenbytes.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/4215AE3C.2070406@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9472 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 18 Feb 2005 08:59:14 +0000 Content-Transfer-Encoding: 7bit Stefan Eissing wrote: > I think it is also not clear if its a hop-to-hop or end-to-end header. > So chances of getting it working in an uncontrolled environment are not > good. From : "The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST return a 417 (Expectation Failed) status if it receives a request with an expectation that it cannot meet. However, the Expect request-header itself is end-to-end; it MUST be forwarded if the request is forwarded." This seems to indicate that expectations not defined in RFC2616 (and the only one deployed there is "100-continue") will be next to impossible to deploy. Usage of "100-continue" shouldn't be problematic, though (expect that servers may not implement the amount of request header checking one may wish). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Feb 18 10:41:50 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18266 for ; Fri, 18 Feb 2005 10:41:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D2AF2-0002Cg-Q4 for w3c-dist-auth-dist@listhub.w3.org; Fri, 18 Feb 2005 15:40:28 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D29ka-0006du-9H for w3c-dist-auth@listhub.w3.org; Fri, 18 Feb 2005 15:09:00 +0000 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by bart.w3.org with esmtp (Exim 4.34) id 1D29j6-0005uc-VK for w3c-dist-auth@w3.org; Fri, 18 Feb 2005 15:07:29 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11894; Fri, 18 Feb 2005 10:07:24 -0500 (EST) Message-Id: <200502181507.KAA11894@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Date: Fri, 18 Feb 2005 10:07:24 -0500 Received-SPF: none (bart.w3.org: domain of dinaras@cnri.reston.va.us does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: I-D ACTION:draft-ietf-webdav-bind-11.txt X-Archived-At: http://www.w3.org/mid/200502181507.KAA11894@ietf.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9473 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 18 Feb 2005 15:40:28 +0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. Title : Binding Extensions to Web Distributed Authoring and Versioning (WebDAV) Author(s) : G. Clemm, et al. Filename : draft-ietf-webdav-bind-11.txt Pages : 41 Date : 2005-2-17 This specification defines bindings, and the BIND method for creating multiple bindings to the same resource. Creating a new binding to a resource causes at least one new URI to be mapped to that resource. Servers are required to insure the integrity of any bindings that they allow to be created. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-bind-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-webdav-bind-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-webdav-bind-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-18103529.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-bind-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-bind-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-18103529.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Fri Feb 18 11:39:44 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03363 for ; Fri, 18 Feb 2005 11:39:43 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D2B9Y-0008AH-CN for w3c-dist-auth-dist@listhub.w3.org; Fri, 18 Feb 2005 16:38:52 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D2B9W-00086p-Sq for w3c-dist-auth@listhub.w3.org; Fri, 18 Feb 2005 16:38:50 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1D2B9N-0004z7-LZ for w3c-dist-auth@w3c.org; Fri, 18 Feb 2005 16:38:41 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3c.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1IGcQaa011813 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 18 Feb 2005 08:38:28 -0800 In-Reply-To: <7a0fc7fb8ebc2d8bc22664488307dc07@greenbytes.de> References: <200502172104.j1HL4lXX013061@services.cse.ucsc.edu> <574c8b49ef70b65d510ad7bcf57d0b63@opengroupware.org> <42150C83.7030301@gmx.de> <7a0fc7fb8ebc2d8bc22664488307dc07@greenbytes.de> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Julian Reschke , "'Webdav WG'" , Helge Hess From: Lisa Dusseault Date: Fri, 18 Feb 2005 08:38:02 -0800 To: Stefan Eissing X-Mailer: Apple Mail (2.619.2) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/fbe0d45ea990814666b5ea12c4c6ea81@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9474 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 18 Feb 2005 16:38:52 +0000 Content-Transfer-Encoding: 7bit Yes, I agree there would need to be some added definition for it to work clearly and interoperably. But I can't see how the mechanism itself is flawed other than being incompletely described and unimplemented :) Lisa On Feb 18, 2005, at 12:26 AM, Stefan Eissing wrote: > > I think it is also not clear if its a hop-to-hop or end-to-end header. > So chances of getting it working in an uncontrolled environment are > not good. > > //Stefan > > Am 17.02.2005 um 22:28 schrieb Julian Reschke: > >> >> Helge Hess wrote: >>> On 17. Feb 2005, at 22:04 Uhr, Jim Whitehead wrote: >>>> 1) One problem clients currently encounter with PUT is determining >>>> whether >>>> they have permission to write to a specific location. At present, a >>>> client >>>> must submit a PUT (or ADDMEMBER) with the entire entity body, then >>>> wait for >>>> the response, or the authentication challenge. >>> Isn't that already solved with Expect: 100-continue? >>> http://zvon.org/tmRFC/RFC2616/Output/chapter14.html#sub20 >> >> Sort of. The problem is that it's extremely hard to implement using >> the Java servlet API (but that's "just" an implementation issue...). >> >> Best regards, Julian >> >> -- >> bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 >> > > > From w3c-dist-auth-request@w3.org Sat Feb 19 06:52:31 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25991 for ; Sat, 19 Feb 2005 06:52:31 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D2T7m-0006NC-V0 for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Feb 2005 11:50:14 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D2T7i-0006Le-5B for w3c-dist-auth@listhub.w3.org; Sat, 19 Feb 2005 11:50:10 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.34) id 1D2T7h-00086H-R7 for w3c-dist-auth@w3.org; Sat, 19 Feb 2005 11:50:10 +0000 Received: (qmail invoked by alias); 19 Feb 2005 11:49:37 -0000 Received: from p5082117F.dip0.t-ipconnect.de (EHLO [192.168.1.10]) (80.130.17.127) by mail.gmx.net (mp024) with SMTP; 19 Feb 2005 12:49:37 +0100 X-Authenticated: #1915285 Message-ID: <421727CB.1090404@gmx.de> Date: Sat, 19 Feb 2005 12:49:31 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: webdav CC: Joe Hildebrand References: <1aef7c87a3636e35da541fba00215c3c@jabber.com> <4204026B.1070104@gmx.de> <420BD326.4090805@gmx.de> In-Reply-To: <420BD326.4090805@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Status of working group last call on BIND X-Archived-At: http://www.w3.org/mid/421727CB.1090404@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9475 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 19 Feb 2005 11:50:14 +0000 Content-Transfer-Encoding: 7bit OK, as announced one week ago, I have submitted the current draft text as version -11. As far as I can tell, all issues that have been raised during the working group last call should be closed according to the procedure outlined by Joe (). Three additional issues were raised after last call. They have been answered, and there was no further discussion since (> 2 weeks ago). Also, they don't have any votes in the issue tracker, so they should be closed as well. Thus, it seems we're done WGLC-wise. The next step now is to submit this draft for publication as RFC, which will result in another last call in which possibly remaining issues can be raised. Joe, Lisa? Best regards, Julian > > Julian Reschke wrote: > >> Thanks Joe, >> >> from my p.o.v.: >> >> #2) Should be closed: consensus for the change made with >> >> >> >> #5) Should be closed: has 0 votes on it >> >> #71) Should be closed: has only 1 vote on it from Elias, and he's >> satisfied with the explanations and changes made >> (). >> >> >> #71b) The question raised by you, Joe, in >> >> is IMHO a distinct issue, it's being tracked with >> , >> you may want to open a new BugZilla issue if you feel that there's a >> risk that we're not following up properly. >> >> >> Regarding the three issues raised post-last-call: please give guidance >> on how to proceed. So far, there aren't any votes on them, and it >> doesn't seem any new feedback is coming in. I think we still should >> plan to submit a document for publication in time before the IETF, >> which is roughly two weeks from now. > > > I note that no further discussion has taken place since the issues were > entered (and replied to). There are also no votes on them so far. > > Unless there's any new discussion on these topics, I'll submit the > current spec before the end of the next week and ask the WG chairs to > submit it to the IESG for last call. > > Best regards, Julian > -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Feb 21 17:09:23 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20454 for ; Mon, 21 Feb 2005 17:09:23 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D3Lhv-000741-Kj for w3c-dist-auth-dist@listhub.w3.org; Mon, 21 Feb 2005 22:07:11 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D3Lht-00073J-4z for w3c-dist-auth@listhub.w3.org; Mon, 21 Feb 2005 22:07:09 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1D3Lhs-0002oL-7b for w3c-dist-auth@w3.org; Mon, 21 Feb 2005 22:07:08 +0000 Received: (qmail invoked by alias); 21 Feb 2005 21:46:26 -0000 Received: from pD9FF0736.dip.t-dialin.net (EHLO [192.168.0.3]) (217.255.7.54) by mail.gmx.net (mp022) with SMTP; 21 Feb 2005 22:46:26 +0100 X-Authenticated: #1915285 Message-ID: <421A56A8.20905@gmx.de> Date: Mon, 21 Feb 2005 22:46:16 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jamie Lokier CC: Scott Lawrence , Cyrus Daboo , Mark Baker , "Roy T. Fielding" , WebDAV , HTTP Working Group , CalDAV DevList References: <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> <788C984DF503C81DC332E7DB@ninevah.cyrusoft.com> <4214D227.9020607@gmx.de> <1108663634.11773.28.camel@sukothai.pingtel.com> <4214E4D0.80408@gmx.de> <1108670449.11773.33.camel@sukothai.pingtel.com> <4214F973.9060404@gmx.de> <1109017914.3811.29.camel@localhost.localdomain> <20050221212838.GA8870@mail.shareable.org> In-Reply-To: <20050221212838.GA8870@mail.shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/421A56A8.20905@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9476 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 21 Feb 2005 22:07:11 +0000 Content-Transfer-Encoding: 7bit Jamie Lokier wrote: > Scott Lawrence wrote: > >>>In which case I couldn't use the content-type of my actual request body >>>for the Content-Type request header, right? >> >>I fear that I may have lost the thread of your comment... you cannot use >>Content-Type to send anything _but_ the content type of your request >>body. > > > Roy said that POST can take into account the request content type to > decide the action that is taken. > > I believe Julian wants to "create resource" with an arbitrary content > type - _without_ the content type having any effect on the action that > is taken to create the resource. Correct. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Feb 21 19:41:56 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05237 for ; Mon, 21 Feb 2005 19:41:56 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D3O5p-0008BO-V5 for w3c-dist-auth-dist@listhub.w3.org; Tue, 22 Feb 2005 00:40:01 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D3O5n-0008AT-Mt; Tue, 22 Feb 2005 00:39:59 +0000 Received: from scorpio.lunarpages.com ([64.235.234.122]) by lisa.w3.org with esmtp (Exim 4.34) id 1D3O5n-0006qP-Hs; Tue, 22 Feb 2005 00:39:59 +0000 Received: from wsip-24-248-98-242.oc.oc.cox.net ([24.248.98.242] helo=[10.2.8.58]) by scorpio.lunarpages.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.44) id 1D3O0m-00085Q-0k; Mon, 21 Feb 2005 16:34:48 -0800 In-Reply-To: <421A56A8.20905@gmx.de> References: <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> <788C984DF503C81DC332E7DB@ninevah.cyrusoft.com> <4214D227.9020607@gmx.de> <1108663634.11773.28.camel@sukothai.pingtel.com> <4214E4D0.80408@gmx.de> <1108670449.11773.33.camel@sukothai.pingtel.com> <4214F973.9060404@gmx.de> <1109017914.3811.29.camel@localhost.localdomain> <20050221212838.GA8870@mail.shareable.org> <421A56A8.20905@gmx.de> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: HTTP Working Group , CalDAV DevList , WebDAV WG From: "Roy T. Fielding" Date: Mon, 21 Feb 2005 16:34:48 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.619.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - scorpio.lunarpages.com X-AntiAbuse: Original Domain - w3.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - gbiv.com Received-SPF: none (lisa.w3.org: domain of fielding@gbiv.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/c844ba079656823c4c2389f174aaa6af@gbiv.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9477 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 22 Feb 2005 00:40:01 +0000 Content-Transfer-Encoding: 7bit On Feb 21, 2005, at 1:46 PM, Julian Reschke wrote: > Jamie Lokier wrote: >> I believe Julian wants to "create resource" with an arbitrary content >> type - _without_ the content type having any effect on the action that >> is taken to create the resource. > > Correct. General-purpose HTTP servers will not allow that for security reasons. They use the media type internally as an extensibility mechanism. ....Roy From w3c-dist-auth-request@w3.org Mon Feb 21 22:54:05 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28397 for ; Mon, 21 Feb 2005 22:54:05 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D3R6E-0002gq-VT for w3c-dist-auth-dist@listhub.w3.org; Tue, 22 Feb 2005 03:52:39 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D3R69-0002fX-Fs; Tue, 22 Feb 2005 03:52:33 +0000 Received: from [216.126.80.155] (helo=bork.markbaker.ca) by lisa.w3.org with esmtp (Exim 4.34) id 1D3R69-00005Y-BB; Tue, 22 Feb 2005 03:52:33 +0000 Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian)) id 1D3R0h-0007zY-00; Mon, 21 Feb 2005 22:46:55 -0500 Date: Mon, 21 Feb 2005 22:46:55 -0500 From: Mark Baker To: Scott Lawrence Cc: WebDAV , HTTP Working Group , CalDAV DevList Message-ID: <20050222034655.GC4504@markbaker.ca> References: <20050217164142.GA17013@mail.shareable.org> <788C984DF503C81DC332E7DB@ninevah.cyrusoft.com> <4214D227.9020607@gmx.de> <1108663634.11773.28.camel@sukothai.pingtel.com> <4214E4D0.80408@gmx.de> <1108670449.11773.33.camel@sukothai.pingtel.com> <4214F973.9060404@gmx.de> <1109017914.3811.29.camel@localhost.localdomain> <20050221212838.GA8870@mail.shareable.org> <1109040989.3811.39.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1109040989.3811.39.camel@localhost.localdomain> User-Agent: Mutt/1.5.6+20040907i Received-SPF: none (lisa.w3.org: domain of distobj@acm.org does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/20050222034655.GC4504@markbaker.ca Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9478 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 22 Feb 2005 03:52:38 +0000 Scott, On Mon, Feb 21, 2005 at 09:56:29PM -0500, Scott Lawrence wrote: > You already have what you need in POST - > defining a new method does not add any new capability Let me ask this; why do we have PUT when a valid effect of a POST could also be to set the state of a resource? IMO, it's because there are advantages to having messages which reflect the expectations of their sender. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca From w3c-dist-auth-request@w3.org Mon Feb 21 23:26:32 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02634 for ; Mon, 21 Feb 2005 23:26:32 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D3Rc6-0005aS-0T for w3c-dist-auth-dist@listhub.w3.org; Tue, 22 Feb 2005 04:25:34 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D3Rc3-0005YQ-Qt; Tue, 22 Feb 2005 04:25:31 +0000 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by lisa.w3.org with esmtp (Exim 4.34) id 1D3Rc3-0001mo-JK; Tue, 22 Feb 2005 04:25:31 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j1M4P0pf014360; Mon, 21 Feb 2005 23:25:00 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1M4P0ew057098; Mon, 21 Feb 2005 23:25:00 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1M4OxFa007692; Mon, 21 Feb 2005 23:24:59 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1M4Ox1C007689; Mon, 21 Feb 2005 23:24:59 -0500 In-Reply-To: <20050221213247.GB8870@mail.shareable.org> To: Jamie Lokier Cc: CalDAV DevList , HTTP Working Group , WebDAV MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Mon, 21 Feb 2005 21:24:50 -0700 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 02/21/2005 23:24:58, Serialize complete at 02/21/2005 23:24:58 Content-Type: multipart/alternative; boundary="=_alternative 007C976387256FAF_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.145 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: draft-reschke-http-addmember-00 X-Archived-At: http://www.w3.org/mid/OF37A764C1.8369E90C-ON85256FAF.007C29A8-87256FB0.0018408A@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9479 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 22 Feb 2005 04:25:34 +0000 This is a multipart message in MIME format. --=_alternative 007C976387256FAF_= Content-Type: text/plain; charset="US-ASCII" Jamie Lokier wrote on 02/21/2005 02:32:47 PM: > Geoffrey M Clemm wrote: > > But even if a clueless implementation will try to parse the > > body of an unknown method like ADDMEMBER, I assume it is very > > unlikely that it would say that it supports the ADDMEMBER > > method on that resource, so that at least would give the client > > a way of avoiding the problem (i.e., by first asking the resource > > if it supports the ADDMEMBER function, before attempting it). > > I think that's a reasonable assumption. > > But you should always try to avoid accessing unknown resources, even > to query their capabilities: There are implementations where sending > OPTIONS to them will be interpreted as a POST or stateful GET :) I'm not sure what you mean by "avoid accessing unknown resources". The only way a client "knows" about a resource is by doing some discovery method on it such as OPTIONS. Cheers, Geoff --=_alternative 007C976387256FAF_= Content-Type: text/html; charset="US-ASCII"
Jamie Lokier <jamie@shareable.org> wrote on 02/21/2005 02:32:47 PM:
> Geoffrey M Clemm wrote:
> >    But even if a clueless implementation will try to parse the
> >    body of an unknown method like ADDMEMBER, I assume it is very
> >    unlikely that it would say that it supports the ADDMEMBER
> >    method on that resource, so that at least would give the client
> >    a way of avoiding the problem (i.e., by first asking the resource
> >    if it supports the ADDMEMBER function, before attempting it).
>
> I think that's a reasonable assumption.
>
> But you should always try to avoid accessing unknown resources, even
> to query their capabilities:  There are implementations where sending
> OPTIONS to them will be interpreted as a POST or stateful GET :)
I'm not sure what you mean by "avoid accessing unknown resources".
The only way a client "knows" about a resource is by doing some discovery
method on it such as OPTIONS.

Cheers,
Geoff
--=_alternative 007C976387256FAF_=-- From w3c-dist-auth-request@w3.org Tue Feb 22 00:35:04 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11786 for ; Tue, 22 Feb 2005 00:35:04 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D3SgG-0002zL-LX for w3c-dist-auth-dist@listhub.w3.org; Tue, 22 Feb 2005 05:33:56 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D3Sg9-0002vb-8b; Tue, 22 Feb 2005 05:33:49 +0000 Received: from rgminet03.oracle.com ([148.87.122.32]) by lisa.w3.org with esmtp (Exim 4.34) id 1D3Sg2-0008Kj-FF; Tue, 22 Feb 2005 05:33:48 +0000 Received: from rgminet03.oracle.com (localhost [127.0.0.1]) by rgminet03.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j1M5RWe4005462; Tue, 22 Feb 2005 00:27:32 -0500 Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.191.50]) by rgminet03.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j1M5JhAL030322; Tue, 22 Feb 2005 00:22:02 -0500 Received: from localhost (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id j1M5Jg3J030789; Mon, 21 Feb 2005 22:19:42 -0700 Received: from [192.168.1.200] (dhcp-amer-csvpn-gw1-141-144-65-231.vpn.oracle.com [141.144.65.231]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j1M5JNNk030569 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 21 Feb 2005 22:19:24 -0700 Message-ID: <421AC0DB.6000001@oracle.com> Date: Tue, 22 Feb 2005 00:19:23 -0500 From: Bernard Desruisseaux User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, fr-ca MIME-Version: 1.0 To: WebDAV , HTTP Working Group , CalDAV DevList CC: Cyrus Daboo , Julian Reschke , "Roy T. Fielding" , Mark Baker References: <4211E442.40209@gmx.de> <27514C16D36854827D284790@ninevah.cyrusoft.com> <42121E4A.3080007@gmx.de> <62F35864CD746B25C06E1A19@ninevah.cyrusoft.com> <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE Received-SPF: none (lisa.w3.org: domain of bernard.desruisseaux@oracle.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/421AC0DB.6000001@oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9480 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 22 Feb 2005 05:33:56 +0000 Content-Transfer-Encoding: 7bit Ideally we would have a solution that would work for all methods that may request the creation of a new resource (e.g, LOCK, PUT, COPY, MOVE, MKCOL, MKWORKSPACE, MKACTIVITY, MKCALENDAR, ...). Could the solution be as simple as specifying an empty query component (e.g., "?") in the Request-URI for those methods, and have the methods return the Location header as part of their response? For instance, PUT /calendar/bernard/? would request the server to create a new resource in the collection /calendar/bernard/ and let the server chose the name of the resource. Is there already a defined use for the query component for the methods mentionned above? Cheers, Bernard Cyrus Daboo wrote: > > > > > Hi Julian, > > --On February 17, 2005 2:54:38 PM +0100 Julian Reschke > wrote: > >> 1) CalDav's approach is: use PUT to an arbitrary member URI of the >> container; then let the server automagically move it somewhere else, and >> report that in the Location response header >> (> fc.section.A.2>). > > > I want to add that in the CalDAV case this URI naming restriction will > also apply to COPY and MOVE methods too, not just PUT. So we do need to > come up with a solution that at least works with those methods too. Of > course it is possible to emulate COPY and MOVE using PUT (client > downloads original data, creates it in new location) and DELETE (remove > old data in the case of MOVE) - but we should really have the proper > atomic operations for this. > From w3c-dist-auth-request@w3.org Tue Feb 22 03:27:34 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25277 for ; Tue, 22 Feb 2005 03:27:34 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D3VMx-0003WX-BY for w3c-dist-auth-dist@listhub.w3.org; Tue, 22 Feb 2005 08:26:11 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D3VMu-0003Vw-5Q; Tue, 22 Feb 2005 08:26:08 +0000 Received: from scorpio.lunarpages.com ([64.235.234.122]) by lisa.w3.org with esmtp (Exim 4.34) id 1D3VMt-00052H-TV; Tue, 22 Feb 2005 08:26:08 +0000 Received: from ip68-4-71-218.oc.oc.cox.net ([68.4.71.218] helo=[192.168.0.100]) by scorpio.lunarpages.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.44) id 1D3VI2-0005f2-1X; Tue, 22 Feb 2005 00:21:06 -0800 In-Reply-To: <20050222034655.GC4504@markbaker.ca> References: <20050217164142.GA17013@mail.shareable.org> <788C984DF503C81DC332E7DB@ninevah.cyrusoft.com> <4214D227.9020607@gmx.de> <1108663634.11773.28.camel@sukothai.pingtel.com> <4214E4D0.80408@gmx.de> <1108670449.11773.33.camel@sukothai.pingtel.com> <4214F973.9060404@gmx.de> <1109017914.3811.29.camel@localhost.localdomain> <20050221212838.GA8870@mail.shareable.org> <1109040989.3811.39.camel@localhost.localdomain> <20050222034655.GC4504@markbaker.ca> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7d6e31bc68586bba82b76fd4fe4443ba@gbiv.com> Content-Transfer-Encoding: 7bit Cc: HTTP Working Group , CalDAV DevList , WebDAV WG From: "Roy T. Fielding" Date: Tue, 22 Feb 2005 00:21:05 -0800 To: Mark Baker X-Mailer: Apple Mail (2.619.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - scorpio.lunarpages.com X-AntiAbuse: Original Domain - w3.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - gbiv.com Received-SPF: none (lisa.w3.org: domain of fielding@gbiv.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/7d6e31bc68586bba82b76fd4fe4443ba@gbiv.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9481 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 22 Feb 2005 08:26:11 +0000 Content-Transfer-Encoding: 7bit On Feb 21, 2005, at 7:46 PM, Mark Baker wrote: > Let me ask this; why do we have PUT when a valid effect of a POST > could also be to set the state of a resource? Because PUT means set the state of this resource, whereas POST does not. > IMO, it's because there are advantages to having messages which reflect > the expectations of their sender. Umm, think about that sentence and you will find it has no content. Messages reflect the instruction of the sender. POST does that. What you are really saying is that there are advantages to the client knowing the nature of a resource, encoding that nature into the set of methods used, and thus forcing how its state will be impacted by each messaged action. That is what Julian wants in an ADDMEMBER method. You, of all people, should be the first to recognize that slippery slope. Yes, it has advantages, but it also has far-reaching disadvantages that HTTP was designed to prevent. It causes clients to become coupled to particular "types" of resources on the server, which is just another from of implementation-dependency. It leads to absolutely moronic implementations that have to test each resource for the set of methods it implements before performing a set of actions that would have the same result as a generic POST. [Which is to say that it will suck every bit as much as the other methods introduced by webdav and its prodigy that created arbitrary resource types for collections, versions, and now calendars.] POST, in contrast, is a generic semantic that allows the resource to determine its implementation-specific effects. POST to a collection means add a member. POST to a PUT-able resource means an atomic append. POST to a messaging gateway means "post this". POST to any other resource means "process this". Note, however, that to a client they all mean the same thing: take this data and apply it in accordance with your nature. The client does not need to know anything more because the client already knows what it wants to do (and knowing more cannot help it, since only the server is allowed to know the implementation). PUT versus PATCH might lead you to an interesting comparison, at least in terms of seeing when two methods do have different semantics. A better example is POST versus PATCH, given that PATCHing a collection could be defined as a set of add/remove operations on the collection state. One could easily define a patch media type for that, but there are also good reasons not to. POST versus ADDMEMBER, however, does not compare at all because POST is already defined to be "add a member." POST only seems to have multiple definitions because the other definitions are examples of various forms of partial state change within a resource that may consist of identifiable subcomponents. It is really just one semantic definition that manifests in different ways based upon how the implementer views the resource to which the POST is applied. A file is just an ordered collection of bytes. A collection is just a file with a compound media type. A gateway is just a pipe, and a pipe is just a file with scrolling-window state over time. The IETF could give every form of implementation a different type and every type its own set of methods for manipulating state, but all that will accomplish is the death of another protocol. And no, I don't care what SOAP does via POST, since SOAP has already proven to be a miserable failure. Cheers, Roy T. Fielding Chief Scientist, Day Software From w3c-dist-auth-request@w3.org Tue Feb 22 08:41:23 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00348 for ; Tue, 22 Feb 2005 08:41:19 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D3aFK-00012v-1W for w3c-dist-auth-dist@listhub.w3.org; Tue, 22 Feb 2005 13:38:38 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D3aFH-000121-PZ; Tue, 22 Feb 2005 13:38:35 +0000 Received: from [216.126.80.155] (helo=bork.markbaker.ca) by lisa.w3.org with esmtp (Exim 4.34) id 1D3aFH-0008KC-LI; Tue, 22 Feb 2005 13:38:35 +0000 Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian)) id 1D3aEg-0001BI-00; Tue, 22 Feb 2005 08:37:58 -0500 Date: Tue, 22 Feb 2005 08:37:58 -0500 From: Mark Baker To: "Roy T. Fielding" Cc: HTTP Working Group , CalDAV DevList , WebDAV WG Message-ID: <20050222133758.GD4504@markbaker.ca> References: <4214D227.9020607@gmx.de> <1108663634.11773.28.camel@sukothai.pingtel.com> <4214E4D0.80408@gmx.de> <1108670449.11773.33.camel@sukothai.pingtel.com> <4214F973.9060404@gmx.de> <1109017914.3811.29.camel@localhost.localdomain> <20050221212838.GA8870@mail.shareable.org> <1109040989.3811.39.camel@localhost.localdomain> <20050222034655.GC4504@markbaker.ca> <7d6e31bc68586bba82b76fd4fe4443ba@gbiv.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7d6e31bc68586bba82b76fd4fe4443ba@gbiv.com> User-Agent: Mutt/1.5.6+20040907i Received-SPF: none (lisa.w3.org: domain of distobj@acm.org does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/20050222133758.GD4504@markbaker.ca Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9482 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 22 Feb 2005 13:38:38 +0000 On Tue, Feb 22, 2005 at 12:21:05AM -0800, Roy T. Fielding wrote: > >IMO, it's because there are advantages to having messages which reflect > >the expectations of their sender. > > Umm, think about that sentence and you will find it has no content. > Messages reflect the instruction of the sender. POST does that. > > What you are really saying is that there are advantages to the > client knowing the nature of a resource, [lots of other stuff that I agree with snipped] Ah, so you're saying that ADDMEMBER isn't uniform? Sorry, I wasn't able to extract that from your other messages. But can you please explain your reasoning behind that belief? From my POV, the draft defines ADDMEMBER semantics to be a small, (seemingly) uniform adjustment upon PUT semantics. Can you give an example of a resource for which ADDMEMBER wouldn't make sense? Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca From w3c-dist-auth-request@w3.org Tue Feb 22 11:38:01 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19497 for ; Tue, 22 Feb 2005 11:38:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D3d1d-0007yU-Pp for w3c-dist-auth-dist@listhub.w3.org; Tue, 22 Feb 2005 16:36:41 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D3d1a-0007xM-IO for w3c-dist-auth@listhub.w3.org; Tue, 22 Feb 2005 16:36:38 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1D3d1a-00047S-7r for w3c-dist-auth@w3.org; Tue, 22 Feb 2005 16:36:38 +0000 Received: (qmail invoked by alias); 22 Feb 2005 16:36:05 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.87]) (217.5.201.10) by mail.gmx.net (mp028) with SMTP; 22 Feb 2005 17:36:05 +0100 X-Authenticated: #1915285 Message-ID: <421B5F72.6070806@gmx.de> Date: Tue, 22 Feb 2005 17:36:02 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jamie Lokier CC: Geoffrey M Clemm , WebDAV , CalDAV DevList , HTTP Working Group References: <20050221213247.GB8870@mail.shareable.org> <20050222161520.GA22555@mail.shareable.org> In-Reply-To: <20050222161520.GA22555@mail.shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] Re: draft-reschke-http-addmember-00 X-Archived-At: http://www.w3.org/mid/421B5F72.6070806@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9483 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 22 Feb 2005 16:36:41 +0000 Content-Transfer-Encoding: 7bit Jamie Lokier wrote: > Geoffrey M Clemm wrote: > >> > But you should always try to avoid accessing unknown resources, even >> > to query their capabilities: There are implementations where >> sending >> > OPTIONS to them will be interpreted as a POST or stateful GET :) >> >> I'm not sure what you mean by "avoid accessing unknown resources". >> The only way a client "knows" about a resource is by doing some >> discovery method on it such as OPTIONS. > > > No: the way a client knows about a resource is that something asks the > client to access the resource. > > For example, a WebDAV client accesses a resource because the user > tells the client to. The user is allowing the client to assume that > WebDAV methods are ok to try on the resource. You're making assumptions about the knowledge a user has that IMHO are simply questionable. For instance, a user my use IE to follow a hyperlink to an Office document, and Office will (under some circumstances) LOCK the document, and later PUT and UNLOCK it. At least 95% of the users will not be aware of what was going on technically. > A CalDAV or Atom client accesses a resource that it is told to access. > > In all cases, the client is told to try certain methods on certain > URLs, by the user (or other agent). > > If the user asks a client to try WebDAV methods on a resource that > they don't know it's safe to try WebDAV methods on, then they can > cause all sorts of havoc. If that causes havoc, that's because the server is broken (be it misconfigured or just buggy). > For example, some URLs will treat any method as form submission, even > OPTIONS, so users should never ask a client which uses OPTIONS to > access those URLs, because that is dangerous. See above. > There is simply no way for the client to "discover" whether a given > URL supports the behaviour it's been asked to do, without causing > potential harmful side effects. Jamie, lots of clients are doing this today. I'm not aware of any "havoc" causing this. > This is why the client has to assume the user gave it a URL with known > behaviour in the first place. > > This is why a client whose job is "add a member to a collection" may > _assume_ that it's ok to use POST for this, if POST is specified as > having the right behaviour _on that resource_. So what do I do if a have a resource that accepts HTML form posts, SOAP requests and ADDMEMBER-like semantics on the same URL? > The only technical reason why a new method would be required in HTTP > is if the message semantics were different. For example, POST is Of course. That's why they are defined to be different from POST. > ... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Feb 22 11:51:02 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20729 for ; Tue, 22 Feb 2005 11:51:02 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D3dEf-0000jK-Kl for w3c-dist-auth-dist@listhub.w3.org; Tue, 22 Feb 2005 16:50:09 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D3dEe-0000iB-Nn for w3c-dist-auth@listhub.w3.org; Tue, 22 Feb 2005 16:50:08 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1D3dEe-0003vY-C9 for w3c-dist-auth@w3.org; Tue, 22 Feb 2005 16:50:08 +0000 Received: (qmail invoked by alias); 22 Feb 2005 16:49:36 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.87]) (217.5.201.10) by mail.gmx.net (mp023) with SMTP; 22 Feb 2005 17:49:36 +0100 X-Authenticated: #1915285 Message-ID: <421B629E.4090303@gmx.de> Date: Tue, 22 Feb 2005 17:49:34 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Roy T. Fielding" CC: HTTP Working Group , CalDAV DevList , WebDAV WG References: <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> <788C984DF503C81DC332E7DB@ninevah.cyrusoft.com> <4214D227.9020607@gmx.de> <1108663634.11773.28.camel@sukothai.pingtel.com> <4214E4D0.80408@gmx.de> <1108670449.11773.33.camel@sukothai.pingtel.com> <4214F973.9060404@gmx.de> <1109017914.3811.29.camel@localhost.localdomain> <20050221212838.GA8870@mail.shareable.org> <421A56A8.20905@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/421B629E.4090303@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9484 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 22 Feb 2005 16:50:09 +0000 Content-Transfer-Encoding: 7bit Roy T. Fielding wrote: > > On Feb 21, 2005, at 1:46 PM, Julian Reschke wrote: > >> Jamie Lokier wrote: >> >>> I believe Julian wants to "create resource" with an arbitrary content >>> type - _without_ the content type having any effect on the action that >>> is taken to create the resource. >> >> >> Correct. > > > General-purpose HTTP servers will not allow that for security > reasons. They use the media type internally as an extensibility > mechanism. Yes. But I'm not speaking of general-purpose servers, but of servers that *do* want to allow that (just like every off-the-shelf WebDAV server). Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Feb 22 12:11:06 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24209 for ; Tue, 22 Feb 2005 12:11:05 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D3dYE-00010K-QY for w3c-dist-auth-dist@listhub.w3.org; Tue, 22 Feb 2005 17:10:22 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D3dOk-0003x6-Ic for w3c-dist-auth@listhub.w3.org; Tue, 22 Feb 2005 17:00:34 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1D3dLa-0008R5-M0 for w3c-dist-auth@w3.org; Tue, 22 Feb 2005 16:57:18 +0000 Received: (qmail invoked by alias); 22 Feb 2005 16:56:46 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.87]) (217.5.201.10) by mail.gmx.net (mp008) with SMTP; 22 Feb 2005 17:56:46 +0100 X-Authenticated: #1915285 Message-ID: <421B644C.4020806@gmx.de> Date: Tue, 22 Feb 2005 17:56:44 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Lawrence CC: Jamie Lokier , Cyrus Daboo , Mark Baker , "Roy T. Fielding" , WebDAV , HTTP Working Group , CalDAV DevList References: <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> <788C984DF503C81DC332E7DB@ninevah.cyrusoft.com> <4214D227.9020607@gmx.de> <1108663634.11773.28.camel@sukothai.pingtel.com> <4214E4D0.80408@gmx.de> <1108670449.11773.33.camel@sukothai.pingtel.com> <4214F973.9060404@gmx.de> <1109017914.3811.29.camel@localhost.localdomain> <20050221212838.GA8870@mail.shareable.org> <1109040989.3811.39.camel@localhost.localdomain> In-Reply-To: <1109040989.3811.39.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/421B644C.4020806@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9485 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 22 Feb 2005 17:10:22 +0000 Content-Transfer-Encoding: 7bit Scott Lawrence wrote: > On Mon, 2005-02-21 at 21:28 +0000, Jamie Lokier wrote: > >>Scott Lawrence wrote: >> >>>>In which case I couldn't use the content-type of my actual request body >>>>for the Content-Type request header, right? >>> >>>I fear that I may have lost the thread of your comment... you cannot use >>>Content-Type to send anything _but_ the content type of your request >>>body. >> >>Roy said that POST can take into account the request content type to >>decide the action that is taken. >> >>I believe Julian wants to "create resource" with an arbitrary content >>type - _without_ the content type having any effect on the action that >>is taken to create the resource. > > > But setting the content type of the resulting resource _is_ having an > effect !?! > > The point that I think Roy and I have both failed to communicate is > this: POST does not in itself define what happens - the thing to which > the request is POSTed (identified by the full URL) makes that decision. Well :-) I certainly am aware of that fact. That's the *reason* of proposing an alternate method that has strict semantics instead. > That thing is free to use the URL, the content body, the time of day, > the phase of the moon, or whatever it wants to when deciding what to do > with the resource _and_you_get_to_choose_ because you are creating that > thing. If you want to define how you use POST in such a way that you > say that the Content-Type of the body should be preserved in the new > resource you are adding to the server, that's fine. If you want to post > an entity body in the request that encapsulates metadata about the > resource with the resource itself (as is done in rfc1867 form file > upload), that's fine too. You already have what you need in POST - > defining a new method does not add any new capability - it just adds > ambiguity for the servers that don't know what it is (all intermediate > systems already know that POST is not idempotent and the response to it > can only be cached if the response so indicates - that's all you need). I am fully aware that the desired semantics *can* be achieved with a well-defined message used with POST. The issue is that if multiple protocols (such as Caldav or Atompub) want to use the same semantics, it would be nice if they could use the same format, so that general purpose servers can take advantage of that. Whether that is some specific kind of POST, ADDMEMBER or PUT+Redirect (already dissed by Roy :-) is a separate issue here. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Feb 22 12:11:23 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24239 for ; Tue, 22 Feb 2005 12:11:22 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D3dYi-0001qW-Kl for w3c-dist-auth-dist@listhub.w3.org; Tue, 22 Feb 2005 17:10:52 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D3dYh-0001pw-LM for w3c-dist-auth@listhub.w3.org; Tue, 22 Feb 2005 17:10:51 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1D3dYh-0000nZ-B2 for w3c-dist-auth@w3.org; Tue, 22 Feb 2005 17:10:51 +0000 Received: (qmail invoked by alias); 22 Feb 2005 17:10:19 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.87]) (217.5.201.10) by mail.gmx.net (mp024) with SMTP; 22 Feb 2005 18:10:19 +0100 X-Authenticated: #1915285 Message-ID: <421B6778.1080804@gmx.de> Date: Tue, 22 Feb 2005 18:10:16 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jamie Lokier CC: Geoffrey M Clemm , WebDAV , CalDAV DevList , HTTP Working Group References: <20050221213247.GB8870@mail.shareable.org> In-Reply-To: <20050221213247.GB8870@mail.shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: draft-reschke-http-addmember-00 X-Archived-At: http://www.w3.org/mid/421B6778.1080804@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9486 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 22 Feb 2005 17:10:52 +0000 Content-Transfer-Encoding: 7bit Jamie Lokier wrote: > Geoffrey M Clemm wrote: > >> My main concern is that because of the popularity of SOAP, >> many/most implementations fall into category 2b (i.e., "clueless"), >> so a resource will say that it supports the POST operation, >> but will actually fail it with some kind of 4xx response >> because it cannot parse the body, or in the worst case, >> will successfully parse the body and execute some potentially >> harmful SOAP operation that was never intended by the client >> (the client just wanted a subsidiary whose content was that body >> to be created). > > .. > >> I'm rather surprised that clueless (e.g., SOAP :-) implementations >> would parse the body of an unknown method (e.g., ADDMEMBER) >> and treat it as if it were a POST call. > > > Yes... I have seen numerous CGI implementations which parse a request > as GET or POST, even if it has another method. > > >> But even if a clueless implementation will try to parse the >> body of an unknown method like ADDMEMBER, I assume it is very >> unlikely that it would say that it supports the ADDMEMBER >> method on that resource, so that at least would give the client >> a way of avoiding the problem (i.e., by first asking the resource >> if it supports the ADDMEMBER function, before attempting it). > > > I think that's a reasonable assumption. > > But you should always try to avoid accessing unknown resources, even > to query their capabilities: There are implementations where sending > OPTIONS to them will be interpreted as a POST or stateful GET :) Jamie, I'm not sure what your point is. Of course if a server mishaves that way, a client accessing it may cause problems. But that's the problem of the server, and I don't think there's anything we can do about that when discussing HTTP based protocols. What am I missing? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Feb 22 13:54:59 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03613 for ; Tue, 22 Feb 2005 13:54:58 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D3f9S-0001lK-KM for w3c-dist-auth-dist@listhub.w3.org; Tue, 22 Feb 2005 18:52:54 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D3f9P-0001js-90 for w3c-dist-auth@listhub.w3.org; Tue, 22 Feb 2005 18:52:51 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.34) id 1D3f9O-0000Wz-UQ for w3c-dist-auth@w3.org; Tue, 22 Feb 2005 18:52:51 +0000 Received: (qmail invoked by alias); 22 Feb 2005 18:52:18 -0000 Received: from pD9FF0736.dip.t-dialin.net (EHLO [192.168.0.3]) (217.255.7.54) by mail.gmx.net (mp003) with SMTP; 22 Feb 2005 19:52:18 +0100 X-Authenticated: #1915285 Message-ID: <421B7F59.5080702@gmx.de> Date: Tue, 22 Feb 2005 19:52:09 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Lawrence CC: Jamie Lokier , Geoffrey M Clemm , WebDAV , CalDAV DevList , HTTP Working Group References: <20050221213247.GB8870@mail.shareable.org> <20050222161520.GA22555@mail.shareable.org> <421B5F72.6070806@gmx.de> <1109097394.6051.1.camel@sukothai.pingtel.com> In-Reply-To: <1109097394.6051.1.camel@sukothai.pingtel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] Re: draft-reschke-http-addmember-00 X-Archived-At: http://www.w3.org/mid/421B7F59.5080702@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9487 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 22 Feb 2005 18:52:54 +0000 Content-Transfer-Encoding: 7bit Scott Lawrence wrote: > On Tue, 2005-02-22 at 17:36 +0100, Julian Reschke wrote: > >>So what do I do if a have a resource that accepts HTML form posts, >>SOAP >>requests and ADDMEMBER-like semantics on the same URL? > > > Either: > > - Implement it very very carefully. Hm. What exactly does that mean? When POST is applied to that resource with a content type of "application/soap+xml", is it supposed to store the attached entity as a new resource (with content type "application/soap+xml", returning a Location response header with the URL of the new resource), or should it process it according to ? > or > > - Change your server organization so that they use different URLs. > >>>The only technical reason why a new method would be required in HTTP >>>is if the message semantics were different. For example, POST is >> >>Of course. That's why they are defined to be different from POST. > > > But that's just the point - from the perspective of HTTP, the proposed > ADDMEMBER is not fundamentally different from POST. No, it's a subset, thus it can not be "fundamentelly different". That's on purpose. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Feb 22 14:01:26 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04337 for ; Tue, 22 Feb 2005 14:01:26 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D3fH4-0006GQ-3h for w3c-dist-auth-dist@listhub.w3.org; Tue, 22 Feb 2005 19:00:46 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D3fGh-00066D-Fr for w3c-dist-auth@listhub.w3.org; Tue, 22 Feb 2005 19:00:23 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1D3fGh-0001x0-4C for w3c-dist-auth@w3.org; Tue, 22 Feb 2005 19:00:23 +0000 Received: (qmail invoked by alias); 22 Feb 2005 18:59:51 -0000 Received: from pD9E62405.dip.t-dialin.net (EHLO [192.168.0.3]) (217.230.36.5) by mail.gmx.net (mp018) with SMTP; 22 Feb 2005 19:59:51 +0100 X-Authenticated: #1915285 Message-ID: <421B811D.2000202@gmx.de> Date: Tue, 22 Feb 2005 19:59:41 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jamie Lokier CC: Jeffrey Mogul , CalDAV DevList , HTTP Working Group , WebDAV References: <20050222161520.GA22555@mail.shareable.org> <200502221838.j1MIc451030030@wera.hpl.hp.com> <20050222185642.GC22555@mail.shareable.org> In-Reply-To: <20050222185642.GC22555@mail.shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: draft-reschke-http-addmember-00 X-Archived-At: http://www.w3.org/mid/421B811D.2000202@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9488 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 22 Feb 2005 19:00:46 +0000 Content-Transfer-Encoding: 7bit Jamie Lokier wrote: > Jeffrey Mogul wrote: > >>If Jamie is arguing that we need to add new method because >>implementations are not compliant with the specs for the old >>methods, that seems to be a recipe for doom. > > > I'm arguing _against_ adding a new method. :-) On the other hand, arguing against new methods by principle may be a recipe for doom as well. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Feb 22 14:20:51 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06527 for ; Tue, 22 Feb 2005 14:20:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D3fZi-0004yc-Q3 for w3c-dist-auth-dist@listhub.w3.org; Tue, 22 Feb 2005 19:20:03 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D3fZd-0004rz-6a for w3c-dist-auth@listhub.w3.org; Tue, 22 Feb 2005 19:19:57 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1D3fZc-0003ud-NO for w3c-dist-auth@w3.org; Tue, 22 Feb 2005 19:19:57 +0000 Received: (qmail invoked by alias); 22 Feb 2005 19:19:24 -0000 Received: from pD9E62405.dip.t-dialin.net (EHLO [192.168.0.3]) (217.230.36.5) by mail.gmx.net (mp022) with SMTP; 22 Feb 2005 20:19:24 +0100 X-Authenticated: #1915285 Message-ID: <421B85B7.7040405@gmx.de> Date: Tue, 22 Feb 2005 20:19:19 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Roy T. Fielding" CC: HTTP Working Group , Mark Baker , CalDAV DevList , WebDAV References: <4211E442.40209@gmx.de> <27514C16D36854827D284790@ninevah.cyrusoft.com> <42121E4A.3080007@gmx.de> <62F35864CD746B25C06E1A19@ninevah.cyrusoft.com> <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/421B85B7.7040405@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9489 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 22 Feb 2005 19:20:02 +0000 Content-Transfer-Encoding: 7bit Roy T. Fielding wrote: > ... >> 1) CalDav's approach is: use PUT to an arbitrary member URI of the >> container; then let the server automagically move it somewhere else, >> and report that in the Location response header >> (> -00.html#rfc.section.A.2>). > > > That is not allowed in HTTP. Thanks for the clarification. >> 2) Atom's approach is to use service URIs to which the client can >> POST, and to discover these service URIs by parting entity (feed) >> bodies. > > > That is allowed. Sure. I didn't mean to imply otherwise. >> Somehow I have the (perhaps naive) wish that identical requirements >> should lead to common protocol constructs. >> >> 1) Seems to break PUT semantics; >> >> 2) Is specific to Atom and not applicable to other protocols. > > > No, it isn't. The client must "discover" the server's URI somehow, > whether that be via hypertext, save under dialogs, or an atom link. > They are all equivalent discovery mechanisms. When Atom does a POST > it will send a representation of an entry (which happens to be just > another resource). When a generic HTTP client does a POST it will > send a representation of a resource. > > The server receives a POST message targeting a URI and containing > a representation. It can do one of three things: 1) deny the request > with method not allowed (or any other error); 2) treat all POSTs > as the same; or 3) decide, based on the URI alone or in combination > with the representation, how to process the request. > > In all cases, the client can assume the addmember semantics of POST > without any interoperability issues. It is the server's responsibility > to provide resource references to the client that match the actions > called for by whatever it is the client is doing, and even if the > client picks some random URI the server is more than capable of > providing an appropriate response. > > Geoff asked what happens if the resource already supports POST > for some other purpose. The answer is one of > > 1) if the implementation supports the addmember purpose > in addition to its other duties, it will return 201 Created; How is it (the resource) supposed to distinguish? > 2) if the implementation does not allow subsidiary resources > to be created, then > > a) if the implementation is written according to HTTP, > it will return 415 Unsupported Media Type; or > > b) if the implementation is clueless, it will attempt to > parse the media type that it expects and will fail with > some form of 4xx response. [Note that this is the case > whether the method is POST or ADDMEMBER -- clueless > implementations do not check the method either.] > > c) if the implementation is totally ignorant of all things > HTTP, it will respond with 200 and a friendly error message > about how this site only works with MSIE 5 (again, > regardless of the method used). > > So, the answer to Geoff's question is a new method is not necessary > to distinguish one POST from another POST because this was already > considered by HTTP in 1992 > > http://www.w3.org/Protocols/HTTP/Methods/Post.html > > and codified in RFC 1945, 2068, and 2616. The reason it allows > the server so much leeway in its handling of the request is because > only the resource can determine, according to its own implementation > and purpose in life, the most appropriate way to store subsidiary > resources. ANY other specification would assume that an HTTP > server is just another form of file server like FTP (which is not > its purpose in life, as I've explained a million times before). > > If the client sends random unsafe requests to a Web server, > it will obtain randomly unsafe results regardless of the method > used. If the server provides a URI as an authorable resource, > then POST to a collection has the semantics of adding a member > to that collection -- the semantics have not changed just because > webdav chose to ignore that feature of HTTP. I still have a hard time understanding what to learn from this. It seems that we're now discussing "when to define new HTTP methods" which is definitively an interesting topic... 1) If I understand you correctly, WebDAV should have said that POST to a WebDAV collection resource indeed is the operation I called ADDMEMBER. RFC2518 says in : "Since by definition the actual function performed by POST is determined by the server and often depends on the particular resource, the behavior of POST when applied to collections cannot be meaningfully modified because it is largely undefined. Thus the semantics of POST are unmodified when applied to a collection." It would be interesting to find out how the working group came to that decision (I don't remember seeing that discussion when I went through the archives some time ago; but I may have missed it). 2) RFC2518 introduces WebDAV collections as a new resource type (with a distinct creation method, MKCOL). How would a client use the POST method (as described above) to create a new collection then? In WebDAV, the only difference between a collection and a non-collection resource is containment; thus a WebDAV collection may respond to GET with any content type the server likes. 3) RFC3253 (DeltaV) defines "VERSION-CONTROL", which is a well-defined operation that puts a resource under version control (and may be applied to WebDAV collections as well). Of course that operation *could* have been defined using POST, but assuming POST to a WebDAV collection is the same as ADDMEMBER, how could I possible use POST to do something else then? So should RFC3253 have used POST instead? If the answer is "yes", how should it have resolved the conflict between the two differing semantics that are needed? If the solution is to use different URLs for POST, what would have been a good way to discover these URLs? Wondering, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Feb 22 14:25:20 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07007 for ; Tue, 22 Feb 2005 14:25:20 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D3fe6-00075w-NE for w3c-dist-auth-dist@listhub.w3.org; Tue, 22 Feb 2005 19:24:34 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D3fe5-00074o-Ba for w3c-dist-auth@listhub.w3.org; Tue, 22 Feb 2005 19:24:33 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.34) id 1D3fe4-0004zT-W4 for w3c-dist-auth@w3.org; Tue, 22 Feb 2005 19:24:33 +0000 Received: (qmail invoked by alias); 22 Feb 2005 19:24:00 -0000 Received: from pD9E62405.dip.t-dialin.net (EHLO [192.168.0.3]) (217.230.36.5) by mail.gmx.net (mp015) with SMTP; 22 Feb 2005 20:24:00 +0100 X-Authenticated: #1915285 Message-ID: <421B86CC.7020402@gmx.de> Date: Tue, 22 Feb 2005 20:23:56 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jamie Lokier CC: Geoffrey M Clemm , WebDAV , CalDAV DevList , HTTP Working Group References: <20050221213247.GB8870@mail.shareable.org> <421B6778.1080804@gmx.de> <20050222190228.GD22555@mail.shareable.org> In-Reply-To: <20050222190228.GD22555@mail.shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: draft-reschke-http-addmember-00 X-Archived-At: http://www.w3.org/mid/421B86CC.7020402@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9490 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 22 Feb 2005 19:24:34 +0000 Content-Transfer-Encoding: 7bit Jamie Lokier wrote: > Julian Reschke wrote: > >>I'm not sure what your point is. Of course if a server mishaves that >>way, a client accessing it may cause problems. But that's the problem of >>the server, and I don't think there's anything we can do about that when >>discussing HTTP based protocols. >> >>What am I missing? > > > You're missing that when you are doing CalDAV* requests, you _know_ the > URL you are accessing is CalDAV compliant already. (* - example). How does a client do *any* kind of server feature discovery if *any* method (including things like OPTIONS) may cause harm because of broken server implementations? > If you don't know that you have big problems. Such as? > So you don't need new methods just to express "intent". > (Maybe for other reasons, but not this one). Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Feb 22 14:51:24 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10456 for ; Tue, 22 Feb 2005 14:51:23 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D3g3K-0002Ch-4N for w3c-dist-auth-dist@listhub.w3.org; Tue, 22 Feb 2005 19:50:38 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D3g3A-0002A5-5q for w3c-dist-auth@listhub.w3.org; Tue, 22 Feb 2005 19:50:28 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1D3g39-00035q-KM for w3c-dist-auth@w3.org; Tue, 22 Feb 2005 19:50:28 +0000 Received: (qmail invoked by alias); 22 Feb 2005 19:49:55 -0000 Received: from pD9E62405.dip.t-dialin.net (EHLO [192.168.0.3]) (217.230.36.5) by mail.gmx.net (mp006) with SMTP; 22 Feb 2005 20:49:55 +0100 X-Authenticated: #1915285 Message-ID: <421B8CDE.6000201@gmx.de> Date: Tue, 22 Feb 2005 20:49:50 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Roy T. Fielding" CC: Mark Baker , HTTP Working Group , CalDAV DevList , WebDAV WG References: <20050217164142.GA17013@mail.shareable.org> <788C984DF503C81DC332E7DB@ninevah.cyrusoft.com> <4214D227.9020607@gmx.de> <1108663634.11773.28.camel@sukothai.pingtel.com> <4214E4D0.80408@gmx.de> <1108670449.11773.33.camel@sukothai.pingtel.com> <4214F973.9060404@gmx.de> <1109017914.3811.29.camel@localhost.localdomain> <20050221212838.GA8870@mail.shareable.org> <1109040989.3811.39.camel@localhost.localdomain> <20050222034655.GC4504@markbaker.ca> <7d6e31bc68586bba82b76fd4fe4443ba@gbiv.com> In-Reply-To: <7d6e31bc68586bba82b76fd4fe4443ba@gbiv.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/421B8CDE.6000201@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9491 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 22 Feb 2005 19:50:38 +0000 Content-Transfer-Encoding: 7bit Roy T. Fielding wrote: > > On Feb 21, 2005, at 7:46 PM, Mark Baker wrote: > >> Let me ask this; why do we have PUT when a valid effect of a POST >> could also be to set the state of a resource? > > > Because PUT means set the state of this resource, whereas POST > does not. > >> IMO, it's because there are advantages to having messages which reflect >> the expectations of their sender. > > > Umm, think about that sentence and you will find it has no content. > Messages reflect the instruction of the sender. POST does that. Agreed. But for POST, this only seems to work where there is a tight coupling between client and server; otherwise the client will have no clue about the server will indeed do with the request. > What you are really saying is that there are advantages to the > client knowing the nature of a resource, encoding that nature > into the set of methods used, and thus forcing how its state > will be impacted by each messaged action. That is what Julian > wants in an ADDMEMBER method. You, of all people, should > be the first to recognize that slippery slope. > > Yes, it has advantages, but it also has far-reaching disadvantages > that HTTP was designed to prevent. It causes clients to become > coupled to particular "types" of resources on the server, which > is just another from of implementation-dependency. It leads to Well yes; let's take a look at WebDAV collections, part of the WebDAV requirements written down in RFC2291 (). By defining a way to discover WebDAV collections (DAV:resourcetype/DAV:collection in PROPFIND response), a client can find out whether a resource is a WebDAV collection or isn't. Also, WebDAV defines COPY and MOVE as namespace operations that take containment into account. I'm not sure why this is a problem; and in particular I'd like to know what a better solution would have been. > absolutely moronic implementations that have to test each resource > for the set of methods it implements before performing a set of > actions that would have the same result as a generic POST. Right, those are moronic implementations (because in general, a client can safely try the method and then handle HTTP's "method not allowed" status code gracefully). On the other hand, using distinct methods allows to use a discovery/failure signalling approach that uses plain HTTP (OPTIONS method, "Allow" response header, 405 status). > [Which is to say that it will suck every bit as much as the other > methods introduced by webdav and its prodigy that created arbitrary > resource types for collections, versions, and now calendars.] Nit: Versions aren't special resource types. > POST, in contrast, is a generic semantic that allows the resource > to determine its implementation-specific effects. POST to a > collection means add a member. POST to a PUT-able resource means > an atomic append. POST to a messaging gateway means "post this". Why can't a collection be PUT-able? > POST to any other resource means "process this". Note, however, > that to a client they all mean the same thing: take this data > and apply it in accordance with your nature. The client does > not need to know anything more because the client already knows > what it wants to do (and knowing more cannot help it, since > only the server is allowed to know the implementation). > > PUT versus PATCH might lead you to an interesting comparison, > at least in terms of seeing when two methods do have different > semantics. A better example is POST versus PATCH, given that > PATCHing a collection could be defined as a set of add/remove > operations on the collection state. One could easily define a > patch media type for that, but there are also good reasons not to. > > POST versus ADDMEMBER, however, does not compare at all because > POST is already defined to be "add a member." POST only seems to > have multiple definitions because the other definitions are > examples of various forms of partial state change within a > resource that may consist of identifiable subcomponents. It is > really just one semantic definition that manifests in different > ways based upon how the implementer views the resource to which > the POST is applied. A file is just an ordered collection of bytes. > A collection is just a file with a compound media type. A gateway > is just a pipe, and a pipe is just a file with scrolling-window > state over time. > > The IETF could give every form of implementation a different > type and every type its own set of methods for manipulating > state, but all that will accomplish is the death of another > protocol. And no, I don't care what SOAP does via POST, > since SOAP has already proven to be a miserable failure. OK, so that sounds to me like resources should fall into distinct categories: (A1) Collections vs (A2) Non-Collections (B1) Put-able vs (B2) Non-Put-able - resources of type A1 would understand POST request as having "ADDMEMBER" semantics - resources of type A2 can (within reason) do anything they like with POST (as long as compliant to RFC2616) - resources of type B1 will allow PUT (as defined by RFC2616) and understand POST as "append" operation Let's consider a simple WebDAV server that supports only resources of types A1 and B1. What's the recommendation to do authoring operations beyond PUT on these resources? Define new methods (such as VERSION-CONTROL) or mint new related URLs to which existing methods can be applied? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Feb 22 14:53:40 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10711 for ; Tue, 22 Feb 2005 14:53:40 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D3g5f-00039q-5h for w3c-dist-auth-dist@listhub.w3.org; Tue, 22 Feb 2005 19:53:03 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D3g5c-000392-Rt; Tue, 22 Feb 2005 19:53:00 +0000 Received: from scorpio.lunarpages.com ([64.235.234.122]) by bart.w3.org with esmtp (Exim 4.34) id 1D3g5c-0003WR-M2; Tue, 22 Feb 2005 19:53:00 +0000 Received: from ip68-4-71-218.oc.oc.cox.net ([68.4.71.218] helo=[192.168.0.100]) by scorpio.lunarpages.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.44) id 1D3g5a-0008KE-9P; Tue, 22 Feb 2005 11:52:58 -0800 In-Reply-To: <20050222133758.GD4504@markbaker.ca> References: <4214D227.9020607@gmx.de> <1108663634.11773.28.camel@sukothai.pingtel.com> <4214E4D0.80408@gmx.de> <1108670449.11773.33.camel@sukothai.pingtel.com> <4214F973.9060404@gmx.de> <1109017914.3811.29.camel@localhost.localdomain> <20050221212838.GA8870@mail.shareable.org> <1109040989.3811.39.camel@localhost.localdomain> <20050222034655.GC4504@markbaker.ca> <7d6e31bc68586bba82b76fd4fe4443ba@gbiv.com> <20050222133758.GD4504@markbaker.ca> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: HTTP Working Group , CalDAV DevList , WebDAV WG From: "Roy T. Fielding" Date: Tue, 22 Feb 2005 11:52:55 -0800 To: Mark Baker X-Mailer: Apple Mail (2.619.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - scorpio.lunarpages.com X-AntiAbuse: Original Domain - w3.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - gbiv.com Received-SPF: none (bart.w3.org: domain of fielding@gbiv.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/c126af63ffe0c6f778badbaf438ca38c@gbiv.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9492 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 22 Feb 2005 19:53:03 +0000 Content-Transfer-Encoding: 7bit On Feb 22, 2005, at 5:37 AM, Mark Baker wrote: > Ah, so you're saying that ADDMEMBER isn't uniform? Actually, no, I was saying that ADDMEMBER as currently defined is identical to POST. Julian said that it wasn't identical because his client would be able to expect one semantic, namely that a 201 result would cause the webdav collection to contain a new member with the given media type. That implies an additional requirement that the target be a webdav collection, which isn't uniform at all. > Can you give an example of a resource > for which ADDMEMBER wouldn't make sense? No, which is why it is POST by any other name. ....Roy From w3c-dist-auth-request@w3.org Tue Feb 22 15:03:35 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11972 for ; Tue, 22 Feb 2005 15:03:35 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D3gEy-0008Gl-ME for w3c-dist-auth-dist@listhub.w3.org; Tue, 22 Feb 2005 20:02:40 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D3gEx-0008Be-CK for w3c-dist-auth@listhub.w3.org; Tue, 22 Feb 2005 20:02:39 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1D3gEu-0005PC-0n for w3c-dist-auth@w3.org; Tue, 22 Feb 2005 20:02:36 +0000 Received: (qmail invoked by alias); 22 Feb 2005 20:02:03 -0000 Received: from pD9E62405.dip.t-dialin.net (EHLO [192.168.0.3]) (217.230.36.5) by mail.gmx.net (mp018) with SMTP; 22 Feb 2005 21:02:03 +0100 X-Authenticated: #1915285 Message-ID: <421B8FB3.6050102@gmx.de> Date: Tue, 22 Feb 2005 21:01:55 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Roy T. Fielding" CC: Mark Baker , HTTP Working Group , CalDAV DevList , WebDAV WG References: <4214D227.9020607@gmx.de> <1108663634.11773.28.camel@sukothai.pingtel.com> <4214E4D0.80408@gmx.de> <1108670449.11773.33.camel@sukothai.pingtel.com> <4214F973.9060404@gmx.de> <1109017914.3811.29.camel@localhost.localdomain> <20050221212838.GA8870@mail.shareable.org> <1109040989.3811.39.camel@localhost.localdomain> <20050222034655.GC4504@markbaker.ca> <7d6e31bc68586bba82b76fd4fe4443ba@gbiv.com> <20050222133758.GD4504@markbaker.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/421B8FB3.6050102@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9493 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 22 Feb 2005 20:02:40 +0000 Content-Transfer-Encoding: 7bit Roy T. Fielding wrote: > > On Feb 22, 2005, at 5:37 AM, Mark Baker wrote: > >> Ah, so you're saying that ADDMEMBER isn't uniform? > > > Actually, no, I was saying that ADDMEMBER as currently defined > is identical to POST. Julian said that it wasn't identical because > his client would be able to expect one semantic, namely that a > 201 result would cause the webdav collection to contain a new > member with the given media type. That implies an additional > requirement that the target be a webdav collection, which isn't > uniform at all. I'm not sure how you get to that conclusion. ADDMEMBER (as proposed) doesn't require the target resouce to be a WebDAV collection. > ... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Feb 22 15:49:15 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18435 for ; Tue, 22 Feb 2005 15:49:14 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D3gxJ-0006AS-KU for w3c-dist-auth-dist@listhub.w3.org; Tue, 22 Feb 2005 20:48:29 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D3gxH-00068y-FP for w3c-dist-auth@listhub.w3.org; Tue, 22 Feb 2005 20:48:27 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1D3gxH-0007bN-3K for w3c-dist-auth@w3.org; Tue, 22 Feb 2005 20:48:27 +0000 Received: (qmail invoked by alias); 22 Feb 2005 20:47:54 -0000 Received: from pD9E62405.dip.t-dialin.net (EHLO [192.168.0.3]) (217.230.36.5) by mail.gmx.net (mp020) with SMTP; 22 Feb 2005 21:47:54 +0100 X-Authenticated: #1915285 Message-ID: <421B9A6F.7050206@gmx.de> Date: Tue, 22 Feb 2005 21:47:43 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jamie Lokier CC: Geoffrey M Clemm , WebDAV , CalDAV DevList , HTTP Working Group References: <20050221213247.GB8870@mail.shareable.org> <20050222161520.GA22555@mail.shareable.org> <421B5F72.6070806@gmx.de> <20050222203839.GE22555@mail.shareable.org> In-Reply-To: <20050222203839.GE22555@mail.shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] Re: draft-reschke-http-addmember-00 X-Archived-At: http://www.w3.org/mid/421B9A6F.7050206@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9494 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 22 Feb 2005 20:48:29 +0000 Content-Transfer-Encoding: 7bit Jamie Lokier wrote: > ... > If it's done, the behaviour of the server is unpredictable. ADDMEMBER > doesn't fix that. > ... You keep saying that :-) So are you saying that defining new methods never ever is the right approach, because there are broken servers out there? If that's the case, let's just agree that we disagree. > (Although it would shift the likelihood towards a simple failure > rather than an unwanted side effect. Is it worth creating a new > method just to change the likelihood of a behaviour when a CalDAV > client is pointed at the wrong URL?) ADDMEMBER is a generic method. It doesn't have anything specific to do with CalDAV except that it *could* be used with CalDAV. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Feb 22 15:50:30 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18718 for ; Tue, 22 Feb 2005 15:50:30 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D3gyj-0007C0-NJ for w3c-dist-auth-dist@listhub.w3.org; Tue, 22 Feb 2005 20:49:57 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D3gyi-0007AV-Rs for w3c-dist-auth@listhub.w3.org; Tue, 22 Feb 2005 20:49:56 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1D3gyi-0007w6-G5 for w3c-dist-auth@w3.org; Tue, 22 Feb 2005 20:49:56 +0000 Received: (qmail invoked by alias); 22 Feb 2005 20:49:25 -0000 Received: from pD9E62405.dip.t-dialin.net (EHLO [192.168.0.3]) (217.230.36.5) by mail.gmx.net (mp002) with SMTP; 22 Feb 2005 21:49:25 +0100 X-Authenticated: #1915285 Message-ID: <421B9ACF.8040807@gmx.de> Date: Tue, 22 Feb 2005 21:49:19 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jamie Lokier CC: Geoffrey M Clemm , WebDAV , CalDAV DevList , HTTP Working Group References: <20050221213247.GB8870@mail.shareable.org> <421B6778.1080804@gmx.de> <20050222190228.GD22555@mail.shareable.org> <421B86CC.7020402@gmx.de> <20050222204226.GF22555@mail.shareable.org> In-Reply-To: <20050222204226.GF22555@mail.shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: draft-reschke-http-addmember-00 X-Archived-At: http://www.w3.org/mid/421B9ACF.8040807@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9495 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 22 Feb 2005 20:49:57 +0000 Content-Transfer-Encoding: 7bit Jamie Lokier wrote: > Julian Reschke wrote: > >>>You're missing that when you are doing CalDAV* requests, you _know_ the >>>URL you are accessing is CalDAV compliant already. (* - example). >> >>How does a client do *any* kind of server feature discovery if *any* >>method (including things like OPTIONS) may cause harm because of broken >>server implementations? > > > Even when you can trust OPTIONS, that's not going to tell you if it's > a CalDAV resource - only what methods are accepted. I'm not interested whether it's a CalDAV resource. I'm interested in whether it supports ADDMEMBER. > You do feature discovery - in other words, which URL points to a > calendar - in other ways. > > >>>If you don't know that you have big problems. >> >>Such as? > > > Such as trying to treat a non-calendar resource as a calender! :) And the problem resulting from that would be what exactly? A CalDAV calendar (as currently proposed) is just a WebDAV collection with some specific features. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Feb 22 16:02:55 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20792 for ; Tue, 22 Feb 2005 16:02:55 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D3hAX-0004y2-Ec for w3c-dist-auth-dist@listhub.w3.org; Tue, 22 Feb 2005 21:02:09 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D3hAV-0004x5-4x; Tue, 22 Feb 2005 21:02:07 +0000 Received: from scorpio.lunarpages.com ([64.235.234.122]) by bart.w3.org with esmtp (Exim 4.34) id 1D3hAU-0002yH-Sw; Tue, 22 Feb 2005 21:02:07 +0000 Received: from ip68-4-71-218.oc.oc.cox.net ([68.4.71.218] helo=[192.168.0.100]) by scorpio.lunarpages.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.44) id 1D3hAS-0008GN-SB; Tue, 22 Feb 2005 13:02:04 -0800 In-Reply-To: <421B8CDE.6000201@gmx.de> References: <20050217164142.GA17013@mail.shareable.org> <788C984DF503C81DC332E7DB@ninevah.cyrusoft.com> <4214D227.9020607@gmx.de> <1108663634.11773.28.camel@sukothai.pingtel.com> <4214E4D0.80408@gmx.de> <1108670449.11773.33.camel@sukothai.pingtel.com> <4214F973.9060404@gmx.de> <1109017914.3811.29.camel@localhost.localdomain> <20050221212838.GA8870@mail.shareable.org> <1109040989.3811.39.camel@localhost.localdomain> <20050222034655.GC4504@markbaker.ca> <7d6e31bc68586bba82b76fd4fe4443ba@gbiv.com> <421B8CDE.6000201@gmx.de> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: HTTP Working Group , Mark Baker , CalDAV DevList , WebDAV WG From: "Roy T. Fielding" Date: Tue, 22 Feb 2005 13:01:57 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.619.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - scorpio.lunarpages.com X-AntiAbuse: Original Domain - w3.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - gbiv.com Received-SPF: none (bart.w3.org: domain of fielding@gbiv.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/c93ef8c483699219997ff777928bedc8@gbiv.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9496 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 22 Feb 2005 21:02:09 +0000 Content-Transfer-Encoding: 7bit On Feb 22, 2005, at 11:49 AM, Julian Reschke wrote: > Roy T. Fielding wrote: >> On Feb 21, 2005, at 7:46 PM, Mark Baker wrote: >>> Let me ask this; why do we have PUT when a valid effect of a POST >>> could also be to set the state of a resource? >> Because PUT means set the state of this resource, whereas POST >> does not. >>> IMO, it's because there are advantages to having messages which >>> reflect >>> the expectations of their sender. >> Umm, think about that sentence and you will find it has no content. >> Messages reflect the instruction of the sender. POST does that. > > Agreed. But for POST, this only seems to work where there is a tight > coupling between client and server; otherwise the client will have no > clue about the server will indeed do with the request. The client doesn't need to know. An HTTP client does not know the reason why a request is being made, just as it does not know the text inside the anchor of a hypertext link that was clicked on to generate a GET request. The user (agent) builds up state based on a huge number of factors, including what is said in all past representations received, degrees of trust, instructions that may have been received via some other channel, configuration, etc. That is what tells the user what to expect. HTTP doesn't care. What HTTP cares about is that the method is unsafe, the response is not (by default) cacheable, a new resource has been created (201), and it can be found at a given Location. > By defining a way to discover WebDAV collections > (DAV:resourcetype/DAV:collection in PROPFIND response), a client can > find out whether a resource is a WebDAV collection or isn't. Also, > WebDAV defines COPY and MOVE as namespace operations that take > containment into account. Completely irrelevant -- COPY and MOVE are HTTP operations on any collection, not just webdav collections, and will succeed or fail regardless of whether the client previously checked its pacifier. > I'm not sure why this is a problem; and in particular I'd like to know > what a better solution would have been. There was no problem -- it was a solution to someone's angst. >> absolutely moronic implementations that have to test each resource >> for the set of methods it implements before performing a set of >> actions that would have the same result as a generic POST. > > Right, those are moronic implementations (because in general, a client > can safely try the method and then handle HTTP's "method not allowed" > status code gracefully). > > On the other hand, using distinct methods allows to use a > discovery/failure signalling approach that uses plain HTTP (OPTIONS > method, "Allow" response header, 405 status). Which is completely unnecessary in HTTP. >> [Which is to say that it will suck every bit as much as the other >> methods introduced by webdav and its prodigy that created arbitrary >> resource types for collections, versions, and now calendars.] > > Nit: Versions aren't special resource types. Sorry, I meant MKWORKSPACE. >> POST, in contrast, is a generic semantic that allows the resource >> to determine its implementation-specific effects. POST to a >> collection means add a member. POST to a PUT-able resource means >> an atomic append. POST to a messaging gateway means "post this". > > Why can't a collection be PUT-able? It could have been, but MKCOL was defined instead (over my objection). > OK, so that sounds to me like resources should fall into distinct > categories: > > (A1) Collections vs (A2) Non-Collections > (B1) Put-able vs (B2) Non-Put-able > > - resources of type A1 would understand POST request as having > "ADDMEMBER" semantics > > - resources of type A2 can (within reason) do anything they like with > POST (as long as compliant to RFC2616) > > - resources of type B1 will allow PUT (as defined by RFC2616) and > understand POST as "append" operation > > Let's consider a simple WebDAV server that supports only resources of > types A1 and B1. What's the recommendation to do authoring operations > beyond PUT on these resources? Define new methods (such as > VERSION-CONTROL) or mint new related URLs to which existing methods > can be applied? Different URLs (see, for example, how the configurable name "index" is a member of a collection and also the default response to GET on that collection). How a PUT or POST or any other method applied to the collection is handled is just as configurable and may depend on other aspects of the request (like content-type, authentication, and more). PUT is usually redirected to the index URL because namespace operations are typically done one name at a time rather than entire collections at a time, however that is dependent on the implementation: when a client does a PUT of an XML document to a JCR-backed implementation, it will create a collection (a document is just one view of the collection). Each resource has an implementation and that implementation defines how the method impacts its state aside from what is already defined by virtue of HTTP's method semantics. The reason we don't need ADDMEMBER is because POST already exists, a server must inspect the media type already, and none of the overlapping uses of POST are valid new members to add to a collection (soap envelopes or www/x-form-urlencoded). It is therefore possible to say that POST has the add member effect on a webdav collection and be done. ....Roy From w3c-dist-auth-request@w3.org Tue Feb 22 16:43:23 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25705 for ; Tue, 22 Feb 2005 16:43:22 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D3hnR-0007G7-F9 for w3c-dist-auth-dist@listhub.w3.org; Tue, 22 Feb 2005 21:42:21 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D3hnK-0007Ax-2V for w3c-dist-auth@listhub.w3.org; Tue, 22 Feb 2005 21:42:14 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1D3hnJ-0001iJ-Lj for w3c-dist-auth@w3.org; Tue, 22 Feb 2005 21:42:13 +0000 Received: (qmail invoked by alias); 22 Feb 2005 21:41:16 -0000 Received: from pD9E62405.dip.t-dialin.net (EHLO [192.168.0.3]) (217.230.36.5) by mail.gmx.net (mp024) with SMTP; 22 Feb 2005 22:41:16 +0100 X-Authenticated: #1915285 Message-ID: <421BA6F6.2000804@gmx.de> Date: Tue, 22 Feb 2005 22:41:10 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jamie Lokier CC: Geoffrey M Clemm , WebDAV , CalDAV DevList , HTTP Working Group References: <20050221213247.GB8870@mail.shareable.org> <20050222161520.GA22555@mail.shareable.org> <421B5F72.6070806@gmx.de> <20050222203839.GE22555@mail.shareable.org> <421B9A6F.7050206@gmx.de> <20050222211908.GH22555@mail.shareable.org> In-Reply-To: <20050222211908.GH22555@mail.shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] Re: draft-reschke-http-addmember-00 X-Archived-At: http://www.w3.org/mid/421BA6F6.2000804@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9497 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 22 Feb 2005 21:42:21 +0000 Content-Transfer-Encoding: 7bit Jamie Lokier wrote: >>You keep saying that :-) So are you saying that defining new methods >>never ever is the right approach, because there are broken servers out >>there? > > > No I'm not saying that. > > One of the rationales given in this thread for ADDMEMBER is that the > tighter semantics mean that clients can depend on it literally adding > a new resource which is GETable, or failing with Method Not Supported. > > I'm saying that particular rationale isn't logically sound. ADDMEMBER is defined to do just that. If it would be accepted and become a standards-track RFC, yes, clients could rely on it just like they can rely on other HTTP methods today. > It doesn't negate any other rationales you may have up your sleeve :) > > >>ADDMEMBER is a generic method. It doesn't have anything specific to do >>with CalDAV except that it *could* be used with CalDAV. > > > Indeed, but are there realistic applications in mind that would use > ADDMEMBER without caring what kind of container resource it is, but do > care that it is a container and not a form processor? Yes. For instance it could be used for Atom-Pub, and another use case was just suggested a few days ago internally at SAP (where a specific backend system has a concept of containment, but doesn't allow user-selected URIs). > If there are it makes more sense. If there aren't, it's unneeded. > > I think your exploration of the WebDAV text concerning why POST isn't > used on containers is a good one, btw. I appreciate all the feedback I'm getting, and I'm very interested in ways that would avoid adding a new method while keeping the intended benefits. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Feb 22 18:41:02 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09370 for ; Tue, 22 Feb 2005 18:41:02 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D3jd2-0003b3-TN for w3c-dist-auth-dist@listhub.w3.org; Tue, 22 Feb 2005 23:39:44 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D3iOt-0008OW-IR for w3c-dist-auth@listhub.w3.org; Tue, 22 Feb 2005 22:21:03 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1D3iFa-0008Qb-J9 for w3c-dist-auth@w3.org; Tue, 22 Feb 2005 22:11:26 +0000 Received: (qmail invoked by alias); 22 Feb 2005 22:10:53 -0000 Received: from pD9E62405.dip.t-dialin.net (EHLO [192.168.0.3]) (217.230.36.5) by mail.gmx.net (mp009) with SMTP; 22 Feb 2005 23:10:53 +0100 X-Authenticated: #1915285 Message-ID: <421BADE0.6060105@gmx.de> Date: Tue, 22 Feb 2005 23:10:40 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Roy T. Fielding" CC: HTTP Working Group , Mark Baker , CalDAV DevList , WebDAV WG References: <20050217164142.GA17013@mail.shareable.org> <788C984DF503C81DC332E7DB@ninevah.cyrusoft.com> <4214D227.9020607@gmx.de> <1108663634.11773.28.camel@sukothai.pingtel.com> <4214E4D0.80408@gmx.de> <1108670449.11773.33.camel@sukothai.pingtel.com> <4214F973.9060404@gmx.de> <1109017914.3811.29.camel@localhost.localdomain> <20050221212838.GA8870@mail.shareable.org> <1109040989.3811.39.camel@localhost.localdomain> <20050222034655.GC4504@markbaker.ca> <7d6e31bc68586bba82b76fd4fe4443ba@gbiv.com> <421B8CDE.6000201@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/421BADE0.6060105@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9498 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 22 Feb 2005 23:39:44 +0000 Content-Transfer-Encoding: 7bit Roy T. Fielding wrote: > ... >> By defining a way to discover WebDAV collections >> (DAV:resourcetype/DAV:collection in PROPFIND response), a client can >> find out whether a resource is a WebDAV collection or isn't. Also, >> WebDAV defines COPY and MOVE as namespace operations that take >> containment into account. > > > Completely irrelevant -- COPY and MOVE are HTTP operations on any > collection, not just webdav collections, and will succeed or fail > regardless of whether the client previously checked its pacifier. Yes, but that doesn't mean it's irrelevant whether a resource is a collection or not. It just means that you don't *have* to check before you apply namespace operations. >> I'm not sure why this is a problem; and in particular I'd like to know >> what a better solution would have been. > > > There was no problem -- it was a solution to someone's angst. So how *should* a WebDAV collection have been defined? >>> absolutely moronic implementations that have to test each resource >>> for the set of methods it implements before performing a set of >>> actions that would have the same result as a generic POST. >> >> >> Right, those are moronic implementations (because in general, a client >> can safely try the method and then handle HTTP's "method not allowed" >> status code gracefully). >> >> On the other hand, using distinct methods allows to use a >> discovery/failure signalling approach that uses plain HTTP (OPTIONS >> method, "Allow" response header, 405 status). > > > Which is completely unnecessary in HTTP. The 405 status and the Allow response header are unnecessary? >>> [Which is to say that it will suck every bit as much as the other >>> methods introduced by webdav and its prodigy that created arbitrary >>> resource types for collections, versions, and now calendars.] >> >> >> Nit: Versions aren't special resource types. > > > Sorry, I meant MKWORKSPACE. The alternative would have been just to use standard resources, but in that case RFC3253 would have had to define some new way to indicate that something indeed is a workspace. >>> POST, in contrast, is a generic semantic that allows the resource >>> to determine its implementation-specific effects. POST to a >>> collection means add a member. POST to a PUT-able resource means >>> an atomic append. POST to a messaging gateway means "post this". >> >> >> Why can't a collection be PUT-able? > > > It could have been, but MKCOL was defined instead (over my objection). There is nothing in RFC2518 that prevents collections from being PUT-able (however the rational for not defining PUT on collections is a bit weird, see ). >> OK, so that sounds to me like resources should fall into distinct >> categories: >> >> (A1) Collections vs (A2) Non-Collections >> (B1) Put-able vs (B2) Non-Put-able >> >> - resources of type A1 would understand POST request as having >> "ADDMEMBER" semantics >> >> - resources of type A2 can (within reason) do anything they like with >> POST (as long as compliant to RFC2616) >> >> - resources of type B1 will allow PUT (as defined by RFC2616) and >> understand POST as "append" operation >> >> Let's consider a simple WebDAV server that supports only resources of >> types A1 and B1. What's the recommendation to do authoring operations >> beyond PUT on these resources? Define new methods (such as >> VERSION-CONTROL) or mint new related URLs to which existing methods >> can be applied? > > > Different URLs (see, for example, how the configurable name "index" > is a member of a collection and also the default response to GET > on that collection). How a PUT or POST or any other method applied > to the collection is handled is just as configurable and may depend > on other aspects of the request (like content-type, authentication, > and more). PUT is usually redirected to the index URL because > namespace operations are typically done one name at a time rather ...when you say "typically", what implementation are you referring to? Is this implemented in Apache/mod_dav? > than entire collections at a time, however that is dependent on the > implementation: when a client does a PUT of an XML document to a > JCR-backed implementation, it will create a collection (a document > is just one view of the collection). > > Each resource has an implementation and that implementation defines > how the method impacts its state aside from what is already defined > by virtue of HTTP's method semantics. The reason we don't need > ADDMEMBER is because POST already exists, a server must inspect > the media type already, and none of the overlapping uses of POST > are valid new members to add to a collection (soap envelopes or > www/x-form-urlencoded). It is therefore possible to say that POST Interesting. Why wouldn't a SOAP envelope be a valid new collection member? And what about other potential content types resources could already implement for POST (that just happen to be proprietary)? > has the add member effect on a webdav collection and be done. > > ....Roy Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Feb 22 23:29:29 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02159 for ; Tue, 22 Feb 2005 23:29:28 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D3o6q-0003Et-1P for w3c-dist-auth-dist@listhub.w3.org; Wed, 23 Feb 2005 04:26:48 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D3o6m-0003Do-Rs; Wed, 23 Feb 2005 04:26:44 +0000 Received: from [216.126.80.155] (helo=bork.markbaker.ca) by bart.w3.org with esmtp (Exim 4.34) id 1D3o6m-0001ZR-JC; Wed, 23 Feb 2005 04:26:44 +0000 Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian)) id 1D3o6C-0004B2-00; Tue, 22 Feb 2005 23:26:08 -0500 Date: Tue, 22 Feb 2005 23:26:08 -0500 From: Mark Baker To: "Roy T. Fielding" Cc: HTTP Working Group , CalDAV DevList , WebDAV WG Message-ID: <20050223042608.GF4504@markbaker.ca> References: <4214E4D0.80408@gmx.de> <1108670449.11773.33.camel@sukothai.pingtel.com> <4214F973.9060404@gmx.de> <1109017914.3811.29.camel@localhost.localdomain> <20050221212838.GA8870@mail.shareable.org> <1109040989.3811.39.camel@localhost.localdomain> <20050222034655.GC4504@markbaker.ca> <7d6e31bc68586bba82b76fd4fe4443ba@gbiv.com> <20050222133758.GD4504@markbaker.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i Received-SPF: none (bart.w3.org: domain of distobj@acm.org does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/20050223042608.GF4504@markbaker.ca Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9499 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 23 Feb 2005 04:26:48 +0000 On Tue, Feb 22, 2005 at 11:52:55AM -0800, Roy T. Fielding wrote: > On Feb 22, 2005, at 5:37 AM, Mark Baker wrote: > >Ah, so you're saying that ADDMEMBER isn't uniform? > > Actually, no, I was saying that ADDMEMBER as currently defined > is identical to POST. Julian said that it wasn't identical because > his client would be able to expect one semantic, namely that a > 201 result would cause the webdav collection to contain a new > member with the given media type. That implies an additional > requirement that the target be a webdav collection, which isn't > uniform at all. I get the DAV-collection-implies-non-uniform thing, and would be against a revision which attributed that meaning to a 201 response. But I'm just not seeing how ADDMEMBER==POST, sorry. I still don't see how POST vs. ADDMEMBER is any different than POST vs. PUT. You previously said that PUT has "set the state of this resource" semantics which is clearly different than POST. IMO, ADDMEMBER's semantics are very similar to PUT. What (constraint?) am I missing that suggests PUT is fine while ADDMEMBER isn't? Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca From w3c-dist-auth-request@w3.org Wed Feb 23 03:32:23 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10344 for ; Wed, 23 Feb 2005 03:32:22 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D3rv6-0001Vz-EI for w3c-dist-auth-dist@listhub.w3.org; Wed, 23 Feb 2005 08:30:56 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D3rv4-0001VB-0G; Wed, 23 Feb 2005 08:30:54 +0000 Received: from fed1rmmtao03.cox.net ([68.230.241.36]) by lisa.w3.org with esmtp (Exim 4.34) id 1D3rv3-0002Dd-NI; Wed, 23 Feb 2005 08:30:53 +0000 Received: from [192.168.0.100] (really [68.4.71.218]) by fed1rmmtao03.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050223083022.GFSW1282.fed1rmmtao03.cox.net@[192.168.0.100]>; Wed, 23 Feb 2005 03:30:22 -0500 In-Reply-To: <20050223042608.GF4504@markbaker.ca> References: <4214E4D0.80408@gmx.de> <1108670449.11773.33.camel@sukothai.pingtel.com> <4214F973.9060404@gmx.de> <1109017914.3811.29.camel@localhost.localdomain> <20050221212838.GA8870@mail.shareable.org> <1109040989.3811.39.camel@localhost.localdomain> <20050222034655.GC4504@markbaker.ca> <7d6e31bc68586bba82b76fd4fe4443ba@gbiv.com> <20050222133758.GD4504@markbaker.ca> <20050223042608.GF4504@markbaker.ca> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9ee689aeebb609c273b25296ff535c51@gbiv.com> Content-Transfer-Encoding: 7bit Cc: HTTP Working Group , CalDAV DevList , WebDAV WG From: "Roy T. Fielding" Date: Wed, 23 Feb 2005 00:24:07 -0800 To: Mark Baker X-Mailer: Apple Mail (2.619.2) Received-SPF: none (lisa.w3.org: domain of fielding@gbiv.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/9ee689aeebb609c273b25296ff535c51@gbiv.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9500 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 23 Feb 2005 08:30:56 +0000 Content-Transfer-Encoding: 7bit On Feb 22, 2005, at 8:26 PM, Mark Baker wrote: > I still don't see how POST vs. ADDMEMBER is any different than POST > vs. PUT. You previously said that PUT has "set the state of this > resource" semantics which is clearly different than POST. IMO, > ADDMEMBER's semantics are very similar to PUT. What (constraint?) am > I missing that suggests PUT is fine while ADDMEMBER isn't? You are missing that the target of PUT is the new resource, whereas the target of POST and ADDMEMBER are both the collection resource. As such, ADDMEMBER's semantics has very little in common with PUT (almost nothing, in fact, since any unsafe extension method can return 201 and communicate just as much, whereas PUT is unique in what it communicates by the 200/201). ....Roy From w3c-dist-auth-request@w3.org Thu Feb 24 10:58:11 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06412 for ; Thu, 24 Feb 2005 10:58:10 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D4LLe-0007Ao-F8 for w3c-dist-auth-dist@listhub.w3.org; Thu, 24 Feb 2005 15:56:18 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D4LLZ-00076L-Ol for w3c-dist-auth@listhub.w3.org; Thu, 24 Feb 2005 15:56:13 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1D4LLZ-0002If-GP for w3c-dist-auth@w3.org; Thu, 24 Feb 2005 15:56:13 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j1OFuCaa012257; Thu, 24 Feb 2005 07:56:12 -0800 Date: Thu, 24 Feb 2005 07:56:12 -0800 Message-Id: <200502241556.j1OFuCaa012257@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 79] New: PUT for collections rationale X-Archived-At: http://www.w3.org/mid/200502241556.j1OFuCaa012257@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9501 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 24 Feb 2005 15:56:18 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=79 Summary: PUT for collections rationale Product: WebDAV-RFC2518-bis Version: -06 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org Section 8.8.2 states: As defined in RFC2616 [8], the "PUT method requests that the enclosed entity be stored under the supplied Request-URI." Since submission of an entity representing a collection would implicitly encode creation and deletion of resources, this specification intentionally does not define a transmission format for creating a collection using PUT. Instead, the MKCOL method is defined to create collections. There is nothing in RFC2616 that would mandate that PUT on a collection would affect collection membership. Simply drop the paragraph. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Fri Feb 25 00:42:03 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09992 for ; Fri, 25 Feb 2005 00:42:02 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D4YCd-0005Gv-Li for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Feb 2005 05:39:51 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D4YCZ-0005G2-Mv for w3c-dist-auth@listhub.w3.org; Fri, 25 Feb 2005 05:39:47 +0000 Received: from mxout-03.mxes.net ([205.237.194.34]) by bart.w3.org with esmtp (Exim 4.34) id 1D4YCZ-0002Yv-IT for w3c-dist-auth@w3.org; Fri, 25 Feb 2005 05:39:47 +0000 Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id C62E751A39 for ; Fri, 25 Feb 2005 00:39:45 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <00e2ac1ef9bcade15ebed6e8af99e779@mnot.net> Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Date: Thu, 24 Feb 2005 21:38:00 -0800 To: w3c-dist-auth@w3.org X-Mailer: Apple Mail (2.619.2) Received-SPF: none (bart.w3.org: domain of mnot@mnot.net does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: WebDav methods and idempotency X-Archived-At: http://www.w3.org/mid/00e2ac1ef9bcade15ebed6e8af99e779@mnot.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9502 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 25 Feb 2005 05:39:51 +0000 Content-Transfer-Encoding: 7bit A couple of questions about WebDAV; * The only mention of idempotency in any WebDAV RFC that I see is: "Responses from a MKCOL request MUST NOT be cached as MKCOL has non-idempotent semantics" in 2518, Section 8.3.2. Is it the case, then, that all other WebDAV-defined methods are in fact idempotent? I could see MOVE as non-idempotent, IF the semantics of COPY are such that it's legal to COPY a null resource; i.e., the MOVE would first COPY the existant resource, then DELETE it, then on a subsequent request, would COPY the null resource. However, it isn't clear from a casual reading of 2518 as to whether COPY will fail (404?) if you try to point it at a null resource. * How is MKCOL non-idempotent? I.e., how does performing MKCOL /foo five times have different side effects than performing it once? 2518 says that "If the resource identified by the Request-URI is non-null then the MKCOL MUST fail." It seems that all MKCOLs after the first one will fail, thus bringing no new side-effects. I can certainly see how MKCOL could be involved in a non-idempotent sequence, but don't see how it is on its own; am I missing something, or should it be "MKCOL has side effects" instead of "MKCOL has non-idempotent semantics?" Thanks, -- Mark Nottingham http://www.mnot.net/ From w3c-dist-auth-request@w3.org Fri Feb 25 01:05:10 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12261 for ; Fri, 25 Feb 2005 01:05:10 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D4YaH-0007ab-FY for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Feb 2005 06:04:17 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D4Y8b-0003m7-Q9; Fri, 25 Feb 2005 05:35:41 +0000 Received: from [216.126.80.155] (helo=bork.markbaker.ca) by lisa.w3.org with esmtp (Exim 4.34) id 1D4Y8b-0000nQ-Lt; Fri, 25 Feb 2005 05:35:41 +0000 Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian)) id 1D4Y85-0004GV-00; Fri, 25 Feb 2005 00:35:09 -0500 Date: Fri, 25 Feb 2005 00:35:09 -0500 From: Mark Baker To: HTTP Working Group , CalDAV DevList , WebDAV WG Message-ID: <20050225053508.GA16308@markbaker.ca> References: <4214F973.9060404@gmx.de> <1109017914.3811.29.camel@localhost.localdomain> <20050221212838.GA8870@mail.shareable.org> <1109040989.3811.39.camel@localhost.localdomain> <20050222034655.GC4504@markbaker.ca> <7d6e31bc68586bba82b76fd4fe4443ba@gbiv.com> <20050222133758.GD4504@markbaker.ca> <20050223042608.GF4504@markbaker.ca> <9ee689aeebb609c273b25296ff535c51@gbiv.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9ee689aeebb609c273b25296ff535c51@gbiv.com> User-Agent: Mutt/1.5.6+20040907i Received-SPF: none (lisa.w3.org: domain of distobj@acm.org does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] X-Archived-At: http://www.w3.org/mid/20050225053508.GA16308@markbaker.ca Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9503 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 25 Feb 2005 06:04:17 +0000 On Wed, Feb 23, 2005 at 12:24:07AM -0800, Roy T. Fielding wrote: > On Feb 22, 2005, at 8:26 PM, Mark Baker wrote: > >I still don't see how POST vs. ADDMEMBER is any different than POST > >vs. PUT. You previously said that PUT has "set the state of this > >resource" semantics which is clearly different than POST. IMO, > >ADDMEMBER's semantics are very similar to PUT. What (constraint?) am > >I missing that suggests PUT is fine while ADDMEMBER isn't? > > You are missing that the target of PUT is the new resource, > whereas the target of POST and ADDMEMBER are both the collection > resource. As such, ADDMEMBER's semantics has very little in > common with PUT (almost nothing, in fact, since any unsafe > extension method can return 201 and communicate just as much, > whereas PUT is unique in what it communicates by the 200/201). In case anybody's still following this thread 8-) ... I now find myself in agreement with Roy, that POST is appropriate and that ADDMEMBER == POST. I was looking at the interaction from the POV of a tweak on PUT semantics, rather than as the submission of a document to a state-preserving container (which I should have recognized it as immediately, given my previous attempts at describing such a model[1]). I'm still not convinced that a POST extension (which declared the expected type of the target resource) wouldn't improve the self-descriptiveness of the message, but practically, that's pretty much irrelevant for the purposes of this discussion. [1] http://www.markbaker.ca/2001/09/draft-baker-http-resource-state-model-01.txt Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca From w3c-dist-auth-request@w3.org Fri Feb 25 15:37:40 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29198 for ; Fri, 25 Feb 2005 15:37:39 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D4mBa-0004Zl-PP for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Feb 2005 20:35:42 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D4mBV-0004VH-G4 for w3c-dist-auth@listhub.w3.org; Fri, 25 Feb 2005 20:35:37 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.34) id 1D4mBV-0002vd-5j for w3c-dist-auth@w3.org; Fri, 25 Feb 2005 20:35:37 +0000 Received: (qmail invoked by alias); 25 Feb 2005 20:35:04 -0000 Received: from pD9FF043D.dip.t-dialin.net (EHLO [192.168.0.3]) (217.255.4.61) by mail.gmx.net (mp019) with SMTP; 25 Feb 2005 21:35:04 +0100 X-Authenticated: #1915285 Message-ID: <421F8BF1.5000902@gmx.de> Date: Fri, 25 Feb 2005 21:34:57 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Nottingham CC: w3c-dist-auth@w3.org References: <00e2ac1ef9bcade15ebed6e8af99e779@mnot.net> In-Reply-To: <00e2ac1ef9bcade15ebed6e8af99e779@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: WebDav methods and idempotency X-Archived-At: http://www.w3.org/mid/421F8BF1.5000902@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9504 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 25 Feb 2005 20:35:42 +0000 Content-Transfer-Encoding: 7bit Mark Nottingham wrote: > > A couple of questions about WebDAV; > > * The only mention of idempotency in any WebDAV RFC that I see is: > "Responses from a MKCOL request MUST NOT be cached as MKCOL has > non-idempotent semantics" in 2518, Section 8.3.2. Is it the case, then, > that all other WebDAV-defined methods are in fact idempotent? > > I could see MOVE as non-idempotent, IF the semantics of COPY are such > that it's legal to COPY a null resource; i.e., the MOVE would first COPY > the existant resource, then DELETE it, then on a subsequent request, > would COPY the null resource. However, it isn't clear from a casual > reading of 2518 as to whether COPY will fail (404?) if you try to point > it at a null resource. > > * How is MKCOL non-idempotent? I.e., how does performing MKCOL /foo five > times have different side effects than performing it once? 2518 says > that "If the resource identified by the Request-URI is non-null then the > MKCOL MUST fail." It seems that all MKCOLs after the first one will > fail, thus bringing no new side-effects. I can certainly see how MKCOL > could be involved in a non-idempotent sequence, but don't see how it is > on its own; am I missing something, or should it be "MKCOL has side > effects" instead of "MKCOL has non-idempotent semantics?" You are right, MKCOL isn't idempotent, nor is MOVE. I'll raise issues against RFC2518bis, RFC3253bis, RFC3648bis and RFC3744bis so this get's fixed in future revisions. In BIND () we're hopefully already doing it right; but you may want to check :-) Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Feb 25 15:52:03 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00776 for ; Fri, 25 Feb 2005 15:52:02 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D4mQa-0000bu-6n for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Feb 2005 20:51:12 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D4mQW-0000bB-Gj for w3c-dist-auth@listhub.w3.org; Fri, 25 Feb 2005 20:51:08 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1D4mQW-0005Vs-8F for w3c-dist-auth@w3.org; Fri, 25 Feb 2005 20:51:08 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j1PKp7dl013354; Fri, 25 Feb 2005 12:51:07 -0800 Date: Fri, 25 Feb 2005 12:51:07 -0800 Message-Id: <200502252051.j1PKp7dl013354@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 80] New: Specify idempotence and safeness for all new methods X-Archived-At: http://www.w3.org/mid/200502252051.j1PKp7dl013354@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9505 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 25 Feb 2005 20:51:12 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=80 Summary: Specify idempotence and safeness for all new methods Product: WebDAV-RFC2518-bis Version: -06 Platform: Other URL: http://greenbytes.de/tech/webdav/rfc2616.html#rfc.sectio n.9.1 OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org (see RFC2616, section 9.1) ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Fri Feb 25 15:58:26 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01096 for ; Fri, 25 Feb 2005 15:58:24 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D4mWu-0002GD-4G for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Feb 2005 20:57:44 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D4mWr-0002FU-CC for w3c-dist-auth@listhub.w3.org; Fri, 25 Feb 2005 20:57:41 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.34) id 1D4mWr-0000vp-12 for w3c-dist-auth@w3.org; Fri, 25 Feb 2005 20:57:41 +0000 Received: (qmail invoked by alias); 25 Feb 2005 20:57:08 -0000 Received: from pD9FF043D.dip.t-dialin.net (EHLO [192.168.0.3]) (217.255.4.61) by mail.gmx.net (mp007) with SMTP; 25 Feb 2005 21:57:08 +0100 X-Authenticated: #1915285 Message-ID: <421F911E.2060607@gmx.de> Date: Fri, 25 Feb 2005 21:57:02 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke CC: webdav , Joe Hildebrand References: <1aef7c87a3636e35da541fba00215c3c@jabber.com> <4204026B.1070104@gmx.de> <420BD326.4090805@gmx.de> <421727CB.1090404@gmx.de> In-Reply-To: <421727CB.1090404@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Status of working group last call on BIND X-Archived-At: http://www.w3.org/mid/421F911E.2060607@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9506 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 25 Feb 2005 20:57:44 +0000 Content-Transfer-Encoding: 7bit Julian Reschke wrote: > > OK, > > as announced one week ago, I have submitted the current draft text as > version -11. As far as I can tell, all issues that have been raised > during the working group last call should be closed according to the > procedure outlined by Joe > (). > > Three additional issues were raised after last call. They have been > answered, and there was no further discussion since (> 2 weeks ago). > Also, they don't have any votes in the issue tracker, so they should be > closed as well. > > Thus, it seems we're done WGLC-wise. The next step now is to submit this > draft for publication as RFC, which will result in another last call in > which possibly remaining issues can be raised. Joe, Lisa? Lisa, Joe, it would be nice if you could follow up on how to proceed. As far as I can tell, we're done, and draft 11 should be sent to the IESG for approval as Proposed Standard. What am I missing? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Feb 25 17:48:11 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10291 for ; Fri, 25 Feb 2005 17:48:11 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D4oEU-0002gO-3n for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Feb 2005 22:46:50 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D4oEN-0002eq-In for w3c-dist-auth@listhub.w3.org; Fri, 25 Feb 2005 22:46:43 +0000 Received: from mxout-03.mxes.net ([205.237.194.34]) by bart.w3.org with esmtp (Exim 4.34) id 1D4oEN-0004ib-EU for w3c-dist-auth@w3.org; Fri, 25 Feb 2005 22:46:43 +0000 Received: from [172.16.1.2] (sj-ez-63-96-162-1.bea.com [63.96.162.1]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 3344E51A1A; Fri, 25 Feb 2005 17:46:42 -0500 (EST) In-Reply-To: <421F8BF1.5000902@gmx.de> References: <00e2ac1ef9bcade15ebed6e8af99e779@mnot.net> <421F8BF1.5000902@gmx.de> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Date: Fri, 25 Feb 2005 14:46:39 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.619.2) Received-SPF: none (bart.w3.org: domain of mnot@mnot.net does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: WebDav methods and idempotency X-Archived-At: http://www.w3.org/mid/a6f51217446e69cc8d14afbcdc7d79b1@mnot.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9507 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 25 Feb 2005 22:46:50 +0000 Content-Transfer-Encoding: 7bit On Feb 25, 2005, at 12:34 PM, Julian Reschke wrote: > You are right, MKCOL isn't idempotent, nor is MOVE. I'll raise issues > against RFC2518bis, RFC3253bis, RFC3648bis and RFC3744bis so this > get's fixed in future revisions. Do you mean that MKCOL *is* idempotent, and MOVE isn't? Thanks! -- Mark Nottingham http://www.mnot.net/ From w3c-dist-auth-request@w3.org Fri Feb 25 20:50:18 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23638 for ; Fri, 25 Feb 2005 20:50:17 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D4r4Q-0000bM-Na for w3c-dist-auth-dist@listhub.w3.org; Sat, 26 Feb 2005 01:48:38 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D4r4M-0000aZ-JR for w3c-dist-auth@listhub.w3.org; Sat, 26 Feb 2005 01:48:34 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1D4r4M-0004sN-Bb for w3c-dist-auth@w3.org; Sat, 26 Feb 2005 01:48:34 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1Q1mPaa022829 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 25 Feb 2005 17:48:29 -0800 In-Reply-To: <421F911E.2060607@gmx.de> References: <1aef7c87a3636e35da541fba00215c3c@jabber.com> <4204026B.1070104@gmx.de> <420BD326.4090805@gmx.de> <421727CB.1090404@gmx.de> <421F911E.2060607@gmx.de> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <404047ae8ff02e72c55e5a8fcd6b8f9b@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: Joe Hildebrand , webdav From: Lisa Dusseault Date: Fri, 25 Feb 2005 17:48:18 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.619.2) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Status of working group last call on BIND X-Archived-At: http://www.w3.org/mid/404047ae8ff02e72c55e5a8fcd6b8f9b@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9508 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 26 Feb 2005 01:48:38 +0000 Content-Transfer-Encoding: 7bit I've limited myself to the role of reviewer on BIND because I wanted to do a bunch of technical and spec clarity reviews. Normally that's well within the scope of a chair and in fact expected of them, but it seemed to be causing some tension in this case so process stuff for BIND is all in Joe's hands. Lisa On Feb 25, 2005, at 12:57 PM, Julian Reschke wrote: > > Julian Reschke wrote: >> OK, >> as announced one week ago, I have submitted the current draft text as >> version -11. As far as I can tell, all issues that have been raised >> during the working group last call should be closed according to the >> procedure outlined by Joe >> (> 0001.html>). >> Three additional issues were raised after last call. They have been >> answered, and there was no further discussion since (> 2 weeks ago). >> Also, they don't have any votes in the issue tracker, so they should >> be closed as well. >> Thus, it seems we're done WGLC-wise. The next step now is to submit >> this draft for publication as RFC, which will result in another last >> call in which possibly remaining issues can be raised. Joe, Lisa? > > Lisa, Joe, > > it would be nice if you could follow up on how to proceed. As far as I > can tell, we're done, and draft 11 should be sent to the IESG for > approval as Proposed Standard. > > What am I missing? > > > Best regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Sat Feb 26 03:10:14 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09984 for ; Sat, 26 Feb 2005 03:10:14 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D4x08-00087X-Km for w3c-dist-auth-dist@listhub.w3.org; Sat, 26 Feb 2005 08:08:36 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D4x04-00086N-Id for w3c-dist-auth@listhub.w3.org; Sat, 26 Feb 2005 08:08:32 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1D4x04-0004AT-69 for w3c-dist-auth@w3.org; Sat, 26 Feb 2005 08:08:32 +0000 Received: (qmail invoked by alias); 26 Feb 2005 08:07:59 -0000 Received: from pD9FF043D.dip.t-dialin.net (EHLO [192.168.0.3]) (217.255.4.61) by mail.gmx.net (mp027) with SMTP; 26 Feb 2005 09:07:59 +0100 X-Authenticated: #1915285 Message-ID: <42202E5C.50203@gmx.de> Date: Sat, 26 Feb 2005 09:07:56 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Nottingham CC: w3c-dist-auth@w3.org References: <00e2ac1ef9bcade15ebed6e8af99e779@mnot.net> <421F8BF1.5000902@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: WebDav methods and idempotency X-Archived-At: http://www.w3.org/mid/42202E5C.50203@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9509 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 26 Feb 2005 08:08:36 +0000 Content-Transfer-Encoding: 7bit Mark Nottingham wrote: > > On Feb 25, 2005, at 12:34 PM, Julian Reschke wrote: > >> You are right, MKCOL isn't idempotent, nor is MOVE. I'll raise issues >> against RFC2518bis, RFC3253bis, RFC3648bis and RFC3744bis so this >> get's fixed in future revisions. > > > Do you mean that MKCOL *is* idempotent, and MOVE isn't? Yep, sorry. MKCOL is idempotent. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sat Feb 26 03:13:18 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10096 for ; Sat, 26 Feb 2005 03:13:17 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D4x46-0000mY-U8 for w3c-dist-auth-dist@listhub.w3.org; Sat, 26 Feb 2005 08:12:42 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1D4x43-0000ix-Hp for w3c-dist-auth@listhub.w3.org; Sat, 26 Feb 2005 08:12:39 +0000 Received: from mxout-03.mxes.net ([205.237.194.34]) by bart.w3.org with esmtp (Exim 4.34) id 1D4x43-00084T-E0 for w3c-dist-auth@w3.org; Sat, 26 Feb 2005 08:12:39 +0000 Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id F2558519F7; Sat, 26 Feb 2005 03:12:37 -0500 (EST) In-Reply-To: <421F8BF1.5000902@gmx.de> References: <00e2ac1ef9bcade15ebed6e8af99e779@mnot.net> <421F8BF1.5000902@gmx.de> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Date: Sat, 26 Feb 2005 00:12:35 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.619.2) Received-SPF: none (bart.w3.org: domain of mnot@mnot.net does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: WebDav methods and idempotency X-Archived-At: http://www.w3.org/mid/aa500746fed6f3dd9eb46982dd5bedca@mnot.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9510 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 26 Feb 2005 08:12:42 +0000 Content-Transfer-Encoding: 7bit If MOVE is non-idempotent, it might also be good to clarify the semantics of MOVEing a null resource in 2518bis; i.e., that it's allowed, and won't give a 404 (for example). Cheers, On Feb 25, 2005, at 12:34 PM, Julian Reschke wrote: > Mark Nottingham wrote: >> A couple of questions about WebDAV; >> * The only mention of idempotency in any WebDAV RFC that I see is: >> "Responses from a MKCOL request MUST NOT be cached as MKCOL has >> non-idempotent semantics" in 2518, Section 8.3.2. Is it the case, >> then, that all other WebDAV-defined methods are in fact idempotent? > > >> I could see MOVE as non-idempotent, IF the semantics of COPY are such >> that it's legal to COPY a null resource; i.e., the MOVE would first >> COPY the existant resource, then DELETE it, then on a subsequent >> request, would COPY the null resource. However, it isn't clear from a >> casual reading of 2518 as to whether COPY will fail (404?) if you try >> to point it at a null resource. >> * How is MKCOL non-idempotent? I.e., how does performing MKCOL /foo >> five times have different side effects than performing it once? 2518 >> says that "If the resource identified by the Request-URI is non-null >> then the MKCOL MUST fail." It seems that all MKCOLs after the first >> one will fail, thus bringing no new side-effects. I can certainly see >> how MKCOL could be involved in a non-idempotent sequence, but don't >> see how it is on its own; am I missing something, or should it be >> "MKCOL has side effects" instead of "MKCOL has non-idempotent >> semantics?" > > You are right, MKCOL isn't idempotent, nor is MOVE. I'll raise issues > against RFC2518bis, RFC3253bis, RFC3648bis and RFC3744bis so this > get's fixed in future revisions. > > In BIND > () > we're hopefully already doing it right; but you may want to check :-) > > Best regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > -- Mark Nottingham http://www.mnot.net/ From w3c-dist-auth-request@w3.org Sat Feb 26 03:28:48 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11060 for ; Sat, 26 Feb 2005 03:28:47 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D4xIu-0004ZR-RA for w3c-dist-auth-dist@listhub.w3.org; Sat, 26 Feb 2005 08:28:00 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D4xIr-0004Yt-Bx for w3c-dist-auth@listhub.w3.org; Sat, 26 Feb 2005 08:27:57 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1D4xIr-0006LC-0i for w3c-dist-auth@w3.org; Sat, 26 Feb 2005 08:27:57 +0000 Received: (qmail invoked by alias); 26 Feb 2005 08:27:22 -0000 Received: from pD9FF043D.dip.t-dialin.net (EHLO [192.168.0.3]) (217.255.4.61) by mail.gmx.net (mp007) with SMTP; 26 Feb 2005 09:27:22 +0100 X-Authenticated: #1915285 Message-ID: <422032E6.6020701@gmx.de> Date: Sat, 26 Feb 2005 09:27:18 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Nottingham CC: w3c-dist-auth@w3.org References: <00e2ac1ef9bcade15ebed6e8af99e779@mnot.net> <421F8BF1.5000902@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: WebDav methods and idempotency X-Archived-At: http://www.w3.org/mid/422032E6.6020701@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9511 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 26 Feb 2005 08:28:00 +0000 Content-Transfer-Encoding: 7bit Mark Nottingham wrote: > > If MOVE is non-idempotent, it might also be good to clarify the > semantics of MOVEing a null resource in 2518bis; i.e., that it's > allowed, and won't give a 404 (for example). Finally I'm starting to understand the issue :-) Yes, MOVE applied to a null resource is expected to fail (with 404); thus doing a MOVE two times in a row should leave the system in the same state as doing it once. Seems it's idempotent after all. Same for COPY, except...: RFC3253 allows PUT and COPY (target resource) to be auto-versioned. That is, everytime you PUT to a URI, you may be -- as a side effect -- creating a new version (and the DeltaV live properties on the resource will reflect this). Can we still consider this idempotent. RFC3253bis should say something about this.. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sun Feb 27 11:11:41 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09262 for ; Sun, 27 Feb 2005 11:11:41 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1D5Qxv-0006hT-Uj for w3c-dist-auth-dist@listhub.w3.org; Sun, 27 Feb 2005 16:08:19 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1D5Qsj-0004Xz-FU for w3c-dist-auth@listhub.w3.org; Sun, 27 Feb 2005 16:02:57 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1D5Qj7-00030T-Aa for w3c-dist-auth@w3.org; Sun, 27 Feb 2005 15:53:04 +0000 Received: (qmail invoked by alias); 27 Feb 2005 15:52:29 -0000 Received: from pD9E51D34.dip.t-dialin.net (EHLO [192.168.0.3]) (217.229.29.52) by mail.gmx.net (mp007) with SMTP; 27 Feb 2005 16:52:29 +0100 X-Authenticated: #1915285 Message-ID: <4221ECB2.5000700@gmx.de> Date: Sun, 27 Feb 2005 16:52:18 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Nottingham CC: w3c-dist-auth@w3.org References: <00e2ac1ef9bcade15ebed6e8af99e779@mnot.net> In-Reply-To: <00e2ac1ef9bcade15ebed6e8af99e779@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Idempotency in RFC3648, was: WebDav methods and idempotency X-Archived-At: http://www.w3.org/mid/4221ECB2.5000700@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9512 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sun, 27 Feb 2005 16:08:19 +0000 Content-Transfer-Encoding: 7bit Mark Nottingham wrote: > > A couple of questions about WebDAV; > ... I have started a RFC3648bis container document for collecting errata in RFC3648 (Ordered Collections). HTML version: Issues list: I've added a new issue for the question raised by Mark (against all specs...) in and resolved it by adding the following statement to the ORDERPATCH method description: "This method is unsafe and idempotent (see [RFC2616], Section 9.1)." Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760