From w3c-dist-auth-request@w3.org Fri Jan 9 10:54:18 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08421 for ; Fri, 9 Jan 2004 10:54:12 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 04437A05B6; Wed, 7 Jan 2004 18:16:41 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 4D366A05B6 for ; Wed, 7 Jan 2004 18:16:40 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 51CE713C5B; Wed, 7 Jan 2004 18:16:40 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by dr-nick.w3.org (Postfix) with ESMTP id 3385B13811 for ; Wed, 7 Jan 2004 18:16:40 -0500 (EST) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i07NGd9n777972 for ; Wed, 7 Jan 2004 18:16:39 -0500 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i07NGd7Z105426 for ; Wed, 7 Jan 2004 18:16:39 -0500 In-Reply-To: <3FF958A3.3040900@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, 7 Jan 2004 18:16:36 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 01/07/2004 18:16:39, Serialize complete at 01/07/2004 18:16:39 Content-Type: text/plain; charset="US-ASCII" Subject: Re: redirect references protocol: automatic update X-Archived-At: http://www.w3.org/mid/OF26CD6376.FD8D7870-ON85256E14.007E5939-85256E14.007FDD9F@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8255 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: <20040107231641.04437A05B6@frink.w3.org> Resent-Date: Wed, 7 Jan 2004 18:16:41 -0500 (EST) I don't see why we couldn't require this (redirects created by some other mechanism don't have to act the same way as redirects created by MKREDIRECTREF. So we could/should say that the value of a redirectref changes only when it is explicitly updated by a PROPPATCH of the DAV:reftarget property, and not as a side-effect of some other operation such as MOVE. Cheers, Geoff Julian on 01/05/2004 07:29:23 AM: > Regarding issue the last call (year 2000) issue: > > protocol-latest.html#rfc.issue.lc-57-noautoupdate> > > "Add language to forbid servers from automatically updating redirect > resources when their targets move." > > I don't think we can forbid that. This spec consists of (a) > clarifications of how a server that supports redirects should behave for > specific WebDAV methods, and (b) extensions to explicitly create them > (or to apply a method to the redirect itself). As such, we shouldn't add > any requirements that HTTP doesn't add. What we could do is (1) note why > auto-update may be a bad idea, and possibly (2) define that redirects > created by MKREDIRECTREF should not behave that way (or alternatively > define more specific resource types). From w3c-dist-auth-request@w3.org Fri Jan 9 10:54:18 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08422 for ; Fri, 9 Jan 2004 10:54:12 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 05A05A05E2; Fri, 9 Jan 2004 07:46:46 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 48CB2A05E2 for ; Fri, 9 Jan 2004 07:46:44 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 36A43140B5; Fri, 9 Jan 2004 07:46:44 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id AD61C1409A for ; Fri, 9 Jan 2004 07:46:43 -0500 (EST) Received: (qmail 6468 invoked by uid 65534); 9 Jan 2004 12:46:42 -0000 Received: from mail.greenbytes.de (EHLO gmx.de) (217.5.201.10) by mail.gmx.net (mp010) with SMTP; 09 Jan 2004 13:46:42 +0100 X-Authenticated: #1915285 Message-ID: <3FFEA2B1.7050507@gmx.de> Date: Fri, 09 Jan 2004 13:46:41 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 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=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: redirect references protocol: automatic update X-Archived-At: http://www.w3.org/mid/3FFEA2B1.7050507@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8262 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: <20040109124646.05A05A05E2@frink.w3.org> Resent-Date: Fri, 9 Jan 2004 07:46:46 -0500 (EST) Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > One possibility is to have an additional argument to MKREDIRECTREF, > e.g. DAV:stable, that means that the client forbids the server from > auto-updating the reference. A client that doesn't care would leave > off this parameter, and the server would do what it wanted, while a > client that cared would specify this parameter, and a server that doesn't > support stable redirectref's would fail the request. Yep. The thing I'm currently unsure about is how to model the different properties of a link (stability, response status). Several approaches come to mind: 1) different resource types (redirect-301, redirect-302, ...) 2) one resource type with extension elements, such as 3) one simple resource type with the remaining information moved into separate properties (like it was proposed for the status). Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Jan 9 10:54:58 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08478 for ; Fri, 9 Jan 2004 10:54:58 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id B9A61A0D15; Fri, 9 Jan 2004 07:30:45 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id D3B0BA0D15 for ; Fri, 9 Jan 2004 07:30:43 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id B88F813A11; Fri, 9 Jan 2004 07:30:43 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by dr-nick.w3.org (Postfix) with ESMTP id 94E8C1394C for ; Fri, 9 Jan 2004 07:30:43 -0500 (EST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i09CUgd6449696 for ; Fri, 9 Jan 2004 07:30:42 -0500 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i09CUg57160650 for ; Fri, 9 Jan 2004 07:30:42 -0500 In-Reply-To: <3FFC99A2.6030100@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: Fri, 9 Jan 2004 07:30:33 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 01/09/2004 07:30:42, Serialize complete at 01/09/2004 07:30:42 Content-Type: text/plain; charset="US-ASCII" Subject: Re: redirect references protocol: automatic update X-Archived-At: http://www.w3.org/mid/OFFD455C38.EABDD7C2-ON85256E16.004440D0-85256E16.0044AF6C@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8261 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: <20040109123045.B9A61A0D15@frink.w3.org> Resent-Date: Fri, 9 Jan 2004 07:30:45 -0500 (EST) One possibility is to have an additional argument to MKREDIRECTREF, e.g. DAV:stable, that means that the client forbids the server from auto-updating the reference. A client that doesn't care would leave off this parameter, and the server would do what it wanted, while a client that cared would specify this parameter, and a server that doesn't support stable redirectref's would fail the request. Cheers, Geoff Julian wrote on 01/07/2004 06:43:30 PM: > > Geoffrey M Clemm wrote: > > I don't see why we couldn't require this (redirects created by some other > > mechanism don't have to act the same way as redirects created by > > MKREDIRECTREF. > > > > So we could/should say that the value of a redirectref changes only when > > it is explicitly updated by a PROPPATCH of the DAV:reftarget property, > > and not as a side-effect of some other operation such as MOVE. > > That's exactly what I *don't* want to say, because in reality there are > servers that have a concept of redirect reference resources, *although* > they auto-update their target. This is completely consistent with > RFC2616, and I don't see why the redirect spec can or should *forbid* > that. I do agree that this behaviour may be confusing, and that it makes > sense to discourage it, but we can't change what's already there... > > Julian > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Fri Jan 9 10:55:12 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08501 for ; Fri, 9 Jan 2004 10:55:12 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id C9372A051A; Wed, 7 Jan 2004 18:14:24 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 2F5DCA05D9 for ; Wed, 7 Jan 2004 18:14:21 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 378CF13CA0; Wed, 7 Jan 2004 18:14:21 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by dr-nick.w3.org (Postfix) with ESMTP id 1036E1355A for ; Wed, 7 Jan 2004 18:14:21 -0500 (EST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i07NEK9n691008 for ; Wed, 7 Jan 2004 18:14:20 -0500 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i07NEJ6r204518 for ; Wed, 7 Jan 2004 18:14:20 -0500 In-Reply-To: <3FF95B4A.4050703@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, 7 Jan 2004 18:14:18 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 01/07/2004 18:14:20, Serialize complete at 01/07/2004 18:14:20 Content-Type: text/plain; charset="US-ASCII" Subject: Re: redirect references protocol: MKRESOURCE issue X-Archived-At: http://www.w3.org/mid/OFFFDDA412.8589699C-ON85256E14.007F4499-85256E14.007FA790@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8254 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: <20040107231424.C9372A051A@frink.w3.org> Resent-Date: Wed, 7 Jan 2004 18:14:24 -0500 (EST) I would suggest that we resolve these issues as follows: - allow PROPPATCH to update the DAV:reftarget property - have an additional property that specifies the status that will be returned, e.g. DAV:redirectref-status that has an integer value of either 301 or 302. Cheers, Geoff Julian on 01/05/2004 07:40:42 AM: > > Hi, > > there was an outstanding issue to replace MKRESOURCE by a less generic > method that only creates redirects and does not overlap with PROPPATCH. > > This was added in the current edits at > protocol-latest.html#METHOD_MKREDIRECTREF>. > > The following issues remain: > > - missing ability to update the target without having to delete and > re-create the redirect resource (proposal: just add UPDATEREDIRECTREF) > > - missing ability to create specific redirect types (such as those > generating a 301 rather than a 302) > > > Regards, Julian > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Fri Jan 9 10:55:34 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08550 for ; Fri, 9 Jan 2004 10:55:34 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id D3EB0A0524; Mon, 5 Jan 2004 07:29:26 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 436ACA05A7 for ; Mon, 5 Jan 2004 07:29:25 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id A965513E15; Mon, 5 Jan 2004 07:29:24 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 30DE513416 for ; Mon, 5 Jan 2004 07:29:24 -0500 (EST) Received: (qmail 3076 invoked by uid 65534); 5 Jan 2004 12:29:23 -0000 Received: from p50824F29.dip0.t-ipconnect.de (EHLO gmx.de) (80.130.79.41) by mail.gmx.net (mp003) with SMTP; 05 Jan 2004 13:29:23 +0100 X-Authenticated: #1915285 Message-ID: <3FF958A3.3040900@gmx.de> Date: Mon, 05 Jan 2004 13:29:23 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: webdav Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: redirect references protocol: automatic update X-Archived-At: http://www.w3.org/mid/3FF958A3.3040900@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8247 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: <20040105122926.D3EB0A0524@frink.w3.org> Resent-Date: Mon, 5 Jan 2004 07:29:26 -0500 (EST) Content-Transfer-Encoding: 7bit Regarding issue the last call (year 2000) issue: "Add language to forbid servers from automatically updating redirect resources when their targets move." I don't think we can forbid that. This spec consists of (a) clarifications of how a server that supports redirects should behave for specific WebDAV methods, and (b) extensions to explicitly create them (or to apply a method to the redirect itself). As such, we shouldn't add any requirements that HTTP doesn't add. What we could do is (1) note why auto-update may be a bad idea, and possibly (2) define that redirects created by MKREDIRECTREF should not behave that way (or alternatively define more specific resource types). Regards, Julian From w3c-dist-auth-request@w3.org Fri Jan 9 10:55:40 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08571 for ; Fri, 9 Jan 2004 10:55:39 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id E6677A094B; Mon, 5 Jan 2004 12:27:26 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id B5A7DA0A75 for ; Mon, 5 Jan 2004 12:27:25 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 381AE136E9; Mon, 5 Jan 2004 12:27:25 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by dr-nick.w3.org (Postfix) with ESMTP id 21E28132E8 for ; Mon, 5 Jan 2004 12:27:25 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by frink.w3.org (Postfix) with SMTP id 0C20CA0A75 for ; Mon, 5 Jan 2004 12:27:25 -0500 (EST) Received: (qmail 29216 invoked by uid 65534); 5 Jan 2004 17:25:59 -0000 Received: from p50824F29.dip0.t-ipconnect.de (EHLO gmx.de) (80.130.79.41) by mail.gmx.net (mp001) with SMTP; 05 Jan 2004 18:25:59 +0100 X-Authenticated: #1915285 Message-ID: <3FF99E26.1060704@gmx.de> Date: Mon, 05 Jan 2004 18:25:58 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: webdav References: <3FF56E03.3030503@gmx.de> In-Reply-To: <3FF56E03.3030503@gmx.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: edits on BIND draft X-Archived-At: http://www.w3.org/mid/3FF99E26.1060704@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8249 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: <20040105172726.E6677A094B@frink.w3.org> Resent-Date: Mon, 5 Jan 2004 12:27:26 -0500 (EST) Content-Transfer-Encoding: 7bit Julian Reschke wrote: > > On > > : > > - Add issues "ED_authors" and "ED_updates". > - Add section about capability discovery (DAV header). > - Close issue "5.1_LOOP_STATUS" (only use 208 status when client signals > support for the BIND spec). OK, the only open issue that's left (not counting the missing plan how to handle locking) seems to be It seems that there was consensus to say that BIND does update RFC2518, while there's no consensus about the relationship to RFC3253. As this is a minor editorial question, I propose to just say "updated 2518" and to close the issue. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Jan 9 10:55:36 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08568 for ; Fri, 9 Jan 2004 10:55:36 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id E5825A077F; Wed, 7 Jan 2004 18:18:50 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 69751A077F for ; Wed, 7 Jan 2004 18:18:50 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 75BE513CA0; Wed, 7 Jan 2004 18:18:50 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from NSNOVPS00411.nacio.xythos.com (212-59.84.64.master-link.com [64.84.59.212]) by dr-nick.w3.org (Postfix) with ESMTP id 1DE2013C5B for ; Wed, 7 Jan 2004 18:18:50 -0500 (EST) Received: from lisalap ([198.144.201.117]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 7 Jan 2004 15:18:46 -0800 From: "Lisa Dusseault" To: "'Geoffrey M Clemm'" , "'webdav'" Date: Wed, 7 Jan 2004 15:20:01 -0800 Message-ID: <013f01c3d574$c66c8830$75c990c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-OriginalArrivalTime: 07 Jan 2004 23:18:46.0549 (UTC) FILETIME=[998B9450:01C3D574] Subject: RE: redirect references protocol: MKRESOURCE issue X-Archived-At: http://www.w3.org/mid/013f01c3d574$c66c8830$75c990c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8256 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: <20040107231850.E5825A077F@frink.w3.org> Resent-Date: Wed, 7 Jan 2004 18:18:50 -0500 (EST) Content-Transfer-Encoding: 7bit That does seem simpler to me, if we *do* in fact need both 301-style and 302-style. I recall the explanation that HTTP supports both, but that doesn't prove that WebDAV needs to create both. Are both equally prevalent on the Web? lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Geoffrey M Clemm > Sent: Wednesday, January 07, 2004 3:14 PM > To: webdav > Subject: Re: redirect references protocol: MKRESOURCE issue > > > > I would suggest that we resolve these issues as follows: > > - allow PROPPATCH to update the DAV:reftarget property > > - have an additional property that specifies the status that > will be returned, e.g. DAV:redirectref-status > that has an integer value of either 301 or 302. > > Cheers, > Geoff > > Julian on 01/05/2004 07:40:42 AM: > > > > > Hi, > > > > there was an outstanding issue to replace MKRESOURCE by a > less generic > > method that only creates redirects and does not overlap > with PROPPATCH. > > > > This was added in the current edits at > > > protocol-latest.html#METHOD_MKREDIRECTREF>. > > > > The following issues remain: > > > > - missing ability to update the target without having to delete and > > re-create the redirect resource (proposal: just add > UPDATEREDIRECTREF) > > > > - missing ability to create specific redirect types (such as those > > generating a 301 rather than a 302) > > > > > > Regards, Julian > > > > > > -- > > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > > From w3c-dist-auth-request@w3.org Fri Jan 9 11:27:28 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11547 for ; Fri, 9 Jan 2004 11:27:27 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 24184A0706; Wed, 7 Jan 2004 18:29:29 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id DCC52A0706 for ; Wed, 7 Jan 2004 18:29:25 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id ECA4F13E05; Wed, 7 Jan 2004 18:23:16 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by dr-nick.w3.org (Postfix) with ESMTP id CA27913DFE for ; Wed, 7 Jan 2004 18:23:16 -0500 (EST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id i07NNGKc262914 for ; Wed, 7 Jan 2004 18:23:16 -0500 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i07NNF6r168706 for ; Wed, 7 Jan 2004 18:23:16 -0500 In-Reply-To: <013f01c3d574$c66c8830$75c990c6@lisalap> 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, 7 Jan 2004 18:23:13 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 01/07/2004 18:23:15, Serialize complete at 01/07/2004 18:23:15 Content-Type: text/plain; charset="US-ASCII" Subject: RE: redirect references protocol: MKRESOURCE issue X-Archived-At: http://www.w3.org/mid/OF20B4F4CC.35DF2779-ON85256E14.00804DBC-85256E14.008078C5@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8257 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: <20040107232929.24184A0706@frink.w3.org> Resent-Date: Wed, 7 Jan 2004 18:29:29 -0500 (EST) I don't know whether they are equally prevalent, but I certainly see many examples of each (and know of web-indexing programs that act differently depending on which it sees). Cheers, Geoff Lisa wrote on 01/07/2004 06:20:01 PM: > > That does seem simpler to me, if we *do* in fact need both 301-style and > 302-style. I recall the explanation that HTTP supports both, but that > doesn't > prove that WebDAV needs to create both. Are both equally prevalent on the > Web? > > lisa > > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Geoffrey M Clemm > > Sent: Wednesday, January 07, 2004 3:14 PM > > To: webdav > > Subject: Re: redirect references protocol: MKRESOURCE issue > > > > > > > > I would suggest that we resolve these issues as follows: > > > > - allow PROPPATCH to update the DAV:reftarget property > > > > - have an additional property that specifies the status that > > will be returned, e.g. DAV:redirectref-status > > that has an integer value of either 301 or 302. > > > > Cheers, > > Geoff > > > > Julian on 01/05/2004 07:40:42 AM: > > > > > > > > Hi, > > > > > > there was an outstanding issue to replace MKRESOURCE by a > > less generic > > > method that only creates redirects and does not overlap > > with PROPPATCH. > > > > > > This was added in the current edits at > > > > > protocol-latest.html#METHOD_MKREDIRECTREF>. > > > > > > The following issues remain: > > > > > > - missing ability to update the target without having to delete and > > > re-create the redirect resource (proposal: just add > > UPDATEREDIRECTREF) > > > > > > - missing ability to create specific redirect types (such as those > > > generating a 301 rather than a 302) > > > > > > > > > Regards, Julian > > > > > > > > > -- > > > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > > > > > > From w3c-dist-auth-request@w3.org Fri Jan 9 11:27:58 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11623 for ; Fri, 9 Jan 2004 11:27:57 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 9C32AA053A; Wed, 7 Jan 2004 12:58:06 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id B387CA053A for ; Wed, 7 Jan 2004 12:58:05 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id E9F1814457; Wed, 7 Jan 2004 12:56:04 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from NSNOVPS00411.nacio.xythos.com (212-59.84.64.master-link.com [64.84.59.212]) by dr-nick.w3.org (Postfix) with ESMTP id 97B0814345 for ; Wed, 7 Jan 2004 12:56:04 -0500 (EST) Received: from lisalap ([198.144.201.117]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 7 Jan 2004 09:56:03 -0800 From: "Lisa Dusseault" To: "'Geoffrey M Clemm'" , Date: Wed, 7 Jan 2004 09:57:18 -0800 Message-ID: <005b01c3d547$b12e1f10$75c990c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-OriginalArrivalTime: 07 Jan 2004 17:56:03.0911 (UTC) FILETIME=[84837D70:01C3D547] Subject: RE: Depth header in a lock refreshing method X-Archived-At: http://www.w3.org/mid/005b01c3d547$b12e1f10$75c990c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8253 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: <20040107175806.9C32AA053A@frink.w3.org> Resent-Date: Wed, 7 Jan 2004 12:58:06 -0500 (EST) Content-Transfer-Encoding: 7bit Another option is to reject the request if the Depth header is present and has the wrong value. lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Geoffrey M Clemm > Sent: Thursday, January 01, 2004 7:02 AM > To: w3c-dist-auth@w3.org > Subject: Re: Depth header in a lock refreshing method > > > > I agree with Julian that option 4 is probably best. > > Cheers, > Geoff > > Julian wrote on 12/31/2003 08:32:11 AM: > > > Stanley Guan wrote: > > > > > Under the topic of "Refreshing Locks", it hints that > > > Client may include a Timeout header. But, Depth header > > > has not being mentioned. > > > > > > Under the topic of "Depth and Locking", it discussed > > > what will happen if "Depth" header is specified for > > > creating a new lock. But, nothing was mentioned on > > > what's its implication on a lock refreshing command. > > > > > > Should "bis" document clarify this? > > > > Possibly. > > > > In general, methods should ignore unknown headers. In this > particular > > case of course, the Depth header *is* used for LOCK (just only when > > creating new locks). > > > > So the options for LOCK refresh are: > > > > 1) server MUST respect Depth header, possibly changing the > lock scope > > 2) server MAY respect Depth header, possibly changing the lock scope > > 3) server SHOULD ignore Depth header > > 4) server MUST ignore Depth header > > > > As 4) is what currently everybody seems to implement, I'd > propose to > > choose that interpretration and clarify in RFC2518bis. > > From w3c-dist-auth-request@w3.org Fri Jan 9 11:28:20 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11670 for ; Fri, 9 Jan 2004 11:28:20 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id B4AB8A062B; Wed, 7 Jan 2004 12:56:31 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 1E2FFA062B for ; Wed, 7 Jan 2004 12:56:30 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id C4FC01488D; Wed, 7 Jan 2004 12:51:27 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from NSNOVPS00411.nacio.xythos.com (212-59.84.64.master-link.com [64.84.59.212]) by dr-nick.w3.org (Postfix) with ESMTP id 5D8BF13C07 for ; Wed, 7 Jan 2004 12:51:27 -0500 (EST) Received: from lisalap ([198.144.201.117]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 7 Jan 2004 09:51:25 -0800 From: "Lisa Dusseault" To: "'Jonathan Yu'" , Date: Wed, 7 Jan 2004 09:52:40 -0800 Message-ID: <005a01c3d547$0b7ab010$75c990c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <4B8C03F38DC96546BDFE17179204CDA6060EA40E@CALGARYMAIL01.cpr.ca> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-OriginalArrivalTime: 07 Jan 2004 17:51:25.0911 (UTC) FILETIME=[DED00E70:01C3D546] Subject: RE: cdo and webdav X-Archived-At: http://www.w3.org/mid/005a01c3d547$0b7ab010$75c990c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8252 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: <20040107175631.B4AB8A062B@frink.w3.org> Resent-Date: Wed, 7 Jan 2004 12:56:31 -0500 (EST) Content-Transfer-Encoding: quoted-printable This resource explains how to use HTTP/WebDAV PUT to add a message to outbox: http://msdn.microsoft.com/library/en-us/e2k3/e2k3/_esdk_sending_a_message= _we bdav.asp This page explains how to use PROPPATCH to create a new calendar appointment: http://support.microsoft.com/default.aspx?scid=3Dkb;EN-US;q308373 Each of these help pages shows code, not HTTP/WebDAV requests, but you = can glean the request information from the code. Either of these two methods should work for inbox, as well. You will = have to figure out which properties to PROPPATCH to create a valid email or = other item, but you can figure that out by doing PROPFIND on existing = resources inside an inbox. Also, the Exchange property schema is documented here: http://msdn.microsoft.com/library/en-us/dnmes2k/html/wssschemause.asp Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org=20 > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Jonathan Yu > Sent: Wednesday, January 07, 2004 8:55 AM > To: w3c-dist-auth@w3.org > Subject: cdo and webdav >=20 >=20 >=20 >=20 > Hi, >=20 > Currently, we are using microsoft CDO to send email to the=20 > microsoft exchange inbox. How does WEBDAV apply to this=20 > process? What methods can I use to do the same in WEBDAV? >=20 > Appreciate if someone can respond. > Jonathan Yu (403)319-6633 >=20 >=20 >=20 From w3c-dist-auth-request@w3.org Fri Jan 9 11:40:54 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08423 for ; Fri, 9 Jan 2004 10:54:12 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 16A97A08B9; Fri, 9 Jan 2004 08:48:56 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 8B79CA0F39 for ; Fri, 9 Jan 2004 08:48:48 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id F29B4140E3; Fri, 9 Jan 2004 08:45:27 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by dr-nick.w3.org (Postfix) with ESMTP id 9F6B2140BF for ; Fri, 9 Jan 2004 08:45:25 -0500 (EST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e6.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i09DjPDA611968 for ; Fri, 9 Jan 2004 08:45:25 -0500 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i09DjO57118968 for ; Fri, 9 Jan 2004 08:45:24 -0500 In-Reply-To: <3FFEA2B1.7050507@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: Fri, 9 Jan 2004 08:45:19 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 01/09/2004 08:45:24, Serialize complete at 01/09/2004 08:45:24 Content-Type: text/plain; charset="US-ASCII" Subject: Re: redirect references protocol: automatic update X-Archived-At: http://www.w3.org/mid/OF72D14D10.45626C98-ON85256E16.004B674F-85256E16.004B87FF@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8263 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: <20040109134856.16A97A08B9@frink.w3.org> Resent-Date: Fri, 9 Jan 2004 08:48:56 -0500 (EST) I prefer (3), a simple singe resource type, with the other information moved into a set of properties. Cheers, Geoff Julian wrote on 01/09/2004 07:46:41 AM: > > Geoffrey M Clemm wrote: > > One possibility is to have an additional argument to MKREDIRECTREF, > > e.g. DAV:stable, that means that the client forbids the server from > > auto-updating the reference. A client that doesn't care would leave > > off this parameter, and the server would do what it wanted, while a > > client that cared would specify this parameter, and a server that doesn't > > support stable redirectref's would fail the request. > > Yep. > > The thing I'm currently unsure about is how to model the different > properties of a link (stability, response status). Several approaches > come to mind: > > 1) different resource types (redirect-301, redirect-302, ...) > > 2) one resource type with extension elements, such as > > > > 3) one simple resource type with the remaining information moved into > separate properties (like it was proposed for the status). > > Regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Fri Jan 9 11:43:59 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12789 for ; Fri, 9 Jan 2004 11:43:58 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 16C47A08C2; Wed, 7 Jan 2004 18:53:13 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 3AC25A0740 for ; Wed, 7 Jan 2004 18:53:12 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 2ADDA135C4; Wed, 7 Jan 2004 18:53:12 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id A20C81355A for ; Wed, 7 Jan 2004 18:53:11 -0500 (EST) Received: (qmail 19852 invoked by uid 65534); 7 Jan 2004 23:53:09 -0000 Received: from p3EE2472E.dip.t-dialin.net (EHLO gmx.de) (62.226.71.46) by mail.gmx.net (mp018) with SMTP; 08 Jan 2004 00:53:09 +0100 X-Authenticated: #1915285 Message-ID: <3FFC9BD5.2040600@gmx.de> Date: Thu, 08 Jan 2004 00:52:53 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault Cc: "'Geoffrey M Clemm'" , w3c-dist-auth@w3.org References: <005b01c3d547$b12e1f10$75c990c6@lisalap> In-Reply-To: <005b01c3d547$b12e1f10$75c990c6@lisalap> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Depth header in a lock refreshing method X-Archived-At: http://www.w3.org/mid/3FFC9BD5.2040600@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8260 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: <20040107235313.16C47A08C2@frink.w3.org> Resent-Date: Wed, 7 Jan 2004 18:53:13 -0500 (EST) Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > Another option is to reject the request if the Depth header is present and > has the wrong value. That's another good option. However, this may be breaking existing code (that for some reason sends bogus Depth headers for LOCK refresh). I'll test that and report back. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Jan 9 11:43:59 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12790 for ; Fri, 9 Jan 2004 11:43:58 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 1A3D4A0676; Wed, 7 Jan 2004 18:47:04 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id DACFFA0D43 for ; Wed, 7 Jan 2004 18:45:37 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 2492B14536; Wed, 7 Jan 2004 18:43:43 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 9657D14540 for ; Wed, 7 Jan 2004 18:43:42 -0500 (EST) Received: (qmail 29045 invoked by uid 65534); 7 Jan 2004 23:43:41 -0000 Received: from p3EE2472E.dip.t-dialin.net (EHLO gmx.de) (62.226.71.46) by mail.gmx.net (mp002) with SMTP; 08 Jan 2004 00:43:41 +0100 X-Authenticated: #1915285 Message-ID: <3FFC99A2.6030100@gmx.de> Date: Thu, 08 Jan 2004 00:43:30 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 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=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: redirect references protocol: automatic update X-Archived-At: http://www.w3.org/mid/3FFC99A2.6030100@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8258 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: <20040107234704.1A3D4A0676@frink.w3.org> Resent-Date: Wed, 7 Jan 2004 18:47:04 -0500 (EST) Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > I don't see why we couldn't require this (redirects created by some other > mechanism don't have to act the same way as redirects created by > MKREDIRECTREF. > > So we could/should say that the value of a redirectref changes only when > it is explicitly updated by a PROPPATCH of the DAV:reftarget property, > and not as a side-effect of some other operation such as MOVE. That's exactly what I *don't* want to say, because in reality there are servers that have a concept of redirect reference resources, *although* they auto-update their target. This is completely consistent with RFC2616, and I don't see why the redirect spec can or should *forbid* that. I do agree that this behaviour may be confusing, and that it makes sense to discourage it, but we can't change what's already there... Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Jan 9 11:44:26 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12825 for ; Fri, 9 Jan 2004 11:44:26 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 4DF9CA072E; Wed, 7 Jan 2004 18:50:14 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 200D9A072E for ; Wed, 7 Jan 2004 18:50:13 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 126021350A; Wed, 7 Jan 2004 18:50:13 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 8A3E51355A for ; Wed, 7 Jan 2004 18:50:12 -0500 (EST) Received: (qmail 27884 invoked by uid 65534); 7 Jan 2004 23:50:10 -0000 Received: from p3EE2472E.dip.t-dialin.net (EHLO gmx.de) (62.226.71.46) by mail.gmx.net (mp004) with SMTP; 08 Jan 2004 00:50:10 +0100 X-Authenticated: #1915285 Message-ID: <3FFC9B27.508@gmx.de> Date: Thu, 08 Jan 2004 00:49:59 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 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=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: redirect references protocol: MKRESOURCE issue X-Archived-At: http://www.w3.org/mid/3FFC9B27.508@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8259 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: <20040107235014.4DF9CA072E@frink.w3.org> Resent-Date: Wed, 7 Jan 2004 18:50:14 -0500 (EST) Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > I would suggest that we resolve these issues as follows: > > - allow PROPPATCH to update the DAV:reftarget property Historically, people wanted the spec to be independant of WebDAV, so they wouldn't need full PROPPATCH support for the updated. However, that was over three years ago. So yes, unless somebody pushes back, making these PROPPATCHable would work to. > - have an additional property that specifies the status that > will be returned, e.g. DAV:redirectref-status > that has an integer value of either 301 or 302. Sounds good. Thanks for the feedback, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Jan 9 11:45:03 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12848 for ; Fri, 9 Jan 2004 11:45:03 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 87FF4A0625; Wed, 7 Jan 2004 09:22:13 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 97212A0625 for ; Wed, 7 Jan 2004 09:22:12 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id A3C8313936; Wed, 7 Jan 2004 09:22:12 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by dr-nick.w3.org (Postfix) with ESMTP id BDE1A137DD for ; Wed, 7 Jan 2004 09:22:11 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11035; Wed, 7 Jan 2004 09:22:09 -0500 (EST) Message-Id: <200401071422.JAA11035@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Wed, 07 Jan 2004 09:22:08 -0500 Subject: I-D ACTION:draft-ietf-webdav-acl-13.txt X-Archived-At: http://www.w3.org/mid/200401071422.JAA11035@ietf.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8250 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: <20040107142213.87FF4A0625@frink.w3.org> Resent-Date: Wed, 7 Jan 2004 09:22:13 -0500 (EST) --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 : WebDAV Access Control Protocol Author(s) : G. Clemm Filename : draft-ietf-webdav-acl-13.txt Pages : 83 Date : 2004-1-6 This document specifies a set of methods, headers, message bodies, properties, and reports that define Access Control extensions to the WebDAV Distributed Authoring Protocol. This protocol permits a client to read and modify access control lists that instruct a server whether to allow or deny operations upon a resource (such as HyperText Transfer Protocol (HTTP) method invocations) by a given principal. A lightweight representation of principals as Web resources supports integration of a wide range of user management repositories. Search operations allow discovery and manipulation of principals using human names. This document is a product of the Web Distributed Authoring and Versioning (WebDAV) working group of the Internet Engineering Task Force. Comments on this draft are welcomed, and should be addressed to the acl@webdav.org mailing list. Other related documents can be found at http://www.example.com/acl/, and http://www.ics.uci.edu/pub/ietf/webdav/. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-acl-13.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-acl-13.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-acl-13.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: <2004-1-6164901.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-acl-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-acl-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-6164901.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Fri Jan 9 11:47:09 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12998 for ; Fri, 9 Jan 2004 11:47:08 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 96045A08BF; Wed, 7 Jan 2004 11:54:57 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 2747FA07D6 for ; Wed, 7 Jan 2004 11:54:56 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 1A51913536; Wed, 7 Jan 2004 11:54:56 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from CALCPRSMTP01.cpr.ca (unknown [209.115.235.79]) by dr-nick.w3.org (Postfix) with SMTP id 575E7135A0 for ; Wed, 7 Jan 2004 11:54:55 -0500 (EST) Received: from CALGARYMAIL01.cpr.ca ([10.176.16.65]) by CALCPRSMTP01.cpr.ca with Microsoft SMTPSVC(5.0.2195.5329); Wed, 7 Jan 2004 09:54:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Jan 2004 09:54:54 -0700 Message-ID: <4B8C03F38DC96546BDFE17179204CDA6060EA40E@CALGARYMAIL01.cpr.ca> Thread-Topic: cdo and webdav Thread-Index: AcPVPvlrpqaQhg7cSMub8A9tsLvTcQ== From: "Jonathan Yu" To: X-OriginalArrivalTime: 07 Jan 2004 16:54:54.0829 (UTC) FILETIME=[F99201D0:01C3D53E] Subject: cdo and webdav X-Archived-At: http://www.w3.org/mid/4B8C03F38DC96546BDFE17179204CDA6060EA40E@CALGARYMAIL01.cpr.ca Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8251 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: <20040107165457.96045A08BF@frink.w3.org> Resent-Date: Wed, 7 Jan 2004 11:54:57 -0500 (EST) Content-Transfer-Encoding: quoted-printable Hi, Currently, we are using microsoft CDO to send email to the microsoft = exchange inbox. How does WEBDAV apply to this process? What methods = can I use to do the same in WEBDAV? Appreciate if someone can respond. Jonathan Yu (403)319-6633 From w3c-dist-auth-request@w3.org Fri Jan 9 11:48:08 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13080 for ; Fri, 9 Jan 2004 11:48:08 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id E80C1A0750; Mon, 5 Jan 2004 07:43:28 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 2E5E0A0913 for ; Mon, 5 Jan 2004 07:43:11 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 4DAE8143AF; Mon, 5 Jan 2004 07:40:44 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id C3AB3143AC for ; Mon, 5 Jan 2004 07:40:43 -0500 (EST) Received: (qmail 19118 invoked by uid 65534); 5 Jan 2004 12:40:43 -0000 Received: from p50824F29.dip0.t-ipconnect.de (EHLO gmx.de) (80.130.79.41) by mail.gmx.net (mp021) with SMTP; 05 Jan 2004 13:40:43 +0100 X-Authenticated: #1915285 Message-ID: <3FF95B4A.4050703@gmx.de> Date: Mon, 05 Jan 2004 13:40:42 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: webdav Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: redirect references protocol: MKRESOURCE issue X-Archived-At: http://www.w3.org/mid/3FF95B4A.4050703@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8248 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: <20040105124328.E80C1A0750@frink.w3.org> Resent-Date: Mon, 5 Jan 2004 07:43:28 -0500 (EST) Content-Transfer-Encoding: 7bit Hi, there was an outstanding issue to replace MKRESOURCE by a less generic method that only creates redirects and does not overlap with PROPPATCH. This was added in the current edits at . The following issues remain: - missing ability to update the target without having to delete and re-create the redirect resource (proposal: just add UPDATEREDIRECTREF) - missing ability to create specific redirect types (such as those generating a 301 rather than a 302) Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Jan 9 12:12:58 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14459 for ; Fri, 9 Jan 2004 12:12:58 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id BD8DBA1026; Fri, 9 Jan 2004 12:12:55 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 9B386A1020 for ; Fri, 9 Jan 2004 12:12:48 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 9FD5B1373F; Fri, 9 Jan 2004 12:12:48 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from dream.darwin.nasa.gov (betlik.darwin.nasa.gov [198.123.160.11]) by dr-nick.w3.org (Postfix) with ESMTP id 301D413650 for ; Fri, 9 Jan 2004 12:12:48 -0500 (EST) Received: from cse.ucsc.edu (paperweight.darwin.nasa.gov [198.123.160.27]) by dream.darwin.nasa.gov ( -- Info omitted by ASANI Solutions, LLC.) with ESMTP id i09HCZP16390 for ; Fri, 9 Jan 2004 09:12:37 -0800 (PST) Message-ID: <3FFEE103.6090303@cse.ucsc.edu> Date: Fri, 09 Jan 2004 09:12:35 -0800 From: Elias Sinderson User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: webdav References: Content-Type: multipart/alternative; boundary="------------080108040603000607090705" Subject: Re: redirect references protocol: automatic update X-Archived-At: http://www.w3.org/mid/3FFEE103.6090303@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8264 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: <20040109171255.BD8DBA1026@frink.w3.org> Resent-Date: Fri, 9 Jan 2004 12:12:55 -0500 (EST) --------------080108040603000607090705 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I also think that the third option would be best. Elias Geoffrey M Clemm wrote: >I prefer (3), a simple singe resource type, with the other information >moved into a set of properties. > >Cheers, >Geoff > >Julian wrote on 01/09/2004 07:46:41 AM: > > > >>Geoffrey M Clemm wrote: >> >> >>>One possibility is to have an additional argument to MKREDIRECTREF, >>>e.g. DAV:stable, that means that the client forbids the server from >>>auto-updating the reference. A client that doesn't care would leave >>>off this parameter, and the server would do what it wanted, while a >>>client that cared would specify this parameter, and a server that >>> >>> >doesn't > > >>>support stable redirectref's would fail the request. >>> >>> >>Yep. >> >>The thing I'm currently unsure about is how to model the different >>properties of a link (stability, response status). Several approaches >>come to mind: >> >>1) different resource types (redirect-301, redirect-302, ...) >> >>2) one resource type with extension elements, such as >> >> >> >>3) one simple resource type with the remaining information moved into >>separate properties (like it was proposed for the status). >> >>Regards, Julian >> >>-- >>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 >> >> >> --------------080108040603000607090705 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I also think that the third option would be best.


Elias


Geoffrey M Clemm wrote:
I prefer (3), a simple singe resource type, with the other information 
moved into a set of properties.

Cheers,
Geoff

Julian wrote on 01/09/2004 07:46:41 AM:

  
Geoffrey M Clemm wrote:
    
One possibility is to have an additional argument to MKREDIRECTREF,
e.g. DAV:stable, that means that the client forbids the server from
auto-updating the reference.  A client that doesn't care would leave
off this parameter, and the server would do what it wanted, while a
client that cared would specify this parameter, and a server that 
      
doesn't
  
support stable redirectref's would fail the request.
      
Yep.

The thing I'm currently unsure about is how to model the different 
properties of a link (stability, response status). Several approaches 
come to mind:

1) different resource types (redirect-301, redirect-302, ...)

2) one resource type with extension elements, such as

   <redirect-ref><status301/><stable/></redirect-ref>

3) one simple resource type with the remaining information moved into 
separate properties (like it was proposed for the status).

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

--------------080108040603000607090705-- From w3c-dist-auth-request@w3.org Sun Jan 11 07:02:56 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24692 for ; Sun, 11 Jan 2004 07:02:56 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id C1090A0688; Sun, 11 Jan 2004 07:02:57 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 6658DA100E for ; Sun, 11 Jan 2004 07:02:56 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 6408914613; Sun, 11 Jan 2004 07:02:56 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id C85D414602 for ; Sun, 11 Jan 2004 07:02:55 -0500 (EST) Received: (qmail 23222 invoked by uid 65534); 11 Jan 2004 12:02:45 -0000 Received: from p3EE2473F.dip.t-dialin.net (EHLO gmx.de) (62.226.71.63) by mail.gmx.net (mp004) with SMTP; 11 Jan 2004 13:02:45 +0100 X-Authenticated: #1915285 Message-ID: <40013B35.9080803@gmx.de> Date: Sun, 11 Jan 2004 13:01:57 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: webdav References: <3FF56E03.3030503@gmx.de> In-Reply-To: <3FF56E03.3030503@gmx.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: edits on BIND draft X-Archived-At: http://www.w3.org/mid/40013B35.9080803@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8265 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: <20040111120257.C1090A0688@frink.w3.org> Resent-Date: Sun, 11 Jan 2004 07:02:57 -0500 (EST) Content-Transfer-Encoding: 7bit Julian Reschke wrote: On : Add and close issues "9.2_redirect_loops", "ED_authors" and "ED_updates". Add section about capability discovery (DAV header). Close issues "5.1_LOOP_STATUS". In particular, the explanation for status 208 has been rewritten stating that it will only occur for collections upon Depth: infinity, the example has been fixed (DAV header added) and another example for a non-BIND-aware client was added. In addition, in section 8 the description for the DAV *request* header has been expanded. Feedback appreciated, Julian - TXT version of the updated sections - 7. Additional Status Codes 7.1 208 Already Reported The 208 (Already Reported) status code can be used inside a DAV:propstat response element to avoid enumerating the internal members of multiple bindings to the same collection repeatedly. For each binding to a collection inside the request's scope, only one will be reported with a 200 status, while subsequent DAV:response elements for all other bindings will use the 208 status, and no DAV:response elements for their descendants are included. Note that the 208 status will only occur for "Depth: infinity" requests, and that it is of particular importance when the multiple collection bindings cause a bind loop as discussed in Section 2.2. A client can request the DAV:resourceid property in a PROPFIND request to guarantee that they can accurately reconstruct the binding structure of a collection with multiple bindings to a single resource. For backward compatibility with clients not aware of the 208 status code appearing in multistatus response bodies, it SHOULD NOT be used unless the client has signalled support for this specification using the "DAV" request header (see Section 8.2). Otherwise the entire PROPFIND request MUST fail with the 506 status described below. 7.1.1 Example: PROPFIND by bind-aware client For example, consider a PROPFIND request on /Coll (bound to collection C), where the members of /Coll are /Coll/Foo (bound to resource R) and /Coll/Bar (bound to collection C). >> Request: PROPFIND /Coll/ HTTP/1.1 Host: www.example.com Depth: infinity DAV: bind Content-Type: text/xml; charset="utf-8" Content-Length: xxx >> Response: HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxx http://www.example.com/Coll/ Loop Demo HTTP/1.1 200 OK http://www.example.com/Coll/Foo Bird Inventory HTTP/1.1 200 OK http://www.example.com/Coll/Bar Loop Demo HTTP/1.1 208 Already Reported 7.1.2 Example: PROPFIND by non-bind-aware client In this example, the client isn't aware of the 208 status code introduced by this specification. As the "Depth: infinity" PROPFIND request would cause a loop condition, the whole request is rejected with a 506 status. >> Request: PROPFIND /Coll/ HTTP/1.1 Host: www.example.com Depth: infinity Content-Type: text/xml; charset="utf-8" Content-Length: xxx >> Response: HTTP/1.1 506 Loop Detected 7.2 506 Loop Detected The 506 (Loop Detected) status code indicates that the server terminated an operation because it encountered an infinite loop while processing a request with "Depth: infinity". This status indicates that the entire operation failed. 8. Capability discovery 8.1 OPTIONS method If the server supports bindings, it MUST return the compliance class name "bind" as a field in the "DAV" response header (see [RFC2518], section 9.1) from an OPTIONS request on any resource implemented by that server. A value of "bind" in the "DAV" header MUST indicate that the server supports all MUST level requirements and REQUIRED features specified in this document. 8.2 'DAV' request header 8.2.1 Generic syntax This specification introduces the 'DAV' request header that allows clients to signal compliance to specific WebDAV features. It has the same syntax as the response header defined in [RFC2518], section 9.1, but MAY be used with any method. Note that clients MUST NOT submit a specific compliance class name in the request header unless the specification defining this compliance class specifically defines it's semantics for clients. Note that if a server chooses to vary the result of a request based on values in the "DAV" header, the response either MUST NOT be cacheable or the server MUST mark the response accordingly using the "Vary" header (see [RFC2616], section 14.44). 8.2.2 Client compliance class 'bind' Clients SHOULD signal support for all MUST level requirements and REQUIRED features by submitting a "DAV" request header containing the compliance class name "bind". In particular, the client MUST understand the 208 status code defined in Section 7.1. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sun Jan 11 19:45:19 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24381 for ; Sun, 11 Jan 2004 19:45:08 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id CC8E8A0854; Sun, 11 Jan 2004 19:44:53 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 8B585A0854 for ; Sun, 11 Jan 2004 19:44:52 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 6CAFE13379; Sun, 11 Jan 2004 19:44:52 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by dr-nick.w3.org (Postfix) with ESMTP id 1AA6B13367 for ; Sun, 11 Jan 2004 19:44:52 -0500 (EST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e6.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0C0ipDA735842 for ; Sun, 11 Jan 2004 19:44:51 -0500 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0C0ioRD200648 for ; Sun, 11 Jan 2004 19:44:50 -0500 In-Reply-To: <40013B35.9080803@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, 11 Jan 2004 19:44:42 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 01/11/2004 19:44:50, Serialize complete at 01/11/2004 19:44:50 Content-Type: text/plain; charset="US-ASCII" Subject: Re: edits on BIND draft X-Archived-At: http://www.w3.org/mid/OF7A5BA7BD.6335DE39-ON85256E19.00029CC1-85256E19.00041044@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8266 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: <20040112004453.CC8E8A0854@frink.w3.org> Resent-Date: Sun, 11 Jan 2004 19:44:53 -0500 (EST) I believe the previous wording of the 208 section was better, and should be restored. In particular, I don't see why status 208 should be restricted to collections (if you have multiple bindings to a non-collection, a server should be able to generate 208's for that as well). Also, I don't see why it should be restricted to Depth:infinity (it can arise for Depth:1). The new sections on the DAV header are good. Cheers, Geoff Julian wrote on 01/11/2004 07:01:57 AM: > > Julian Reschke wrote: > > > On > > : > > Add and close issues "9.2_redirect_loops", "ED_authors" and > "ED_updates". Add section about capability discovery (DAV header). > Close issues "5.1_LOOP_STATUS". > > In particular, the explanation for status 208 has been rewritten stating > that it will only occur for collections upon Depth: infinity, the > example has been fixed (DAV header added) and another example for a > non-BIND-aware client was added. In addition, in section 8 the > description for the DAV *request* header has been expanded. > > Feedback appreciated, > > Julian > > - TXT version of the updated sections - > > 7. Additional Status Codes > > 7.1 208 Already Reported > > The 208 (Already Reported) status code can be used inside a > DAV:propstat response element to avoid enumerating the internal > members of multiple bindings to the same collection repeatedly. For > each binding to a collection inside the request's scope, only one > will be reported with a 200 status, while subsequent DAV:response > elements for all other bindings will use the 208 status, and no > DAV:response elements for their descendants are included. > > Note that the 208 status will only occur for "Depth: infinity" > requests, and that it is of particular importance when the multiple > collection bindings cause a bind loop as discussed in Section 2.2. > > A client can request the DAV:resourceid property in a PROPFIND > request to guarantee that they can accurately reconstruct the binding > structure of a collection with multiple bindings to a single > resource. > > For backward compatibility with clients not aware of the 208 status > code appearing in multistatus response bodies, it SHOULD NOT be used > unless the client has signalled support for this specification using > the "DAV" request header (see Section 8.2). Otherwise the entire > PROPFIND request MUST fail with the 506 status described below. > > 7.1.1 Example: PROPFIND by bind-aware client > > For example, consider a PROPFIND request on /Coll (bound to > collection C), where the members of /Coll are /Coll/Foo (bound to > resource R) and /Coll/Bar (bound to collection C). > > >> Request: > > PROPFIND /Coll/ HTTP/1.1 > Host: www.example.com > Depth: infinity > DAV: bind > Content-Type: text/xml; charset="utf-8" > Content-Length: xxx > > > > > > > > >> Response: > > HTTP/1.1 207 Multi-Status > Content-Type: text/xml; charset="utf-8" > Content-Length: xxx > > > > > http://www.example.com/Coll/ > > > Loop Demo > > HTTP/1.1 200 OK > > > > http://www.example.com/Coll/Foo > > > Bird Inventory > > HTTP/1.1 200 OK > > > > http://www.example.com/Coll/Bar > > > > Loop Demo > > HTTP/1.1 208 Already Reported > > > > > > 7.1.2 Example: PROPFIND by non-bind-aware client > > In this example, the client isn't aware of the 208 status code > introduced by this specification. As the "Depth: infinity" PROPFIND > request would cause a loop condition, the whole request is rejected > with a 506 status. > > >> Request: > > PROPFIND /Coll/ HTTP/1.1 > Host: www.example.com > Depth: infinity > Content-Type: text/xml; charset="utf-8" > Content-Length: xxx > > > > > > > >> Response: > > HTTP/1.1 506 Loop Detected > > > 7.2 506 Loop Detected > > The 506 (Loop Detected) status code indicates that the server > terminated an operation because it encountered an infinite loop while > processing a request with "Depth: infinity". This status indicates > that the entire operation failed. > > 8. Capability discovery > > 8.1 OPTIONS method > > If the server supports bindings, it MUST return the compliance class > name "bind" as a field in the "DAV" response header (see [RFC2518], > section 9.1) from an OPTIONS request on any resource implemented by > that server. A value of "bind" in the "DAV" header MUST indicate that > the server supports all MUST level requirements and REQUIRED features > specified in this document. > > 8.2 'DAV' request header > > 8.2.1 Generic syntax > > This specification introduces the 'DAV' request header that allows > clients to signal compliance to specific WebDAV features. It has the > same syntax as the response header defined in [RFC2518], section 9.1, > but MAY be used with any method. > > Note that clients MUST NOT submit a specific compliance class name in > the request header unless the specification defining this compliance > class specifically defines it's semantics for clients. > > Note that if a server chooses to vary the result of a request based > on values in the "DAV" header, the response either MUST NOT be > cacheable or the server MUST mark the response accordingly using the > "Vary" header (see [RFC2616], section 14.44). > > 8.2.2 Client compliance class 'bind' > > Clients SHOULD signal support for all MUST level requirements and > REQUIRED features by submitting a "DAV" request header containing the > compliance class name "bind". In particular, the client MUST > understand the 208 status code defined in Section 7.1. > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Mon Jan 12 04:05:31 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18705 for ; Mon, 12 Jan 2004 04:05:31 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 18CFCA104C; Mon, 12 Jan 2004 04:05:28 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 4D3D4A10A1 for ; Mon, 12 Jan 2004 04:05:07 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 1D45B140EF; Mon, 12 Jan 2004 03:56:47 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 982F613BBD for ; Mon, 12 Jan 2004 03:56:46 -0500 (EST) Received: (qmail 15396 invoked by uid 65534); 12 Jan 2004 08:56:41 -0000 Received: from pD950C24B.dip.t-dialin.net (EHLO gmx.de) (217.80.194.75) by mail.gmx.net (mp014) with SMTP; 12 Jan 2004 09:56:41 +0100 X-Authenticated: #1915285 Message-ID: <40026124.6030900@gmx.de> Date: Mon, 12 Jan 2004 09:56:04 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 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=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: edits on BIND draft X-Archived-At: http://www.w3.org/mid/40026124.6030900@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8267 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: <20040112090528.18CFCA104C@frink.w3.org> Resent-Date: Mon, 12 Jan 2004 04:05:28 -0500 (EST) Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > I believe the previous wording of the 208 section > was better, and should be restored. Well, we found it to be confusing. Obviously neither is good enough, and we need to work on it :-) > In particular, I don't see why status 208 should be > restricted to collections (if you have multiple bindings > to a non-collection, a server should be able to generate > 208's for that as well). Why would it do that? It could generate a 200 as well. The confusing thing (to us) was not entirely clear about what it means to be "already reported" and when it occur. The intent of the change was to clarify that. > Also, I don't see why it should be restricted to Depth:infinity > (it can arise for Depth:1). Not the way it is defined now. OK, before we discuss the wording, let's try to agree on what it should mean: The intent of the 208 code was to allow PROPFIND to handle bind loops. BIND loops are relevant only for Depth: Infinity operations (for Depth: 0, no bindings are enumerated anyway, for Depth: 1, enumerating another binding to a previously reported collection is harmless). Thus, to achieve this goal in the most simple way, I'd say that the current description is the best one: A 208 is reported instead of a 200 whenever the server decides not to enumerate the children of a particular collection because they have already been reported. This situation (as discussed above) IMHO can only occur for Depth: infinity. > The new sections on the DAV header are good. Thanks, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Jan 12 05:01:49 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20479 for ; Mon, 12 Jan 2004 05:01:48 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id D8AF0A088A; Mon, 12 Jan 2004 05:01:49 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 17234A088A for ; Mon, 12 Jan 2004 05:01:48 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 14CAE13B59; Mon, 12 Jan 2004 05:01:48 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 8962313A44 for ; Mon, 12 Jan 2004 05:01:47 -0500 (EST) Received: (qmail 25426 invoked by uid 65534); 12 Jan 2004 10:01:33 -0000 Received: from pD950C24B.dip.t-dialin.net (EHLO gmx.de) (217.80.194.75) by mail.gmx.net (mp006) with SMTP; 12 Jan 2004 11:01:33 +0100 X-Authenticated: #1915285 Message-ID: <40027064.4020808@gmx.de> Date: Mon, 12 Jan 2004 11:01:08 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: webdav Cc: Geoffrey M Clemm References: <40026124.6030900@gmx.de> In-Reply-To: <40026124.6030900@gmx.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: edits on BIND draft X-Archived-At: http://www.w3.org/mid/40027064.4020808@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8268 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: <20040112100149.D8AF0A088A@frink.w3.org> Resent-Date: Mon, 12 Jan 2004 05:01:49 -0500 (EST) Content-Transfer-Encoding: 7bit Hi, when thinking about actually *implementing* this stuff, I discovered another issue here. Take a server that allows Depth: infinity upon PROPFIND. In general, the only way to implement this efficiently is to *stream* the multistatus response. However this means that the server needs to decide about the HTTP status code to return *prior* to actually doing the recursion. Therefore, requiring the server to return a 506 status in case there's a bind loop somewhere below the request URI will not work. An obvious alternative would be to allow the 506 to be returned inside the DAV:status element for the resource the server refuses to recurse into. Of course that would mean that the client essentially would get a partly incorrect picture of the server state. However, I don't think there's any way to avoid that (except for rejecting all Depth: infinity PROPFINDs, like many servers already do). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Jan 14 09:05:47 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18353 for ; Wed, 14 Jan 2004 09:05:41 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 95C68A0723; Wed, 14 Jan 2004 09:05:32 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 16469A0A98 for ; Wed, 14 Jan 2004 09:05:19 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 1C37914446; Wed, 14 Jan 2004 09:03:37 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 9F28714276 for ; Wed, 14 Jan 2004 09:03:36 -0500 (EST) Received: (qmail 28192 invoked by uid 65534); 14 Jan 2004 14:03:35 -0000 Received: from p5082510E.dip0.t-ipconnect.de (EHLO gmx.de) (80.130.81.14) by mail.gmx.net (mp027) with SMTP; 14 Jan 2004 15:03:35 +0100 X-Authenticated: #1915285 Message-ID: <40054C35.1080902@gmx.de> Date: Wed, 14 Jan 2004 15:03:33 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: locking clarifications/extensions vs BIND draft vs RFC2518bis X-Archived-At: http://www.w3.org/mid/40054C35.1080902@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8269 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: <20040114140532.95C68A0723@frink.w3.org> Resent-Date: Wed, 14 Jan 2004 09:05:32 -0500 (EST) Content-Transfer-Encoding: 7bit Hi, I've been thinking about the best way to get the BIND spec out without neglecting the fact that the interaction between locks and multiple bindings could use a clarification :-) Several approaches come to mind...: 1) Add a section to the BIND spec. From a procedural point of view that would be easiest, but it would IMHO be short-sighted. The aforementioned clarification should be independant of the BIND spec, and in particular needs to be compatible to whatever RFC2518bis will say when it's finished. 2) Come up with a separate spec that updates RFC2518 and just summarizes all that we changed or intend to change regarding locking (like deprecation of lock-null resources, fixes to LOCK and lock refresh, If header syntax, and lockdiscovery extensions). That would still be a "draft standard" as RFC2518, but it would make things easier for RFC2518bis as well, because all these changes would be written down in a spec that came out prior to the revision, so wouldn't be "new" anymore. It would also encourage implementors to actually *implement* these changes and extensions *before* RFC2518bis comes out. 3) A drastic approach would be to de-couple locking entirely from RFC2518 ("updating" RFC2518 again). That would look similar to how RFC3253 is organized (locking would become an optional module, and everything that needs to be said about locking would reside in that separate document). Of course that approach would have a significant impact on RFC2518bis, because optimally, it wouldn't say anything about locking anymore either. From a purely technical point of view, choice 3) has a lot of appeal. Separating the specs should make both more accessible, the base spec would be MUCH simpler, and both specs would be easier to update. Also, getting people to implement basic WebDAV minus locking may be a lot easier if it's decoupled. Of course, that's also the option that would cause the biggest amount of editorial work... On the other hand, I'd understand if people think that we shouldn't mess around too much with both RFC2518 and RFC2518bis. In that case, I see option 2) as a workable alternative. Of course, that approach only makes sense if we can make that activity an official WebDAV working group work item. Feedback appreciated, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Jan 16 15:00:42 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26853 for ; Fri, 16 Jan 2004 15:00:37 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 17AA2A0AD2; Fri, 16 Jan 2004 15:00:23 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id BCDBBA0AD2 for ; Fri, 16 Jan 2004 15:00:21 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id BBC481452F; Fri, 16 Jan 2004 15:00:21 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 4154D134B8 for ; Fri, 16 Jan 2004 15:00:21 -0500 (EST) Received: (qmail 4411 invoked by uid 65534); 16 Jan 2004 20:00:19 -0000 Received: from p3EE24724.dip.t-dialin.net (EHLO gmx.de) (62.226.71.36) by mail.gmx.net (mp009) with SMTP; 16 Jan 2004 21:00:19 +0100 X-Authenticated: #1915285 Message-ID: <400842D1.2020008@gmx.de> Date: Fri, 16 Jan 2004 21:00:17 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <40054C35.1080902@gmx.de> In-Reply-To: <40054C35.1080902@gmx.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: locking clarifications/extensions vs BIND draft vs RFC2518bis X-Archived-At: http://www.w3.org/mid/400842D1.2020008@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8270 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: <20040116200023.17AA2A0AD2@frink.w3.org> Resent-Date: Fri, 16 Jan 2004 15:00:23 -0500 (EST) Content-Transfer-Encoding: 7bit Jason wrote in an off-list mail: > > I'm tempted to just put BIND right into 2518bis -- worst > case we recycle at > > Proposed, which I don't see as being a major adoption > impediment anymore (we > > could perhaps call it WebDAV v2, to make it clear that we're making > > progress). > > I assume there are platforms that would have difficulty implementing > bindings so I suspect we'd want it to be optional. I'd think > that'd be > easier as a separate draft. But I think it's fine, and in I can't imagine problems implementing bindings. I *can* imagine problems implenting *multiple* bindings to the same resource. That's fine. The BIND spec doesn't require servers to actually support multiple bindings, it just defines how these must work (and how they can be discovered/authored) *if* they are supported. > fact advisible, > to establish the basic vocabulary of bindings in 2518 and let > the bindings > draft just cover the optional issues and clarifications for bindings > and multiple bindings. I do agree that RFC2518bis *should* remove any inconsistencies with BIND, where present. Note that one major problem was the definition for DELETE, which (in RFC2518) required to remove all other bindings to the resource as well. AFAIK, this has been fixed in RFC2518bis. So besides the fact that RFC2518bis talks about "internal members" rather than bindings, I'm not really sure that anything *needs* to be fixed. Geoff? Regards, Julian From w3c-dist-auth-request@w3.org Fri Jan 16 15:12:22 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27206 for ; Fri, 16 Jan 2004 15:12:22 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 90B57A0E38; Fri, 16 Jan 2004 15:12:22 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 5A406A11D6 for ; Fri, 16 Jan 2004 15:12:18 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 601C814701; Fri, 16 Jan 2004 15:12:11 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id CC2E2143EE for ; Fri, 16 Jan 2004 15:12:10 -0500 (EST) Received: (qmail 27658 invoked by uid 65534); 16 Jan 2004 20:12:08 -0000 Received: from p3EE24724.dip.t-dialin.net (EHLO gmx.de) (62.226.71.36) by mail.gmx.net (mp021) with SMTP; 16 Jan 2004 21:12:08 +0100 X-Authenticated: #1915285 Message-ID: <40084591.2050008@gmx.de> Date: Fri, 16 Jan 2004 21:12:01 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <40054C35.1080902@gmx.de> In-Reply-To: <40054C35.1080902@gmx.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: locking clarifications/extensions vs BIND draft vs RFC2518bis X-Archived-At: http://www.w3.org/mid/40084591.2050008@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8271 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: <20040116201222.90B57A0E38@frink.w3.org> Resent-Date: Fri, 16 Jan 2004 15:12:22 -0500 (EST) Content-Transfer-Encoding: 7bit In an off-list mail, Geoff Clemm wrote: > I would strongly advocate separating locking from base WebDAV > functionality > for the following reasons: > > - WebDAV is already a family of specs (3253, ACL, redirect, ordering), > each of which defines an optional feature-package beyond what > is defined > in the base spec. It would be more consistent to handle locking > (which is an optional feature-package) the same way. > > - Having a smaller "base WebDAV spec" I believe will make WebDAV more > accessible to new implementors, since the base spec will be > less daunting > in > size. You don't have to read/understand the locking extensions to > understand versioning, ACL, redirect, or ordering, but the current > packaging of locking in with the base protocol makes it look > like you do. > > - It allows us to make more rapid progress on getting the locking > functionality standardized (i.e. it doesn't have to wait until we've > resolved all the other issues in 2518bis). I agree on all these points. However, for this plan to work we need - buy-in from the RFC2518bis authors (Lisa and Jason), - volunteers for the new document and - broad support from the working group members (that is, this mailing list) Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sat Jan 17 03:52:49 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01940 for ; Sat, 17 Jan 2004 03:52:44 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id BDE35A1377; Sat, 17 Jan 2004 03:52:34 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 4CBF1A1377 for ; Sat, 17 Jan 2004 03:52:32 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 42CF814EDC; Sat, 17 Jan 2004 03:52:32 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id B056E14ED2 for ; Sat, 17 Jan 2004 03:52:31 -0500 (EST) Received: (qmail 16690 invoked by uid 65534); 17 Jan 2004 08:52:30 -0000 Received: from p3EE24724.dip.t-dialin.net (EHLO gmx.de) (62.226.71.36) by mail.gmx.net (mp022) with SMTP; 17 Jan 2004 09:52:30 +0100 X-Authenticated: #1915285 Message-ID: <4008F7CD.3000701@gmx.de> Date: Sat, 17 Jan 2004 09:52:29 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <40054C35.1080902@gmx.de> In-Reply-To: <40054C35.1080902@gmx.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: locking clarifications/extensions vs BIND draft vs RFC2518bis X-Archived-At: http://www.w3.org/mid/4008F7CD.3000701@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8272 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: <20040117085234.BDE35A1377@frink.w3.org> Resent-Date: Sat, 17 Jan 2004 03:52:34 -0500 (EST) Content-Transfer-Encoding: 7bit In an off-list mail, Jim Whitehead wrote: > I'm tempted to just put BIND right into 2518bis -- worst case > we recycle at > Proposed, which I don't see as being a major adoption > impediment anymore (we > could perhaps call it WebDAV v2, to make it clear that we're making > progress). Well, I think that would be a radical change to our strategy... Seems that opinions vary between 1) take locking out, keep BIND out, make everyhing more modular and 2) keep locking in, add BIND, publish RFC2518+BIND (staying at the "proposed level") I'd definifively vote for 1). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sat Jan 17 07:53:46 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06714 for ; Sat, 17 Jan 2004 07:53:43 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 1AEF3A0A02; Sat, 17 Jan 2004 07:53:42 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 84000A0A02 for ; Sat, 17 Jan 2004 07:53:40 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 7C521139A7; Sat, 17 Jan 2004 07:53:40 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by dr-nick.w3.org (Postfix) with ESMTP id 5599D13495 for ; Sat, 17 Jan 2004 07:53:40 -0500 (EST) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0HCrdcg662908 for ; Sat, 17 Jan 2004 07:53:39 -0500 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0HCrdK1123286 for ; Sat, 17 Jan 2004 07:53:39 -0500 In-Reply-To: <40084591.2050008@gmx.de> MIME-Version: 1.0 To: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Sat, 17 Jan 2004 07:53:34 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 01/17/2004 07:53:38, Serialize complete at 01/17/2004 07:53:38 Content-Type: text/plain; charset="US-ASCII" Subject: Re: locking clarifications/extensions vs BIND draft vs RFC2518bis X-Archived-At: http://www.w3.org/mid/OF160D66D3.DD88A37F-ON85256E1E.0016DE6A-85256E1E.0046CA40@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8273 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: <20040117125342.1AEF3A0A02@frink.w3.org> Resent-Date: Sat, 17 Jan 2004 07:53:42 -0500 (EST) I am willing to work with Jason on this document. Cheers, Geoff Julian wrote on 01/16/2004 03:12:01 PM: > > In an off-list mail, Geoff Clemm wrote: > > > I would strongly advocate separating locking from base WebDAV > > functionality > > for the following reasons: > > > > - WebDAV is already a family of specs (3253, ACL, redirect, ordering), > > each of which defines an optional feature-package beyond what > > is defined > > in the base spec. It would be more consistent to handle locking > > (which is an optional feature-package) the same way. > > > > - Having a smaller "base WebDAV spec" I believe will make WebDAV more > > accessible to new implementors, since the base spec will be > > less daunting in size. You don't have to > > read/understand the locking extensions to > > understand versioning, ACL, redirect, or ordering, but the current > > packaging of locking in with the base protocol makes it look > > like you do. > > > > - It allows us to make more rapid progress on getting the locking > > functionality standardized (i.e. it doesn't have to wait until we've > > resolved all the other issues in 2518bis). > > I agree on all these points. However, for this plan to work we need > > - buy-in from the RFC2518bis authors (Lisa and Jason), > - volunteers for the new document and > - broad support from the working group members (that is, this mailing list) From w3c-dist-auth-request@w3.org Sat Jan 17 07:56:48 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06743 for ; Sat, 17 Jan 2004 07:56:48 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 5070FA0BC8; Sat, 17 Jan 2004 07:56:48 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 80811A0BC8 for ; Sat, 17 Jan 2004 07:56:47 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 752A013BBC; Sat, 17 Jan 2004 07:56:47 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by dr-nick.w3.org (Postfix) with ESMTP id 492C813A27 for ; Sat, 17 Jan 2004 07:56:47 -0500 (EST) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0HCukvM277182 for ; Sat, 17 Jan 2004 07:56:46 -0500 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0HCukK1111134 for ; Sat, 17 Jan 2004 07:56:46 -0500 In-Reply-To: To: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Sat, 17 Jan 2004 07:56:41 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 01/17/2004 07:56:46, Serialize complete at 01/17/2004 07:56:46 Content-Type: text/plain; charset="US-ASCII" Subject: Re: locking clarifications/extensions vs BIND draft vs RFC2518bis X-Archived-At: http://www.w3.org/mid/OF99F3DB0D.950B4EB6-ON85256E1E.0046F868-85256E1E.004712B7@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8274 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: <20040117125648.5070FA0BC8@frink.w3.org> Resent-Date: Sat, 17 Jan 2004 07:56:48 -0500 (EST) Actually, I meant to say "I am willing to work with Julian on this document", (but I am in fact also willing to work with Jason on this document :-). Cheers, Geoff Geoff wrote on 01/17/2004 07:53:34 AM: > > I am willing to work with Jason on this document. > > Cheers, > Geoff > > Julian wrote on 01/16/2004 03:12:01 PM: > > > > > In an off-list mail, Geoff Clemm wrote: > > > > > I would strongly advocate separating locking from base WebDAV > > > functionality > > > for the following reasons: > > > > > > - WebDAV is already a family of specs (3253, ACL, redirect, > ordering), > > > each of which defines an optional feature-package beyond what > > > is defined > > > in the base spec. It would be more consistent to handle locking > > > (which is an optional feature-package) the same way. > > > > > > - Having a smaller "base WebDAV spec" I believe will make WebDAV more > > > accessible to new implementors, since the base spec will be > > > less daunting in size. You don't have to > > > read/understand the locking extensions to > > > understand versioning, ACL, redirect, or ordering, but the current > > > packaging of locking in with the base protocol makes it look > > > like you do. > > > > > > - It allows us to make more rapid progress on getting the locking > > > functionality standardized (i.e. it doesn't have to wait until we've > > > resolved all the other issues in 2518bis). > > > > I agree on all these points. However, for this plan to work we need > > > > - buy-in from the RFC2518bis authors (Lisa and Jason), > > - volunteers for the new document and > > - broad support from the working group members (that is, this mailing > list) > From w3c-dist-auth-request@w3.org Tue Jan 20 09:04:04 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29992 for ; Tue, 20 Jan 2004 09:04:03 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 422CCA0CD2; Tue, 20 Jan 2004 09:04:01 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id A9F0FA0CE9 for ; Tue, 20 Jan 2004 09:03:32 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 694D813CEE; Tue, 20 Jan 2004 09:03:30 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id CF55D139FC for ; Tue, 20 Jan 2004 09:03:29 -0500 (EST) Received: (qmail 14019 invoked by uid 65534); 20 Jan 2004 14:03:28 -0000 Received: from p50824C7F.dip0.t-ipconnect.de (EHLO gmx.de) (80.130.76.127) by mail.gmx.net (mp012) with SMTP; 20 Jan 2004 15:03:28 +0100 X-Authenticated: #1915285 Message-ID: <400D352D.4040603@gmx.de> Date: Tue, 20 Jan 2004 15:03:25 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Minor issue in RFC2518bis05, DAV:href X-Archived-At: http://www.w3.org/mid/400D352D.4040603@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8275 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: <20040120140401.422CCA0CD2@frink.w3.org> Resent-Date: Tue, 20 Jan 2004 09:04:01 -0500 (EST) Content-Transfer-Encoding: 7bit Hi, the definition for DAV:href was "updated". Previously it referred to RFC2068, now it refers to RFC2616. This is incorrect because RFC2616 is about HTTP, while we need to reference RFC2396 (which defines general URI syntax). Note that in WebDAV, the DAV:href element may contain non-HTTP URIs, such as opaquelocktoken. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Jan 20 11:15:30 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08842 for ; Tue, 20 Jan 2004 11:15:30 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id C752BA06C2; Tue, 20 Jan 2004 11:15:30 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 75645A0A96 for ; Tue, 20 Jan 2004 11:15:29 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 7DED814C14; Tue, 20 Jan 2004 11:15:29 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from usmail.cocreate.com (usmail.cocreate.com [63.119.136.74]) by dr-nick.w3.org (Postfix) with SMTP id 0BC3D14BC2 for ; Tue, 20 Jan 2004 11:15:29 -0500 (EST) Received: from u10sm001.us10.cocreate.com ([10.31.16.131]) by usmail.cocreate.com (SAVSMTP 3.1.2.35) with SMTP id M2004012009151707701 for ; Tue, 20 Jan 2004 09:15:17 -0700 Received: from cocreate.us10.cocreate.com ([10.31.18.3]) by u10sm001.us10.cocreate.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id DAZV4AV8; Tue, 20 Jan 2004 09:15:19 -0700 Received: from cocreate.com ([10.31.21.11]) by cocreate.us10.cocreate.com (8.11.6/8.11.6) with ESMTP id i0KGFOR11461 for ; Tue, 20 Jan 2004 09:15:25 -0700 Message-ID: <400D5401.70403@cocreate.com> Date: Tue, 20 Jan 2004 09:14:57 -0700 From: Jeff Thompson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Client specified properties X-Archived-At: http://www.w3.org/mid/400D5401.70403@cocreate.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8276 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: <20040120161530.C752BA06C2@frink.w3.org> Resent-Date: Tue, 20 Jan 2004 11:15:30 -0500 (EST) Content-Transfer-Encoding: 7bit I've read through the WEBDAV spec and Lisa's book, but there is one area that isn't quite clear to me. Is it expected that a WEBDAV server should accept arbitrary dead properties that the client PROPPATCHs? We've been watching the messages sent by Windows Explorer and we see that it sends several Windows specific properties in a PROPPATCH. Our system naturally has the required properties (or can leave them blank in specific cases). However, we do not have any need for arbitrary client specified properties. Does WEBDAV (clients, servers, or specifications) expect that we do have this capability? Jeff Thompson From w3c-dist-auth-request@w3.org Tue Jan 20 12:32:35 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13781 for ; Tue, 20 Jan 2004 12:32:35 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 4B5D5A0923; Tue, 20 Jan 2004 12:32:31 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id D50D9A09D5 for ; Tue, 20 Jan 2004 12:32:28 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id C5AA715138; Tue, 20 Jan 2004 12:31:01 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from NSNOVPS00411.nacio.xythos.com (212-59.84.64.master-link.com [64.84.59.212]) by dr-nick.w3.org (Postfix) with ESMTP id 57A4815121 for ; Tue, 20 Jan 2004 12:31:01 -0500 (EST) Received: from lisalap ([64.202.9.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Jan 2004 09:30:59 -0800 From: "Lisa Dusseault" To: "'Julian Reschke'" , Date: Tue, 20 Jan 2004 09:32:37 -0800 Message-ID: <015101c3df7b$65e4c9d0$1f01a8c0@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <400D352D.4040603@gmx.de> X-OriginalArrivalTime: 20 Jan 2004 17:30:59.0553 (UTC) FILETIME=[2B376D10:01C3DF7B] Subject: RE: Minor issue in RFC2518bis05, DAV:href X-Archived-At: http://www.w3.org/mid/015101c3df7b$65e4c9d0$1f01a8c0@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8277 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: <20040120173231.4B5D5A0923@frink.w3.org> Resent-Date: Tue, 20 Jan 2004 12:32:31 -0500 (EST) Content-Transfer-Encoding: 7bit Do you think that the ability to contain 'opaquelocktoken' URIs is the sole exception, or is it generally OK for href to contain non-HTTP URLs? I believe the latter would cause some problems among clients. And, is it always ok to have opaquelocktoken URIs in hrefs, or only in certain circumstances? lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Julian Reschke > Sent: Tuesday, January 20, 2004 6:03 AM > To: w3c-dist-auth@w3.org > Subject: Minor issue in RFC2518bis05, DAV:href > > > > Hi, > > the definition for DAV:href was "updated". Previously it referred to > RFC2068, now it refers to RFC2616. This is incorrect because > RFC2616 is > about HTTP, while we need to reference RFC2396 (which defines general > URI syntax). > > Note that in WebDAV, the DAV:href element may contain non-HTTP URIs, > such as opaquelocktoken. > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Tue Jan 20 12:58:06 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14285 for ; Tue, 20 Jan 2004 12:58:06 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id C8171A0CBD; Tue, 20 Jan 2004 12:58:03 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id BBC8BA0D05 for ; Tue, 20 Jan 2004 12:57:39 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 3454615073; Tue, 20 Jan 2004 12:48:52 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 2711B152D5 for ; Tue, 20 Jan 2004 12:48:51 -0500 (EST) Received: (qmail 19568 invoked by uid 65534); 20 Jan 2004 17:48:49 -0000 Received: from p50824C7F.dip0.t-ipconnect.de (EHLO gmx.de) (80.130.76.127) by mail.gmx.net (mp008) with SMTP; 20 Jan 2004 18:48:49 +0100 X-Authenticated: #1915285 Message-ID: <400D6A00.1010806@gmx.de> Date: Tue, 20 Jan 2004 18:48:48 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault Cc: w3c-dist-auth@w3.org References: <015101c3df7b$65e4c9d0$1f01a8c0@lisalap> In-Reply-To: <015101c3df7b$65e4c9d0$1f01a8c0@lisalap> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Minor issue in RFC2518bis05, DAV:href X-Archived-At: http://www.w3.org/mid/400D6A00.1010806@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8278 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: <20040120175803.C8171A0CBD@frink.w3.org> Resent-Date: Tue, 20 Jan 2004 12:58:03 -0500 (EST) Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > Do you think that the ability to contain 'opaquelocktoken' URIs is > the sole exception, or is it generally OK for href to contain non-HTTP > URLs? I believe the latter would cause some problems among clients. Not generally. But there are other exceptions such as URIs that can appear in or . > And, is it always ok to have opaquelocktoken URIs in hrefs, or only > in certain circumstances? Only in certain cirumstances. So any element that re-uses DAV:href needs to state that if it isn't prepared to accept any URI (productions absoluteURI and relativeURI in RFC2396). Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Jan 20 15:12:36 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18486 for ; Tue, 20 Jan 2004 15:12:36 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id AA301A0C2B; Tue, 20 Jan 2004 15:12:35 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 33C93A0802 for ; Tue, 20 Jan 2004 15:12:34 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 3367313D28; Tue, 20 Jan 2004 15:12:34 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id A2F241358D for ; Tue, 20 Jan 2004 15:12:33 -0500 (EST) Received: (qmail 20623 invoked by uid 65534); 20 Jan 2004 20:12:26 -0000 Received: from p3EE2472A.dip.t-dialin.net (EHLO gmx.de) (62.226.71.42) by mail.gmx.net (mp026) with SMTP; 20 Jan 2004 21:12:26 +0100 X-Authenticated: #1915285 Message-ID: <400D8B86.6060107@gmx.de> Date: Tue, 20 Jan 2004 21:11:50 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Thompson Cc: w3c-dist-auth@w3.org References: <400D5401.70403@cocreate.com> In-Reply-To: <400D5401.70403@cocreate.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Client specified properties X-Archived-At: http://www.w3.org/mid/400D8B86.6060107@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8279 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: <20040120201235.AA301A0C2B@frink.w3.org> Resent-Date: Tue, 20 Jan 2004 15:12:35 -0500 (EST) Content-Transfer-Encoding: 7bit Jeff Thompson wrote: > > I've read through the WEBDAV spec and Lisa's book, but there is one area > that isn't quite clear to me. > > Is it expected that a WEBDAV server should accept arbitrary dead > properties that the client PROPPATCHs? Yes, according to the spec. > We've been watching the messages sent by Windows Explorer and we see > that it sends several Windows specific properties in a PROPPATCH. Our > system naturally has the required properties (or can leave them blank in > specific cases). However, we do not have any need for arbitrary client > specified properties. Does WEBDAV (clients, servers, or specifications) > expect that we do have this capability? Clients: some. In reality, there are of course servers that do not support dead properties, and clients have to cope with that in some way (just give up, or try to continue without dead properties). As long as the PROPPATCH request is rejected in a proper way (such as "Forbidden" or "Not Implemented"), this shouldn't be a big problem in practice. Of course it's *better* to support dead properties. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Jan 27 08:37:32 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04621 for ; Tue, 27 Jan 2004 08:37:32 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id C6A49A068F; Tue, 27 Jan 2004 08:37:31 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 8CDE8A068F for ; Tue, 27 Jan 2004 08:37:30 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id DD47B16964; Tue, 27 Jan 2004 05:11:03 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from nebula.lyra.org (us-1.i3.intermud.org [198.144.203.194]) by dr-nick.w3.org (Postfix) with ESMTP id 4764E19239 for ; Tue, 27 Jan 2004 04:57:16 -0500 (EST) Received: from localhost.localdomain (nebula.lyra.org [127.0.0.1]) by nebula.lyra.org (8.12.8/8.12.8) with ESMTP id i0RA3Rlj031185 for ; Tue, 27 Jan 2004 02:03:27 -0800 Date: Tue, 27 Jan 2004 02:03:27 -0800 Message-Id: <200401271003.i0RA3Rlj031185@nebula.lyra.org> From: gstein@lyra.org To: w3c-dist-auth@w3.org Subject: received your email X-Archived-At: http://www.w3.org/mid/200401271003.i0RA3Rlj031185@nebula.lyra.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8280 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: <20040127133731.C6A49A068F@frink.w3.org> Resent-Date: Tue, 27 Jan 2004 08:37:31 -0500 (EST) Hi, [ Re: Error ] I have received your email, but it may take a while to respond. I'm really sorry to have to hook up this auto-responder, as it is so impersonal. However, I get a lot of email every day and find it very difficult to keep up with it. Please be patient while I try to get to your message. Please feel free to resend your message if you think I've missed it. I'll always respond to personal email first. If your email is regarding some of the software that I work on (if you have questions, comments, suggestions, etc), then please resend it to the appropriate mailing list: mod_dav WebDAV ViewCVS Subversion edna Thank you! Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Jan 30 17:31:02 2004 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15365 for ; Fri, 30 Jan 2004 17:31:01 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 405BBA09EE; Fri, 30 Jan 2004 17:29:15 -0500 (EST) X-Original-To: w3c-dist-auth@listhub.w3.org Delivered-To: w3c-dist-auth@listhub.w3.org Received: from egp.w3.org (willie.w3.org [18.29.0.206]) by frink.w3.org (Postfix) with ESMTP id E8B2CA09EE for ; Fri, 30 Jan 2004 17:29:13 -0500 (EST) Received: by egp.w3.org (Postfix) id 3289288028E; Fri, 30 Jan 2004 17:28:31 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail3.gmhwh.org (unknown [198.31.239.197]) by egp.w3.org (Postfix) with ESMTP id C36B98802C5 for ; Fri, 30 Jan 2004 17:28:30 -0500 (EST) Received: from 192.168.8.246 by mail3.gmhwh.org with ESMTP ( (MMS v5.5.3)); Fri, 30 Jan 2004 15:30:40 -0600 Received: from WH-INET-MTA by wh-inet.gmhwh.org with Novell_GroupWise; Fri, 30 Jan 2004 15:28:06 -0700 Message-ID: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Fri, 30 Jan 2004 15:27:33 -0700 From: "Charlie Smith" To: w3c-dist-auth@w3.org MIME-Version: 1.0 X-WSS-ID: 6C04049A877884-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Preferred s/w platform for webdav implementation. X-Archived-At: http://www.w3.org/mid/s01a7806.008@wh-inet.gmhwh.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8281 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: <20040130222915.405BBA09EE@frink.w3.org> Resent-Date: Fri, 30 Jan 2004 17:29:15 -0500 (EST) Content-Transfer-Encoding: 7bit I'm looking at creating web site that can easily allow users to edit docs. What would be the most favorite freeware platform for deploying webdav? Php site? Perl Site? What are favorites. We'll need to have authentication and authorization features as well as a file management system. Forums and private chat rooms, etc. File management part should have version control, ability to lock files, with seemless access by word processing applications. I prefer Apache on an Intell box, but am open to otheroptions. Ditto for UNIX/Linux/RedHat.