From w3c-dist-auth-request@w3.org Mon Jul 2 01:25:18 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20269 for ; Mon, 2 Jul 2001 01:25:18 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA16460; Mon, 2 Jul 2001 01:23:38 -0400 (EDT) Resent-Date: Mon, 2 Jul 2001 01:23:38 -0400 (EDT) Resent-Message-Id: <200107020523.BAA16460@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id BAA16437 for ; Mon, 2 Jul 2001 01:23:32 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA08102 for ; Mon, 2 Jul 2001 01:23:33 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id BAA289150; Mon, 2 Jul 2001 01:21:09 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f625Gwb157886; Mon, 2 Jul 2001 01:16:58 -0400 Importance: Normal To: "Clemm, Geoff" Cc: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Mon, 2 Jul 2001 01:22:13 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at 07/02/2001 01:23:00 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5122 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: << So I think we should just say "A server SHOULD fail an attempt to lock an unmapped URL", and then remain silent on what a server might end up doing if it lets the lock of an unmapped URL succeed. In general, a MAY here is of little more use to the client than having the protocol remain discretely silent, and the benefit of using one of the several different flavors of lock-null behavior is unlikely to warrant writing special purpose code for each of those flavors. >> Geoff, After looking over the binding spec and how it relates to locking, I've changed my position to support what you've just said. I think it's important that we move forward and we are spending a lot of time on LNR despite the fact that many of us over the last few years have expressed a desire to remove them and as far as I know no one has taken a strong stand for them or their functionality. I suggest, as you have above, that we simply drop LNR's in a way that doesn't prevent us from adding them or something equivalent to the spec later if we decide there really is a need for them. Your suggestion above is the best one down this path that I've seen recently. I hope we all can quickly agree on it. J. From w3c-dist-auth-request@w3.org Mon Jul 2 10:11:01 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14975 for ; Mon, 2 Jul 2001 10:11:00 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA19853; Mon, 2 Jul 2001 10:08:16 -0400 (EDT) Resent-Date: Mon, 2 Jul 2001 10:08:16 -0400 (EDT) Resent-Message-Id: <200107021408.KAA19853@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA19833 for ; Mon, 2 Jul 2001 10:08:11 -0400 (EDT) Received: from aslan.computas.com ([193.71.42.32]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA17839 for ; Mon, 2 Jul 2001 10:08:10 -0400 To: w3c-dist-auth@w3.org References: <3906C56A7BD1F54593344C05BD1374B103770CAC@SUS-MA1IT01> From: Steinar Bang In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103770CAC@SUS-MA1IT01> ("Clemm, Geoff"'s message of "Fri, 29 Jun 2001 09:41:06 -0400") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 02 Jul 2001 16:07:58 +0200 Subject: Re: WebDAV and write access discovery Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5123 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: >>>>> "Clemm, Geoff" : > Probably the most general way to handle this is with the Expect > header ... that lets the server tell you that the request will fail > before you've sent the request body (an ACL violation is only one of > the reasons why the request might fail). Thanx for the tip. Quick reference for other uninitiated: Basically, if I've understood section 8.2.3 on how to handle the 100-continue response to an expect request (link at the end of the above section), the client should not send the body of the message until it sees a "100 continue" response to the server. So that would avoid me having to send the body over twice, in the case of authentication of a PUT request, which is great. One thing I would like to do, is to find out if a file is writable when I load it. Ie. I would like to do something like: - GET a file - immediately start a PUT of the file with the expect header in place - if I get a "100 continue" response, set the file to be R/W, otherwise mark it as read-only However, in this case the client has no intention of actually sending the body, even if the server returns a "100 continue", and I'm unsure of what happens if it doesn't? Will the 1.1 pipeline be blocked? Will a new request be taken to be an empty PUT body, and the file be overwritten with a file of 0 bytes? > The main problem with the Expect header is that it is an HTTP/1.1 > construct that is not understood by old HTTP/1.0 servers and > proxies. What's the risk with HTTP/1.0 servers in my case? That the PUT request with an expect header will be taken as an actual PUT request with an empty request body, and the file get 0 bytes? Is this a real risk? Are there any PUT enabled HTTP/1.0 servers out there? From w3c-dist-auth-request@w3.org Mon Jul 2 10:18:40 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19076 for ; Mon, 2 Jul 2001 10:18:39 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA20417; Mon, 2 Jul 2001 10:17:29 -0400 (EDT) Resent-Date: Mon, 2 Jul 2001 10:17:29 -0400 (EDT) Resent-Message-Id: <200107021417.KAA20417@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA20389 for ; Mon, 2 Jul 2001 10:17:22 -0400 (EDT) Received: from aslan.computas.com ([193.71.42.32]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA18918 for ; Mon, 2 Jul 2001 10:17:22 -0400 To: w3c-dist-auth@w3.org References: <3906C56A7BD1F54593344C05BD1374B103770CAC@SUS-MA1IT01> From: Steinar Bang In-Reply-To: (Steinar Bang's message of "Mon, 02 Jul 2001 16:07:58 +0200") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 02 Jul 2001 16:17:16 +0200 Subject: Re: WebDAV and write access discovery Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5124 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: >>>>> Steinar Bang : >>>>> "Clemm, Geoff" : >> Probably the most general way to handle this is with the Expect >> header ... that lets the server tell you that the request will fail >> before you've sent the request body (an ACL violation is only one >> of the reasons why the request might fail). > Thanx for the tip. Quick reference for other uninitiated: > > Basically, if I've understood section 8.2.3 on how to handle the > 100-continue response to an expect request (link at the end of the > above section), the client should not send the body of the message > until it sees a "100 continue" response to the server. > So that would avoid me having to send the body over twice, in the > case of authentication of a PUT request, which is great. I use libwww, so it looks like I may be using expect already: From the logs it looks like the body may be sent twice where authentication is required, but that may be caused by the 2 sec timeout being too short for slow servers. The question is then, can I do the thing below...? > One thing I would like to do, is to find out if a file is writable > when I load it. Ie. I would like to do something like: > - GET a file > - immediately start a PUT of the file with the expect header in place > - if I get a "100 continue" response, set the file to be R/W, > otherwise mark it as read-only From w3c-dist-auth-request@w3.org Mon Jul 2 10:40:42 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29377 for ; Mon, 2 Jul 2001 10:40:41 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA22596; Mon, 2 Jul 2001 10:36:15 -0400 (EDT) Resent-Date: Mon, 2 Jul 2001 10:36:15 -0400 (EDT) Resent-Message-Id: <200107021436.KAA22596@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA22576 for ; Mon, 2 Jul 2001 10:36:10 -0400 (EDT) Received: from c2bapps1.btconnect.com (c2bapps1.btconnect.com [193.113.209.21]) by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA20937 for ; Mon, 2 Jul 2001 10:36:10 -0400 Received: from light.plus.com (actually host host217-32-162-106.hg.mdip.bt.net) by c2bapps1 with SMTP (XT-PP) with ESMTP; Mon, 2 Jul 2001 15:35:37 +0100 Received: (from joe@localhost) by light.plus.com (8.11.0/8.9.0) id f62ETiR18109; Mon, 2 Jul 2001 15:29:44 +0100 X-Authentication-Warning: monolith.homenet: joe set sender to jorton@btconnect.com using -f Date: Mon, 2 Jul 2001 15:29:44 +0100 From: Joe Orton To: Steinar Bang Cc: w3c-dist-auth@w3.org Message-ID: <20010702152944.F17934@light.plus.com> Mail-Followup-To: Steinar Bang , w3c-dist-auth@w3.org References: <3906C56A7BD1F54593344C05BD1374B103770CAC@SUS-MA1IT01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from sb@metis.no on Mon, Jul 02, 2001 at 04:07:58PM +0200 Subject: Re: WebDAV and write access discovery Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5125 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: On Mon, Jul 02, 2001 at 04:07:58PM +0200, Steinar Bang wrote: ... > So that would avoid me having to send the body over twice, in the case > of authentication of a PUT request, which is great. > > One thing I would like to do, is to find out if a file is writable > when I load it. Ie. I would like to do something like: > - GET a file > - immediately start a PUT of the file with the expect header in place > - if I get a "100 continue" response, set the file to be R/W, > otherwise mark it as read-only > > However, in this case the client has no intention of actually sending > the body, even if the server returns a "100 continue", and I'm unsure > of what happens if it doesn't? Will the 1.1 pipeline be blocked? > Will a new request be taken to be an empty PUT body, and the file be > overwritten with a file of 0 bytes? The behaviour will be server-dependent I expect. (at least, since the RFC doesn't cover this case, you can't rely on any particular behaviour) > > The main problem with the Expect header is that it is an HTTP/1.1 > > construct that is not understood by old HTTP/1.0 servers and > > proxies. > > What's the risk with HTTP/1.0 servers in my case? That the PUT > request with an expect header will be taken as an actual PUT request > with an empty request body, and the file get 0 bytes? The problem is that HTTP/1.0 servers ignore the extension, so both client and server block waiting for the other. > Is this a real risk? Are there any PUT enabled HTTP/1.0 servers out > there? Proxy servers are the big problem - they are mostly HTTP/1.0 compliant. Regards, joe From w3c-dist-auth-request@w3.org Mon Jul 2 11:08:05 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19377 for ; Mon, 2 Jul 2001 11:08:04 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA24283; Mon, 2 Jul 2001 11:02:05 -0400 (EDT) Resent-Date: Mon, 2 Jul 2001 11:02:05 -0400 (EDT) Resent-Message-Id: <200107021502.LAA24283@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA24263 for ; Mon, 2 Jul 2001 11:02:01 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37015.rational.com [192.229.37.15]) by tux.w3.org (8.9.3/8.9.3) with SMTP id LAA23938 for ; Mon, 2 Jul 2001 11:02:02 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Mon, 02 Jul 2001 11:08:22 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Jul 2001 11:08:22 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E2502@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Mon, 2 Jul 2001 11:08:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: WebDAV and write access discovery Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5126 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: You are not allowed to send a Expect request header if you do not intend to send a request body (Section 8.2.3): A client MUST NOT send an Expect request-header field (section 14.20) with the "100-continue" expectation if it does not intend to send a request body. An early terminated PUT request (i.e. without a message body) should be treated by the server as a failure by the client, and not as a 0-length content update. But the overhead of having the client prematurely terminate a connection (to get the PUT to fail) or wait for the server to timeout the connection, would make it unadvisable to use this as a techique for finding out whether the resource is readonly. When the ACL protocol is implemented, that would be the best way to determine whether a resource is readonly. If it is a Class 2 DAV server, trying to get a write lock might be something to try, but I don't know whether or not servers tend to fail requests to get write-locks on read-only resources. Cheers, Geoff -----Original Message----- From: Steinar Bang [mailto:sb@metis.no] Sent: Monday, July 02, 2001 10:08 AM To: w3c-dist-auth@w3.org Subject: Re: WebDAV and write access discovery >>>>> "Clemm, Geoff" : > Probably the most general way to handle this is with the Expect > header ... that lets the server tell you that the request will fail > before you've sent the request body (an ACL violation is only one of > the reasons why the request might fail). Thanx for the tip. Quick reference for other uninitiated: Basically, if I've understood section 8.2.3 on how to handle the 100-continue response to an expect request (link at the end of the above section), the client should not send the body of the message until it sees a "100 continue" response to the server. So that would avoid me having to send the body over twice, in the case of authentication of a PUT request, which is great. One thing I would like to do, is to find out if a file is writable when I load it. Ie. I would like to do something like: - GET a file - immediately start a PUT of the file with the expect header in place - if I get a "100 continue" response, set the file to be R/W, otherwise mark it as read-only However, in this case the client has no intention of actually sending the body, even if the server returns a "100 continue", and I'm unsure of what happens if it doesn't? Will the 1.1 pipeline be blocked? Will a new request be taken to be an empty PUT body, and the file be overwritten with a file of 0 bytes? > The main problem with the Expect header is that it is an HTTP/1.1 > construct that is not understood by old HTTP/1.0 servers and > proxies. What's the risk with HTTP/1.0 servers in my case? That the PUT request with an expect header will be taken as an actual PUT request with an empty request body, and the file get 0 bytes? Is this a real risk? Are there any PUT enabled HTTP/1.0 servers out there? From w3c-dist-auth-request@w3.org Mon Jul 2 13:43:38 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02230 for ; Mon, 2 Jul 2001 13:43:37 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA11927; Mon, 2 Jul 2001 13:42:47 -0400 (EDT) Resent-Date: Mon, 2 Jul 2001 13:42:47 -0400 (EDT) Resent-Message-Id: <200107021742.NAA11927@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA11905 for ; Mon, 2 Jul 2001 13:42:43 -0400 (EDT) Received: from hermes.eurgw.xerox.com (root@hermes.ext.eurgw.xerox.com [212.120.143.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA10883 for ; Mon, 2 Jul 2001 13:42:42 -0400 Received: from eurodns2.eur.xerox.com (eurodns2.eur.xerox.com [13.202.66.10]) by hermes.eurgw.xerox.com (8.9.3/8.9.3) with ESMTP id SAA27338 for ; Mon, 2 Jul 2001 18:42:40 +0100 (BST) Received: from eur.xerox.com (eurdubmg02.eur.xerox.com [13.202.65.254]) by eurodns2.eur.xerox.com (8.9.3/8.9.3) with ESMTP id SAA24951 for ; Mon, 2 Jul 2001 18:40:07 +0100 (BST) Received: from eurgbrbh02.emeacinops.xerox.com (unverified) by eur.xerox.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 2 Jul 2001 18:20:37 +0100 Received: by eurgbrbh02.eur.xerox.com with Internet Mail Service (5.5.2651.58) id <2WZBDKW9>; Mon, 2 Jul 2001 18:21:03 +0100 Received: from eur.xerox.com (eurdubmg02.eur.xerox.com [13.202.65.254]) by eurgbrbh02.emeacinops.xerox.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id 2WZBDKWX; Mon, 2 Jul 2001 18:20:54 +0100 Received: from gbrwgcbh01.wgc.gbr.xerox.com (unverified) by eur.xerox.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 2 Jul 2001 18:09:38 +0100 Received: by gbrwgcbh01.wgc.gbr.xerox.com with Internet Mail Service (5.5.2650.21) id ; Mon, 2 Jul 2001 16:31:32 +0100 Message-ID: <59697CCC6CE3D411B4CD00805FBB77672875D5@gbrwgcms03.wgc.gbr.xerox.com> From: "Hall, Shaun" To: "'Steinar Bang'" , w3c-dist-auth@w3.org Date: Mon, 2 Jul 2001 16:31:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WebDAV and write access discovery Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5127 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: All IMHO. Bits snipped. > -----Original Message----- > From: Steinar Bang [mailto:sb@metis.no] > Sent: 02 July 2001 15:08 > To: w3c-dist-auth@w3.org > Subject: Re: WebDAV and write access discovery > > One thing I would like to do, is to find out if a file is writable > when I load it. Ie. I would like to do something like: > - GET a file > - immediately start a PUT of the file with the expect header in place > - if I get a "100 continue" response, set the file to be R/W, > otherwise mark it as read-only > > However, in this case the client has no intention of actually sending > the body, even if the server returns a "100 continue", and I'm unsure > of what happens if it doesn't? Will the 1.1 pipeline be blocked? > Will a new request be taken to be an empty PUT body, and the file be > overwritten with a file of 0 bytes? You really shouldn't do this. RFC2616 Sec 8.2.3 states "a client MUST NOT send an Expect header .... if it does not intend to send a request body". You will have to check, but some servers might assume any data arriving on "the socket connection" after it has sent the response for the Expect header *is* the body. In the case of PUT, it might store the data (which could actually be your new request) in the file as specified by the PUT request. Regards Shaun Hall Xerox Europe From w3c-dist-auth-request@w3.org Wed Jul 4 05:14:40 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA03045 for ; Wed, 4 Jul 2001 05:14:39 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA08543; Wed, 4 Jul 2001 05:11:04 -0400 (EDT) Resent-Date: Wed, 4 Jul 2001 05:11:04 -0400 (EDT) Resent-Message-Id: <200107040911.FAA08543@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA08520 for ; Wed, 4 Jul 2001 05:10:56 -0400 (EDT) Received: from io.mds.rmit.edu.au (io.mds.rmit.edu.au [131.170.70.10]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA28920 for ; Wed, 4 Jul 2001 05:10:55 -0400 Received: by io.mds.rmit.edu.au (Postfix, from userid 301) id 8B97A49B49; Wed, 4 Jul 2001 19:10:18 +1000 (EST) Date: Wed, 4 Jul 2001 19:10:18 +1000 From: Alan Kent To: WebDAV Message-ID: <20010704191018.A11885@io.mds.rmit.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i Subject: ACL proposal comments Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5128 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: Not being bamboozeled enough by DeltaV, I thought I would read the ACL spec reported recently. The good news (to me), is it made sense and seemed quite clear etc. Otherwise I am so far gone I cannot tell the difference! ;^) One comment - it says that XML namespace semantics are the same as those of WebDAV. Talking to people locally seems to indicate that the WebDAV interpretation of XML namespaces is not conformant to the XML namespace recommendation. Should ACL base the namespace interpretation on WebDAV, or on the XML namespaces specification? The ACL spec explicitly references the WebDAV RFC by number, so if a new WebDAV spec came along supporting the "official" XML namespace interpretation, then the spec would be out of date already. (Not a big deal - and probably no solution.) The difference is WebDAV says you concatenate the namespace URI to the element name to form a single string. What I have been told of the official XML namespace recommendation is that the two values must be kept separate during comparisons. It is not valid to concatenate them. One syntax that has been used to help represent this is {DAV:}owner to represent the element 'owner' in the 'DAV:' namespace. Other minor points - some places use principle URLs of /_acl/users/foo and others use /users/foo. Both are probably correct. I am wondering if it might avoid confusion if the same format is used throughout the document. I saw it and wondered if they were the same sort of URL or something different. 5.6.1 had a *very* minor typo (/_acl/users and /_acl_groups). The last '_' should be a slash. (Ok, just prooving I read it all 8-) General comment - its seems reasonably complex. This may be necessary, but there is a fair bit to implement. Some more motivation may be nice. For example, I was not sure why inheritance was useful. Also the description of principles and collection principles was pretty confusing until the example called some of the collection principles GRPA and GRPB. Some more examples of how it may be used helps clear things up. Yes, and I noticed the slightly contraversial inclusion of something else in other than just . Alan From w3c-dist-auth-request@w3.org Wed Jul 4 05:24:17 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA03151 for ; Wed, 4 Jul 2001 05:24:16 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA08832; Wed, 4 Jul 2001 05:19:28 -0400 (EDT) Resent-Date: Wed, 4 Jul 2001 05:19:28 -0400 (EDT) Resent-Message-Id: <200107040919.FAA08832@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA08812 for ; Wed, 4 Jul 2001 05:19:20 -0400 (EDT) Received: from io.mds.rmit.edu.au (io.mds.rmit.edu.au [131.170.70.10]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA29525 for ; Wed, 4 Jul 2001 05:19:20 -0400 Received: by io.mds.rmit.edu.au (Postfix, from userid 301) id 48CC049B49; Wed, 4 Jul 2001 19:18:44 +1000 (EST) Date: Wed, 4 Jul 2001 19:18:44 +1000 From: Alan Kent To: WebDAV Message-ID: <20010704191844.B11885@io.mds.rmit.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i Subject: MSIE question related to WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5129 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: This is not really a WebDAV question, but more of a question of integrating WebDAV nicely with Web browsers (such as MSIE). I think the answer is no, but is there any way to tell Microsoft Internet Explorer (or Netscape for that matter I guess) that a URL in a or similar is in a DAV folder, so it should use the application to natively load the document. For example, if I have a Word document in a DAV web folder, and I have a web page with a pointing to the document, then if the user clicks on the link, IE will download the file, put it into a temporary directory, then start up Word on the downloaded file. So Word does not talk to the WebDAV repository. I would rather give Word the URL and say 'hey, you load it yourself'. That way Word can save the changes directly back to the Web DAV folder. My best solution so far is to put on the web page a URL to a document that contains the URL of the DAV resource to be edited, give the first URL a file extension of .xyz, get the user to associate a small program to the .xyz file extension which starts up Word with the second URL on the command line. Any other brilliant ways of doing this without having to reconfigure the user's web browser first? Thanks. Alan From w3c-dist-auth-request@w3.org Wed Jul 4 05:42:44 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA03287 for ; Wed, 4 Jul 2001 05:42:43 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA09701; Wed, 4 Jul 2001 05:37:39 -0400 (EDT) Resent-Date: Wed, 4 Jul 2001 05:37:39 -0400 (EDT) Resent-Message-Id: <200107040937.FAA09701@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA09671 for ; Wed, 4 Jul 2001 05:37:30 -0400 (EDT) Received: from d06lmsgate.uk.ibm.COM (d06lmsgate.uk.ibm.com [195.212.29.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA30830 for ; Wed, 4 Jul 2001 05:37:29 -0400 Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147]) by d06lmsgate.uk.ibm.COM (1.0.0) with ESMTP id KAA132194 for ; Wed, 4 Jul 2001 10:18:28 +0100 Received: from d06ml034.portsmouth.uk.ibm.com (d06ml034_cs0 [9.180.35.31]) by d06relay01.portsmouth.uk.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f649agE85120 for ; Wed, 4 Jul 2001 10:36:43 +0100 To: WebDAV X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Tim Ellison" Date: Wed, 4 Jul 2001 10:36:34 +0100 X-MIMETrack: Serialize by Router on D06ML034/06/M/IBM(Release 5.0.6 |December 14, 2000) at 04/07/2001 10:35:38 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: MSIE question related to WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5130 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: Alan Kent wrote: > This is not really a WebDAV question, but more of a > question of integrating WebDAV nicely with Web > browsers (such as MSIE). > > I think the answer is no, but is there any way to tell > Microsoft Internet Explorer (or Netscape for that > matter I guess) that a URL in a or > similar is in a DAV folder, so it should use the > application to natively load the document. > > For example, if I have a Word document in a DAV web > folder, and I have a web page with a > pointing to the document, then if the user clicks on > the link, IE will download the file, put it into a > temporary directory, then start up Word on the > downloaded file. So Word does not talk to the WebDAV > repository. I would rather give Word the URL and say > 'hey, you load it yourself'. That way Word can save > the changes directly back to the Web DAV folder. > > My best solution so far is to put on the web page a > URL to a document that contains the URL of the DAV > resource to be edited, give the first URL a file > extension of .xyz, get the user to associate a small > program to the .xyz file extension which starts up > Word with the second URL on the command line. > > Any other brilliant ways of doing this without having > to reconfigure the user's web browser first? For an IE-specific solution you can use the FOLDER attribute of an href. The description is given here http://msdn.microsoft.com/library/default.asp?url=/workshop/author/behaviors/overview/WebFolder.asp As far as I am aware there is no equivalent in Netscape. Regards, Tim Ellison Java Technology Centre, MP146 IBM UK Laboratory, Hursley Park, Winchester, UK. SO21 2JN tel: +44 (0)1962 819872 internal: 249872 MOBx: 270452 From w3c-dist-auth-request@w3.org Wed Jul 4 05:43:12 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA03298 for ; Wed, 4 Jul 2001 05:43:11 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA09772; Wed, 4 Jul 2001 05:41:08 -0400 (EDT) Resent-Date: Wed, 4 Jul 2001 05:41:08 -0400 (EDT) Resent-Message-Id: <200107040941.FAA09772@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA09748 for ; Wed, 4 Jul 2001 05:41:00 -0400 (EDT) Received: from d06lmsgate-3.uk.ibm.com (d06lmsgate-3.uk.ibm.com [195.212.29.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA31032 for ; Wed, 4 Jul 2001 05:40:59 -0400 Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147]) by d06lmsgate-3.uk.ibm.com (1.0.0) with ESMTP id KAA97994 for ; Wed, 4 Jul 2001 10:31:20 +0100 Received: from d06ml034.portsmouth.uk.ibm.com (d06ml034_cs0 [9.180.35.31]) by d06relay01.portsmouth.uk.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f649eIE116584 for ; Wed, 4 Jul 2001 10:40:19 +0100 To: WebDAV X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Tim Ellison" Date: Wed, 4 Jul 2001 10:40:54 +0100 X-MIMETrack: Serialize by Router on D06ML034/06/M/IBM(Release 5.0.6 |December 14, 2000) at 04/07/2001 10:39:16 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: ACL proposal comments Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5131 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: Alan Kent wrote: > One comment - it says that XML namespace semantics are the > same as those of WebDAV. Talking to people locally seems > to indicate that the WebDAV interpretation of XML namespaces > is not conformant to the XML namespace recommendation. Should > ACL base the namespace interpretation on WebDAV, or on the > XML namespaces specification? The ACL spec explicitly references > the WebDAV RFC by number, so if a new WebDAV spec came along > supporting the "official" XML namespace interpretation, then > the spec would be out of date already. (Not a big deal - and > probably no solution.) RFC2518 has to be read in conjunction with the issues list cum addendum which is at http://www.ics.uci.edu/pub/ietf/webdav/protocol/issues.html (in particular see XML_NS) Regards, Tim From w3c-dist-auth-request@w3.org Thu Jul 5 00:06:45 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA17493 for ; Thu, 5 Jul 2001 00:06:44 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA01064; Thu, 5 Jul 2001 00:02:43 -0400 (EDT) Resent-Date: Thu, 5 Jul 2001 00:02:43 -0400 (EDT) Resent-Message-Id: <200107050402.AAA01064@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id AAA01041 for ; Thu, 5 Jul 2001 00:02:33 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37015.rational.com [192.229.37.15]) by tux.w3.org (8.9.3/8.9.3) with SMTP id AAA20111 for ; Thu, 5 Jul 2001 00:02:33 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Thu, 05 Jul 2001 00:08:55 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Jul 2001 00:08:55 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1038E1474@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV Date: Thu, 5 Jul 2001 00:09:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: ACL proposal comments Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5132 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: A while back, I added the following text to the "Notational Conventions" section of the versioning protocol: When an XML element type in the "DAV:" namespace is referenced in this document outside of the context of an XML fragment, the string "DAV:" will be prefixed to the element type. We probably should add this to the ACL document as well, to avoid concerns of this kind. Cheers, Geoff -----Original Message----- From: Alan Kent [mailto:ajk@mds.rmit.edu.au] Sent: Wednesday, July 04, 2001 5:10 AM To: WebDAV Subject: ACL proposal comments Not being bamboozeled enough by DeltaV, I thought I would read the ACL spec reported recently. The good news (to me), is it made sense and seemed quite clear etc. Otherwise I am so far gone I cannot tell the difference! ;^) One comment - it says that XML namespace semantics are the same as those of WebDAV. Talking to people locally seems to indicate that the WebDAV interpretation of XML namespaces is not conformant to the XML namespace recommendation. Should ACL base the namespace interpretation on WebDAV, or on the XML namespaces specification? The ACL spec explicitly references the WebDAV RFC by number, so if a new WebDAV spec came along supporting the "official" XML namespace interpretation, then the spec would be out of date already. (Not a big deal - and probably no solution.) The difference is WebDAV says you concatenate the namespace URI to the element name to form a single string. What I have been told of the official XML namespace recommendation is that the two values must be kept separate during comparisons. It is not valid to concatenate them. One syntax that has been used to help represent this is {DAV:}owner to represent the element 'owner' in the 'DAV:' namespace. Other minor points - some places use principle URLs of /_acl/users/foo and others use /users/foo. Both are probably correct. I am wondering if it might avoid confusion if the same format is used throughout the document. I saw it and wondered if they were the same sort of URL or something different. 5.6.1 had a *very* minor typo (/_acl/users and /_acl_groups). The last '_' should be a slash. (Ok, just prooving I read it all 8-) General comment - its seems reasonably complex. This may be necessary, but there is a fair bit to implement. Some more motivation may be nice. For example, I was not sure why inheritance was useful. Also the description of principles and collection principles was pretty confusing until the example called some of the collection principles GRPA and GRPB. Some more examples of how it may be used helps clear things up. Yes, and I noticed the slightly contraversial inclusion of something else in other than just . Alan From w3c-dist-auth-request@w3.org Thu Jul 5 02:16:31 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA00141 for ; Thu, 5 Jul 2001 02:16:31 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA05285; Thu, 5 Jul 2001 02:16:02 -0400 (EDT) Resent-Date: Thu, 5 Jul 2001 02:16:02 -0400 (EDT) Resent-Message-Id: <200107050616.CAA05285@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id CAA05265 for ; Thu, 5 Jul 2001 02:15:51 -0400 (EDT) Received: from io.mds.rmit.edu.au (io.mds.rmit.edu.au [131.170.70.10]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id CAA29012 for ; Thu, 5 Jul 2001 02:15:50 -0400 Received: by io.mds.rmit.edu.au (Postfix, from userid 301) id 40C7349B49; Thu, 5 Jul 2001 16:15:19 +1000 (EST) Date: Thu, 5 Jul 2001 16:15:18 +1000 From: Alan Kent To: Tim Ellison Cc: WebDAV Message-ID: <20010705161518.E23551@io.mds.rmit.edu.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: ; from Tim Ellison on Wed, Jul 04, 2001 at 10:36:34AM +0100 Subject: Re: MSIE question related to WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5133 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: > For an IE-specific solution you can use the FOLDER attribute of an href. > > The description is given here > http://msdn.microsoft.com/library/default.asp?url=/workshop/author/behaviors/overview/WebFolder.asp Thanks for the link. From my reading of this, it seems I can get IE to open up a folder. Can I get it to immediately launch Word on a particular document? Or do I have to open the folder then ask the user to double-click on the correct document in the folder? In case others are listening, I used the following HTML My Slides Clinking on 'My Slides' in IE5 brought up the directory (inside IE) with the file in it. Double clicking on the file in the web folder caused Power Point to load the document via WebDAV, then save the changes back when I was finished. Quite nice really, but not the user had to click on the particular file in the folder - I cannot get it to start power point directly on the myslides.ppt file from a web page. Note: I tried changing the FOLDER="..." to ../foo/myslides.ppt and IE just ignored the file name on the end (dropped it). I then tried .../foo/myslides.ppt/ (OK, I am a hacker at heart). IE said "Not enough memory to complete your operation." Alan From w3c-dist-auth-request@w3.org Thu Jul 5 02:31:31 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA01251 for ; Thu, 5 Jul 2001 02:31:30 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA05936; Thu, 5 Jul 2001 02:31:22 -0400 (EDT) Resent-Date: Thu, 5 Jul 2001 02:31:22 -0400 (EDT) Resent-Message-Id: <200107050631.CAA05936@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id CAA05913 for ; Thu, 5 Jul 2001 02:31:12 -0400 (EDT) Received: from viffer.computas.no (c96s55h3.upc.chello.no [213.46.211.96]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id CAA30185 for ; Thu, 5 Jul 2001 02:31:10 -0400 Received: (from sb@localhost) by viffer.computas.no (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id IAA01663; Thu, 5 Jul 2001 08:31:09 +0200 To: w3c-dist-auth@w3.org References: <3906C56A7BD1F54593344C05BD1374B1018E2502@SUS-MA1IT01> From: Steinar Bang In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1018E2502@SUS-MA1IT01> ("Clemm, Geoff"'s message of "Mon, 2 Jul 2001 11:08:28 -0400") Message-ID: User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 05 Jul 2001 08:31:04 +0200 Lines: 46 Subject: Re: WebDAV and write access discovery Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5134 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: >>>>> "Clemm, Geoff" : > You are not allowed to send a Expect request header if you do not > intend to send a request body (Section 8.2.3): > A client MUST NOT send an Expect request-header field (section > 14.20) with the "100-continue" expectation if it does not intend > to send a request body. Yes, I missed that. Thanx for the clarification. > An early terminated PUT request (i.e. without a message body) should > be treated by the server as a failure by the client, and not as a > 0-length content update. But the overhead of having the client > prematurely terminate a connection (to get the PUT to fail) or wait > for the server to timeout the connection, would make it unadvisable > to use this as a techique for finding out whether the resource is > readonly. I agree. > When the ACL protocol is implemented, that would be the best way to > determine whether a resource is readonly. If it is a Class 2 DAV > server, trying to get a write lock might be something to try, That was my next idea, also. After I have done a GET, immediately start a LOCK on the same resource, and then either UNLOCK the lock (to try to grab it again, if I ever wish to attempt a PUT), or let it time out (and refresh it before a PUT). Yet another approach would be to do a PROPFIND on the resource, to see if it has any locks. Or aren't lock tokens listed as properties? (One tricky bit here would be to map from the HREF to the authenticated user, but presumably I would know what URL I set myself.) I wonder what eg. Word 2000 does? Does it mark everything as R/W, and just PUT, and then report a failure? > but I don't know whether or not servers tend to fail requests to get > write-locks on read-only resources. I thought 8.10.7 of RFC 2518 would require them to return a 412 in this case (ie. "lock token not enforcable on this resource")...? From w3c-dist-auth-request@w3.org Thu Jul 5 02:45:25 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02385 for ; Thu, 5 Jul 2001 02:45:25 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA06487; Thu, 5 Jul 2001 02:44:50 -0400 (EDT) Resent-Date: Thu, 5 Jul 2001 02:44:50 -0400 (EDT) Resent-Message-Id: <200107050644.CAA06487@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id CAA06467 for ; Thu, 5 Jul 2001 02:44:42 -0400 (EDT) Received: from viffer.computas.no (c96s55h3.upc.chello.no [213.46.211.96]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id CAA30974 for ; Thu, 5 Jul 2001 02:44:41 -0400 Received: (from sb@localhost) by viffer.computas.no (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id IAA01755; Thu, 5 Jul 2001 08:44:40 +0200 To: w3c-dist-auth@w3.org References: <3906C56A7BD1F54593344C05BD1374B1018E2502@SUS-MA1IT01> From: Steinar Bang In-Reply-To: (Steinar Bang's message of "Thu, 05 Jul 2001 08:31:04 +0200") Message-ID: User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 05 Jul 2001 08:44:35 +0200 Lines: 28 Subject: Re: WebDAV and write access discovery Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5135 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: >>>>> Steinar Bang : >>>>> "Clemm, Geoff" : >> When the ACL protocol is implemented, that would be the best way to >> determine whether a resource is readonly. If it is a Class 2 DAV >> server, trying to get a write lock might be something to try, > That was my next idea, also. > After I have done a GET, immediately start a LOCK on the same > resource, and then either UNLOCK the lock (to try to grab it again, if > I ever wish to attempt a PUT), or let it time out (and refresh it > before a PUT). > Yet another approach would be to do a PROPFIND on the resource, to see > if it has any locks. Or aren't lock tokens listed as properties? > (One tricky bit here would be to map from the HREF to the authenticated > user, but presumably I would know what URL I set myself.) > I wonder what eg. Word 2000 does? Does it mark everything as R/W, and > just PUT, and then report a failure? This link would seem to indicate that a WebFolder Visual Basic(?) object can return the isWritable status of a WebFolder (which is a DAV collection...?). So the question is then: how does it discover the isWritable status. From w3c-dist-auth-request@w3.org Thu Jul 5 02:48:06 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02617 for ; Thu, 5 Jul 2001 02:48:06 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA06579; Thu, 5 Jul 2001 02:47:30 -0400 (EDT) Resent-Date: Thu, 5 Jul 2001 02:47:30 -0400 (EDT) Resent-Message-Id: <200107050647.CAA06579@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id CAA06555 for ; Thu, 5 Jul 2001 02:47:21 -0400 (EDT) Received: from viffer.computas.no (c96s55h3.upc.chello.no [213.46.211.96]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id CAA31148 for ; Thu, 5 Jul 2001 02:47:20 -0400 Received: (from sb@localhost) by viffer.computas.no (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id IAA01782; Thu, 5 Jul 2001 08:47:19 +0200 To: w3c-dist-auth@w3.org References: <3906C56A7BD1F54593344C05BD1374B1018E2502@SUS-MA1IT01> From: Steinar Bang In-Reply-To: (Steinar Bang's message of "Thu, 05 Jul 2001 08:44:35 +0200") Message-ID: User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 05 Jul 2001 08:47:14 +0200 Lines: 16 Subject: Re: WebDAV and write access discovery Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5136 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: >>>>> Steinar Bang : >>>>> Steinar Bang : >> I wonder what eg. Word 2000 does? Does it mark everything as R/W, and >> just PUT, and then report a failure? > This link would seem to indicate that a WebFolder Visual Basic(?) > object can return the isWritable status of a WebFolder (which is a > DAV collection...?). Forgot to add the link. Here it is: > So the question is then: how does it discover the isWritable status. From w3c-dist-auth-request@w3.org Thu Jul 5 05:58:38 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05821 for ; Thu, 5 Jul 2001 05:58:37 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA12872; Thu, 5 Jul 2001 05:54:35 -0400 (EDT) Resent-Date: Thu, 5 Jul 2001 05:54:35 -0400 (EDT) Resent-Message-Id: <200107050954.FAA12872@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA12827 for ; Thu, 5 Jul 2001 05:54:28 -0400 (EDT) Received: from d06lmsgate-2.uk.ibm.com (d06lmsgate-2.uk.ibm.com [195.212.29.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA12591 for ; Thu, 5 Jul 2001 05:54:24 -0400 Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147]) by d06lmsgate-2.uk.ibm.com (1.0.0) with ESMTP id KAA82820 for ; Thu, 5 Jul 2001 10:37:31 +0100 Received: from d06ml034.portsmouth.uk.ibm.com (d06ml034_cs0 [9.180.35.31]) by d06relay01.portsmouth.uk.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f659roC168126 for ; Thu, 5 Jul 2001 10:53:50 +0100 To: WebDAV X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Tim Ellison" Date: Thu, 5 Jul 2001 10:54:27 +0100 X-MIMETrack: Serialize by Router on D06ML034/06/M/IBM(Release 5.0.6 |December 14, 2000) at 05/07/2001 10:52:44 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: MSIE question related to WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5137 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: Alan Kent > > For an IE-specific solution you can use the FOLDER > > attribute of an href. > > > > The description is given here > > http://msdn.microsoft.com/library/default.asp?url=/workshop/author/behaviors/overview/WebFolder.asp > > Thanks for the link. From my reading of this, it seems I > can get IE to open up a folder. Yes. > Can I get it to immediately launch Word on a > particular document? Yes, see http://support.microsoft.com/support/kb/articles/Q178/2/22.asp > Or do I have to open the folder then ask the > user to double-click on the correct document in the folder? > > In case others are listening, I used the following HTML > > HREF="http://localhost:4444/foo/myslides.ppt" > FOLDER="http://localhost:4444/foo/" > TARGET="_top"> > My Slides > > > Clinking on 'My Slides' in IE5 brought up the directory > (inside IE) with the file in it. Double clicking on the > file in the web folder caused Power Point to load the > document via WebDAV, then save the changes back when I > was finished. Quite nice really, but not the user had > to click on the particular file in the folder - I cannot > get it to start power point directly on the myslides.ppt > file from a web page. The above link should do it. Note that the webfolders interaction is between the PowerPoint and the server (not IE). I had misinterpreted your intent. > Note: I tried changing the FOLDER="..." to ../foo/myslides.ppt > and IE just ignored the file name on the end (dropped it). > I then tried .../foo/myslides.ppt/ (OK, I am a hacker at heart). IE should just launch PowerPoint and pass it the .ppt URL. > IE said "Not enough memory to complete your operation." ??strange (ok that's enough of answering questions on Microsoft products :-) Regards, Tim Ellison Java Technology Centre, MP146 IBM UK Laboratory, Hursley Park, Winchester, UK. SO21 2JN tel: +44 (0)1962 819872 internal: 249872 MOBx: 270452 From w3c-dist-auth-request@w3.org Thu Jul 5 09:26:56 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11664 for ; Thu, 5 Jul 2001 09:26:55 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA22315; Thu, 5 Jul 2001 09:24:24 -0400 (EDT) Resent-Date: Thu, 5 Jul 2001 09:24:24 -0400 (EDT) Resent-Message-Id: <200107051324.JAA22315@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA22291 for ; Thu, 5 Jul 2001 09:24:16 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37015.rational.com [192.229.37.15]) by tux.w3.org (8.9.3/8.9.3) with SMTP id JAA30847 for ; Thu, 5 Jul 2001 09:24:16 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Thu, 05 Jul 2001 09:30:52 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Jul 2001 09:30:52 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1038E14BD@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Thu, 5 Jul 2001 09:30:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: WebDAV and write access discovery Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5138 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: From: Steinar Bang [mailto:sb@metis.no] > but I don't know whether or not servers tend to fail requests to get > write-locks on read-only resources. I thought 8.10.7 of RFC 2518 would require them to return a 412 in this case (ie. "lock token not enforcable on this resource")...? A write lock does not guarantee the lock-token-holder the ability to write to a resource ... it just denies non-lock-token-holders that ability. So a server would be enforcing the lock, even if there are reasons (such as ACLs) that prevent the lock-holder from writing to the resource. Cheers, Geoff From w3c-dist-auth-request@w3.org Thu Jul 5 19:07:29 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29534 for ; Thu, 5 Jul 2001 19:07:29 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA01992; Thu, 5 Jul 2001 18:59:52 -0400 (EDT) Resent-Date: Thu, 5 Jul 2001 18:59:52 -0400 (EDT) Resent-Message-Id: <200107052259.SAA01992@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA01972 for ; Thu, 5 Jul 2001 18:59:49 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA27934 for ; Thu, 5 Jul 2001 18:59:49 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id PAA17502 for ; Thu, 5 Jul 2001 15:59:53 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Thu, 5 Jul 2001 15:57:21 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: London IETF meeting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5139 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: Content-Transfer-Encoding: 7bit The WebDAV Working Group will be meeting at the 51st IETF meeting in London, England, August 5-10, 2001. Information on the IETF meeting, including hotels and registration information, can be found at: http://www.ietf.org/meetings/IETF-51.html The draft agenda for the meeting has the WebDAV WG meeting scheduled for Monday, August 6, from 15:30 to 17:30, and the DeltaV meeting on Wednesday, August 8, from 13:00 to 15:00. Note that these times are subject to change (this happened last meeting). Lisa Dusseault has graciously agreed to Chair the WebDAV meeting, since I will be unable to attend this IETF. - Jim From w3c-dist-auth-request@w3.org Fri Jul 6 13:13:45 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13051 for ; Fri, 6 Jul 2001 13:13:44 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA17476; Fri, 6 Jul 2001 13:11:58 -0400 (EDT) Resent-Date: Fri, 6 Jul 2001 13:11:58 -0400 (EDT) Resent-Message-Id: <200107061711.NAA17476@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA17456 for ; Fri, 6 Jul 2001 13:11:54 -0400 (EDT) Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA29767 for ; Fri, 6 Jul 2001 13:11:54 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA14282 for ; Fri, 6 Jul 2001 13:03:56 -0400 Received: from f3n44e (d03nm044h.boulder.ibm.com [9.99.140.44]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.96.1.0) with ESMTP id f66HBqF94666 for ; Fri, 6 Jul 2001 11:11:52 -0600 To: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Tao Wan" Date: Fri, 6 Jul 2001 10:11:41 -0700 X-MIMETrack: Serialize by Router on D03NM044/03/M/IBM(Release 5.0.6 |December 14, 2000) at 07/06/2001 11:11:52 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: webdav compliant resouce Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5140 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: Hi, according to RFC2518, it said a webdav compliant collection may hold not webdav compliant resource. if so, when I use propfind with and depth = 1 header to request properties, webdav should make response for all properties of its immediate members or just for all properties of its immediate members which is webdav compliant. how to identify a webdav compliant resource or not. Thanks Tao Wan DBTI Content Management IBM Silicon Valley Labs, San Jose, CA Phone: 408 463 2256 Internet email: want@us.ibm.com From w3c-dist-auth-request@w3.org Fri Jul 6 13:43:37 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14075 for ; Fri, 6 Jul 2001 13:43:37 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA19339; Fri, 6 Jul 2001 13:42:57 -0400 (EDT) Resent-Date: Fri, 6 Jul 2001 13:42:57 -0400 (EDT) Resent-Message-Id: <200107061742.NAA19339@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA19302 for ; Fri, 6 Jul 2001 13:42:50 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37015.rational.com [192.229.37.15]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA32685 for ; Fri, 6 Jul 2001 13:42:49 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Fri, 06 Jul 2001 13:49:17 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Jul 2001 13:49:17 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E2520@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Fri, 6 Jul 2001 13:49:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: webdav compliant resouce Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5141 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: Section 5.2 states that it is server-defined whether or not a collection lists non-compliant resources as internal members. You can identify that a resource is webDAV compliant if it returns a "1" as a value in the DAV header returned from an OPTIONS request. Cheers, Geoff -----Original Message----- From: Tao Wan [mailto:want@us.ibm.com] Sent: Friday, July 06, 2001 1:12 PM To: w3c-dist-auth@w3.org Subject: webdav compliant resouce Hi, according to RFC2518, it said a webdav compliant collection may hold not webdav compliant resource. if so, when I use propfind with and depth = 1 header to request properties, webdav should make response for all properties of its immediate members or just for all properties of its immediate members which is webdav compliant. how to identify a webdav compliant resource or not. Thanks Tao Wan DBTI Content Management IBM Silicon Valley Labs, San Jose, CA Phone: 408 463 2256 Internet email: want@us.ibm.com From w3c-dist-auth-request@w3.org Tue Jul 10 03:43:37 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24876 for ; Tue, 10 Jul 2001 03:43:37 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA09969; Tue, 10 Jul 2001 03:42:10 -0400 (EDT) Resent-Date: Tue, 10 Jul 2001 03:42:10 -0400 (EDT) Resent-Message-Id: <200107100742.DAA09969@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA09908 for ; Tue, 10 Jul 2001 03:41:56 -0400 (EDT) Received: from aslan.computas.com ([193.71.42.32]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA03308 for ; Tue, 10 Jul 2001 03:41:55 -0400 To: w3c-dist-auth@w3.org References: <3906C56A7BD1F54593344C05BD1374B1018E2502@SUS-MA1IT01> From: Steinar Bang In-Reply-To: (Steinar Bang's message of "Thu, 05 Jul 2001 08:31:04 +0200") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 10 Jul 2001 09:41:51 +0200 Subject: Re: WebDAV and write access discovery Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5142 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: >>>>> Steinar Bang : > Yet another approach would be to do a PROPFIND on the resource, to > see if it has any locks. Or aren't lock tokens listed as > properties? (One tricky bit here would be to map from the HREF to > the authenticated user, but presumably I would know what URL I set > myself.) I've used cadaver against mod_dav on my laptop (SuSE 6.4 linux), and what it uses as the of a lock is username@hostname (where "username" is the name you're authenticated as, and hostname is the name of the host withouth the domain name). But that's mod_dav on one particular machine. It doesn't say anything about what another mod_dav installation might do, or what IIS does. :-/ From w3c-dist-auth-request@w3.org Tue Jul 10 03:43:40 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24896 for ; Tue, 10 Jul 2001 03:43:40 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA10006; Tue, 10 Jul 2001 03:42:14 -0400 (EDT) Resent-Date: Tue, 10 Jul 2001 03:42:14 -0400 (EDT) Resent-Message-Id: <200107100742.DAA10006@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA09906 for ; Tue, 10 Jul 2001 03:41:56 -0400 (EDT) Received: from aslan.computas.com ([193.71.42.32]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA03307 for ; Tue, 10 Jul 2001 03:41:55 -0400 To: w3c-dist-auth@w3.org References: <3906C56A7BD1F54593344C05BD1374B1038E14BD@SUS-MA1IT01> From: Steinar Bang In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1038E14BD@SUS-MA1IT01> ("Clemm, Geoff"'s message of "Thu, 5 Jul 2001 09:30:52 -0400") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 10 Jul 2001 09:41:51 +0200 Subject: Re: WebDAV and write access discovery Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5143 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: >>>>> "Clemm, Geoff" : > From: Steinar Bang [mailto:sb@metis.no] >> but I don't know whether or not servers tend to fail requests to >> get write-locks on read-only resources. >> I thought 8.10.7 of RFC 2518 would require them to return a 412 in >> this case (ie. "lock token not enforcable on this resource")...? > A write lock does not guarantee the lock-token-holder the ability to > write to a resource ... it just denies non-lock-token-holders that > ability. So a server would be enforcing the lock, even if there are > reasons (such as ACLs) that prevent the lock-holder from writing to > the resource. I think allowing locks on non-writable resources will create a lot of confused client writers. What's the rationale for keeping lock functionality separate from the writability of a resource? From w3c-dist-auth-request@w3.org Tue Jul 10 12:57:09 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08638 for ; Tue, 10 Jul 2001 12:57:08 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA12773; Tue, 10 Jul 2001 12:55:44 -0400 (EDT) Resent-Date: Tue, 10 Jul 2001 12:55:44 -0400 (EDT) Resent-Message-Id: <200107101655.MAA12773@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA12746 for ; Tue, 10 Jul 2001 12:55:39 -0400 (EDT) Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA28257 for ; Tue, 10 Jul 2001 12:55:38 -0400 Received: from gmgw01.us.oracle.com (gmgw01.us.oracle.com [130.35.249.115]) by inet-mail4.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f6AGler10895 for ; Tue, 10 Jul 2001 09:47:40 -0700 (PDT) Received: from esedlarlaptop (dhcp-4op7-4op8-west-130-35-170-87.us.oracle.com [130.35.170.87]) by gmgw01.us.oracle.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f6AGrQj18624 for ; Tue, 10 Jul 2001 09:53:26 -0700 (PDT) From: "Eric Sedlar" To: Date: Tue, 10 Jul 2001 09:57:59 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Subject: RE: WebDAV and write access discovery Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5144 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: Content-Transfer-Encoding: 7bit Perhaps a better thing to do would be to add privileges controlling who can LOCK a resource? (This could be aggregated under write on particular implementations) --Eric > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Steinar Bang > Sent: Tuesday, July 10, 2001 12:42 AM > To: w3c-dist-auth@w3.org > Subject: Re: WebDAV and write access discovery > > > >>>>> "Clemm, Geoff" : > > > From: Steinar Bang [mailto:sb@metis.no] > >> but I don't know whether or not servers tend to fail requests to > >> get write-locks on read-only resources. > > >> I thought 8.10.7 of RFC 2518 would require them to return a 412 in > >> this case (ie. "lock token not enforcable on this resource")...? > > > A write lock does not guarantee the lock-token-holder the ability to > > write to a resource ... it just denies non-lock-token-holders that > > ability. So a server would be enforcing the lock, even if there are > > reasons (such as ACLs) that prevent the lock-holder from writing to > > the resource. > > I think allowing locks on non-writable resources will create a lot of > confused client writers. > > What's the rationale for keeping lock functionality separate from the > writability of a resource? > > From w3c-dist-auth-request@w3.org Wed Jul 11 17:43:14 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21540 for ; Wed, 11 Jul 2001 17:43:13 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA05324; Wed, 11 Jul 2001 17:41:54 -0400 (EDT) Resent-Date: Wed, 11 Jul 2001 17:41:54 -0400 (EDT) Resent-Message-Id: <200107112141.RAA05324@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA05304 for ; Wed, 11 Jul 2001 17:41:50 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA31823 for ; Wed, 11 Jul 2001 17:41:49 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id OAA26421 for ; Wed, 11 Jul 2001 14:41:54 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Wed, 11 Jul 2001 14:39:18 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: London IETF update Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5145 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: Content-Transfer-Encoding: 7bit In the latest IETF schedule, the WebDAV working group meeting has been CHANGED. The new time is: Monday, August 6, 2001, from 9-11:30AM. DeltaV is still scheduled for: Wednesday, August 8, 2001, from 1-3PM. - Jim From w3c-dist-auth-request@w3.org Wed Jul 11 22:02:34 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA27912 for ; Wed, 11 Jul 2001 22:02:33 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA14950; Wed, 11 Jul 2001 21:58:34 -0400 (EDT) Resent-Date: Wed, 11 Jul 2001 21:58:34 -0400 (EDT) Resent-Message-Id: <200107120158.VAA14950@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA14930 for ; Wed, 11 Jul 2001 21:58:25 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA21804 for ; Wed, 11 Jul 2001 21:58:25 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id SAA06376 for ; Wed, 11 Jul 2001 18:58:31 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Wed, 11 Jul 2001 18:55:53 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: More than halfway through ACL last call Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5146 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: Content-Transfer-Encoding: 7bit Just a quick reminder that the WebDAV Working Group is currently a little bit more than halfway through a Working Group Last Call for Comments on the WebDAV Access Control Protocol, draft-ietf-webdav-acl-06. The comments period ends July 29, 2001, at midnight, US Pacific time. The initial message starting the comments period can be found here: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0313.html This specification is available in the following formats: Text (normative version): http://www.ietf.org/internet-drafts/draft-ietf-webdav-acl-06.txt http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-06.txt HTML: http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-06.htm PDF: http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-06.pdf Word (with change tracking active): http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-06.doc Based on the comments I have seen so far, it looks like the -06 specification will be changed only slightly to remedy problems identified in the comments, and then forwarded along to the IESG for approval. As a result, this is looking very much like the final call for comments within the working group, and hence if you are intending to review this document, you should do so by the 29th. - Jim From w3c-dist-auth-request@w3.org Thu Jul 12 01:55:29 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20176 for ; Thu, 12 Jul 2001 01:55:28 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA19951; Thu, 12 Jul 2001 01:54:48 -0400 (EDT) Resent-Date: Thu, 12 Jul 2001 01:54:48 -0400 (EDT) Resent-Message-Id: <200107120554.BAA19951@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id BAA19931 for ; Thu, 12 Jul 2001 01:54:40 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA06373 for ; Thu, 12 Jul 2001 01:54:40 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id BAA256706 for ; Thu, 12 Jul 2001 01:52:15 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.96.1.0) with ESMTP id f6C5lvD21354 for ; Thu, 12 Jul 2001 01:47:57 -0400 Importance: Normal To: "WebDAV" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Thu, 12 Jul 2001 01:41:02 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at 07/12/2001 01:54:08 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id BAA19931 Subject: rfc2818 issue: UNLOCK_BY_NON_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5147 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: Content-Transfer-Encoding: 8bit Okay All: I'm going through the issue list and am going to try to present two issues per week for a while. The first one up tonight is... ------------------------------------------------------------------ UNLOCK_BY_NON_LOCK_OWNER At present, the specification is not explicit about who might be capable of grabbing a lock token via lock discovery and the submitting it in UNLOCK (and/or for a subsequent write operation). It is OK for the resource owner to grab the lock token and do UNLOCK/write? Is it OK to have a "grab lock token" privilege that can be assigned to anyone? ----------------------------------------------------------------- The issues list notes that this was raised by Lisa Dusseault in private email (I believe to Jim). I also believe we discussed what is largely the same issue briefly recently. I think you can find them in reverse chronological order at... http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/index.html#351 in various threads mentioning lock discovery in their subject. I'll step back and let someone else kick of the discussion on this. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Thu Jul 12 01:56:05 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20319 for ; Thu, 12 Jul 2001 01:56:04 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA19999; Thu, 12 Jul 2001 01:55:35 -0400 (EDT) Resent-Date: Thu, 12 Jul 2001 01:55:35 -0400 (EDT) Resent-Message-Id: <200107120555.BAA19999@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id BAA19976 for ; Thu, 12 Jul 2001 01:55:25 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA06430 for ; Thu, 12 Jul 2001 01:55:25 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id BAA450408 for ; Thu, 12 Jul 2001 01:52:58 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.96.1.0) with ESMTP id f6C5meD191018 for ; Thu, 12 Jul 2001 01:48:40 -0400 Importance: Normal To: "WebDAV" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Thu, 12 Jul 2001 01:54:43 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at 07/12/2001 01:54:51 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5148 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: I've just entered this one in the issues list. I think we basically settled on this but I just want to make sure. ----------------------------------------------------------------------------- DEFER_LOCK_NULL_RESOURCES_IN_SPEC Proposal to remove lock null resources from the spec until we are motivated to have them or something equivalent. In the meantime, keep the spec silent on the topic in order to avoid precluding LNR or the equivalent in a future version of WebDAV. ------------------------------------------------------------------ The issue references the following posting http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0354.html and more particularly the following paragraph: So I think we should just say "A server SHOULD fail an attempt to lock an unmapped URL", and then remain silent on what a server might end up doing if it lets the lock of an unmapped URL succeed. In general, a MAY here is of little more use to the client than having the protocol remain discretely silent, and the benefit of using one of the several different flavors of lock-null behavior is unlikely to warrant writing special purpose code for each of those flavors. If we can get this resolved it might actually resolve a lot of other unresolved issues on the issues list. Let's try to settle on this by Monday. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Thu Jul 12 14:47:18 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04106 for ; Thu, 12 Jul 2001 14:47:17 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA26864; Thu, 12 Jul 2001 14:46:29 -0400 (EDT) Resent-Date: Thu, 12 Jul 2001 14:46:29 -0400 (EDT) Resent-Message-Id: <200107121846.OAA26864@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA26844 for ; Thu, 12 Jul 2001 14:46:22 -0400 (EDT) Received: from front1.mail.megapathdsl.net (front1.mail.megapathdsl.net [66.80.60.31]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA11580 for ; Thu, 12 Jul 2001 14:46:21 -0400 Received: from [216.36.75.57] (HELO beaver) by front1.mail.megapathdsl.net (CommuniGate Pro SMTP 3.4.8a) with SMTP id 2053462; Thu, 12 Jul 2001 11:42:43 -0700 From: "Lisa Dusseault" To: "Jason Crawford" , "WebDAV" Date: Thu, 12 Jul 2001 11:45:59 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Importance: Normal Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5149 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: Content-Transfer-Encoding: 7bit Good thing you're making sure :) Since somebody was asking if lock-null resources have been implemented: - Xythos WebFile Server implements lock-null resources - I believe the Microsoft DAV servers allow LOCK of a non-mapped URL then PUT. Their version of a lock null resource may not support MKCOL, and it may not disappear when the lock expires, but it still solves the lost-update problem for a new resource (not a problem for MKCOL). - Our tests of Office XP show it seems to use lock null resources. My next concern is that the functionality was intended to solve an important problem - the lost-update problem for a new resource is the problem that two users can both try to create a resource with the same name using PUT. One overwrites the other unwittingly. LOCK already solves the lost-update problem for existing resources, so it seemed reasonable at the time to use the same mechanism for new resources. Since lock null resources solve an important problem, and since they have been implemented, I'd object to removing them from RFC2518. Although it may be possible to try to simplify, I'd hesitate. We'd want to make sure there was a good reason to do that. Is there any serious problem with the existing definition? lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Wednesday, July 11, 2001 10:55 PM > To: WebDAV > Subject: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC > > > > > I've just entered this one in the issues list. I think we basically > settled on this but I just want to make sure. > > ------------------------------------------------------------------ > ----------- > > DEFER_LOCK_NULL_RESOURCES_IN_SPEC > > Proposal to remove lock null resources from the spec until we are > motivated > to have them or something equivalent. In the meantime, keep the spec > silent on the topic in order to avoid precluding LNR or the > equivalent in a > future version of WebDAV. > ------------------------------------------------------------------ > > The issue references the following posting > > http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0354.html > > and more particularly the following paragraph: > > So I think we should just say "A server SHOULD fail > an attempt to lock an unmapped URL", and then remain > silent on what a server might end up doing if it lets > the lock of an unmapped URL succeed. In general, > a MAY here is of little more use to the client than having > the protocol remain discretely silent, and the > benefit of using one of the several different > flavors of lock-null behavior is unlikely to warrant > writing special purpose code for each of those flavors. > > If we can get this resolved it might actually resolve a lot of other > unresolved issues on the issues list. Let's try to settle on this by > Monday. > > J. > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Thu Jul 12 15:43:20 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13180 for ; Thu, 12 Jul 2001 15:43:20 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA29121; Thu, 12 Jul 2001 15:42:40 -0400 (EDT) Resent-Date: Thu, 12 Jul 2001 15:42:40 -0400 (EDT) Resent-Message-Id: <200107121942.PAA29121@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA29101 for ; Thu, 12 Jul 2001 15:42:36 -0400 (EDT) Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA17236 for ; Thu, 12 Jul 2001 15:42:36 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA22800 for ; Thu, 12 Jul 2001 15:34:36 -0400 Received: from f3n44e (d03nm044h.boulder.ibm.com [9.99.140.44]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.96.1.0) with ESMTP id f6CJgZp121668 for ; Thu, 12 Jul 2001 13:42:35 -0600 To: "WebDAV" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Tao Wan" Date: Thu, 12 Jul 2001 12:42:33 -0700 X-MIMETrack: Serialize by Router on D03NM044/03/M/IBM(Release 5.0.6 |December 14, 2000) at 07/12/2001 01:42:34 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: proppatch on null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5150 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: Hi, I read your paper about "Proposed Extensions to WebDAV Properties" linked through http://www.ics.uci.edu/pub/ietf/webdav/props/draft-ietf-webdav-properties-extension-00.txt, we have same problem with yours. that is proppatch on a null resource. I am not sure whether WebDAV spec. can support a proppatch on a null resource right now. I mean if I perform a proppatch on a null resource does this method create this resource with the properties defined in element inside element? Thanks Tao Wan Internet email: want@us.ibm.com From w3c-dist-auth-request@w3.org Fri Jul 13 14:38:53 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20713 for ; Fri, 13 Jul 2001 14:38:53 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA04853; Fri, 13 Jul 2001 14:37:57 -0400 (EDT) Resent-Date: Fri, 13 Jul 2001 14:37:57 -0400 (EDT) Resent-Message-Id: <200107131837.OAA04853@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA04821 for ; Fri, 13 Jul 2001 14:37:50 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37015.rational.com [192.229.37.15]) by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA07738 for ; Fri, 13 Jul 2001 14:37:50 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Fri, 13 Jul 2001 14:45:12 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <36L1KWTT>; Fri, 13 Jul 2001 14:45:12 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103A38521@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV Date: Fri, 13 Jul 2001 14:45:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5151 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: From: Lisa Dusseault [mailto:lisa@xythos.com] Since somebody was asking if lock-null resources have been implemented: - Xythos WebFile Server implements lock-null resources - I believe the Microsoft DAV servers allow LOCK of a non-mapped URL then PUT. Their version of a lock null resource may not support MKCOL, and it may not disappear when the lock expires, but it still solves the lost-update problem for a new resource (not a problem for MKCOL). - Our tests of Office XP show it seems to use lock null resources. Note that the main issue is not whether anyone has implemented lock null resources, but rather that different repositories have implemented them differently because the current lock null semantics are incompatible with the semantics of those repositories. To me, this is a clear signal that lock null resources are not a basis for interoperability. My next concern is that the functionality was intended to solve an important problem - the lost-update problem for a new resource is the problem that two users can both try to create a resource with the same name using PUT. One overwrites the other unwittingly. It has been demonstrated in the recent thread on lock null resources that the lost-update problem for a new resource can be solved without the use of lock-null resources. In particular, you do a PUT/If-None-Match with a zero length body, followed by a LOCK (or if you wanted to create a collection, a MKCOL followed by a LOCK, or if you wanted to create an activity, a MKACTIVITY followed by a LOCK, etc.). LOCK already solves the lost-update problem for existing resources, so it seemed reasonable at the time to use the same mechanism for new resources. Yes, but there is no need for a lock-null resource. You create an "empty" resource at the location, which gives you a real resource to lock, and then lock it (before you do any updates to that resource that you care about). The fact that another client can LOCK the new empty resource is of no significance, since it does not have any of the content that you care about yet (i.e. it is no different from them getting their "lock" request in before yours). If the server gives the owner special permissions on the new resource, that is fine (and only the creating client's LOCK will succeed), but it is not necessary for solving the lost update to a new resource problem. Since lock null resources solve an important problem, and since they have been implemented, I'd object to removing them from RFC2518. Although it may be possible to try to simplify, I'd hesitate. We'd want to make sure there was a good reason to do that. Is there any serious problem with the existing definition? The current implementations have demonstrated that lock null resources are not a basis for interoperability. That is the serious problem that is being addressed by removing them from the protocol. Cheers, Geoff From w3c-dist-auth-request@w3.org Fri Jul 13 14:38:55 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20728 for ; Fri, 13 Jul 2001 14:38:54 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA04889; Fri, 13 Jul 2001 14:38:07 -0400 (EDT) Resent-Date: Fri, 13 Jul 2001 14:38:07 -0400 (EDT) Resent-Message-Id: <200107131838.OAA04889@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA04832 for ; Fri, 13 Jul 2001 14:37:52 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37015.rational.com [192.229.37.15]) by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA07741 for ; Fri, 13 Jul 2001 14:37:52 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Fri, 13 Jul 2001 14:45:09 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <36L1KWTP>; Fri, 13 Jul 2001 14:45:09 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103A38520@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV Date: Fri, 13 Jul 2001 14:45:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: proppatch on null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5152 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: You cannot PROPPATCH a null resource because most repositories need to know what kind of resource you are creating (collection, non-collection, whatever). So you first need to create the resource before you can PROPPATCH it. Cheers, Geoff -----Original Message----- From: Tao Wan [mailto:want@us.ibm.com] Sent: Thursday, July 12, 2001 3:43 PM To: WebDAV Subject: proppatch on null resource Hi, I read your paper about "Proposed Extensions to WebDAV Properties" linked through http://www.ics.uci.edu/pub/ietf/webdav/props/draft-ietf-webdav-properties-ex tension-00.txt, we have same problem with yours. that is proppatch on a null resource. I am not sure whether WebDAV spec. can support a proppatch on a null resource right now. I mean if I perform a proppatch on a null resource does this method create this resource with the properties defined in element inside element? Thanks Tao Wan Internet email: want@us.ibm.com From w3c-dist-auth-request@w3.org Fri Jul 13 18:09:37 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19072 for ; Fri, 13 Jul 2001 18:09:37 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA13613; Fri, 13 Jul 2001 18:07:49 -0400 (EDT) Resent-Date: Fri, 13 Jul 2001 18:07:49 -0400 (EDT) Resent-Message-Id: <200107132207.SAA13613@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA13593 for ; Fri, 13 Jul 2001 18:07:45 -0400 (EDT) Received: from front2.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA28288 for ; Fri, 13 Jul 2001 18:07:37 -0400 Received: from [216.36.75.57] (HELO beaver) by front2.mail.megapathdsl.net (CommuniGate Pro SMTP 3.4.8a) with SMTP id 2261929; Fri, 13 Jul 2001 15:03:26 -0700 From: "Lisa Dusseault" To: "Jason Crawford" , "WebDAV" Date: Fri, 13 Jul 2001 15:07:11 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Subject: RE: rfc2818 issue: UNLOCK_BY_NON_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5153 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: Content-Transfer-Encoding: 7bit Well, since I was the one who brought it up, here are my thoughts. It seems not entirely unreasonable to have a system where the resource owner can remove locks on their resource, even locks that the resource owner did not create. With ACLs in the mix, this makes even more sense. After all, if somebody has the ability to grant permission whether or not somebody can lock a resource, they might as well have the ability to remove locks. To the client that had their lock disappear, it's just like the lock expired. They can try to get another. There may be changes they may have to merge. Now it doesn't have to be the resource owner that can do this. It can be entirely up to the implementation or the lock policy. This is made nicely possible in WebDAV because it makes the locktoken available for anybody to use to try to UNLOCK the resource. It just leaves it up to the implementation whether or not to allow this to succeed. lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Wednesday, July 11, 2001 10:41 PM > To: WebDAV > Subject: rfc2818 issue: UNLOCK_BY_NON_LOCK_OWNER > > > > > Okay All: I'm going through the issue list and am going to try > to present > two issues per week for a while. The first one up tonight is... > > ------------------------------------------------------------------ > UNLOCK_BY_NON_LOCK_OWNER > > At present, the specification is not explicit about who might be > capable of > grabbing a lock token via lock discovery and the submitting it in UNLOCK > (and/or for a subsequent write operation). It is OK for the resource owner > to grab the lock token and do UNLOCK/write? Is it OK to have a "grab lock > token" privilege that can be assigned to anyone? > ----------------------------------------------------------------- > > The issues list notes that this was raised by Lisa Dusseault in private > email (I believe to Jim). I also believe we discussed what is largely the > same issue briefly recently. I think you can find them in reverse > chronological order at... > > http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/index .html#351 in various threads mentioning lock discovery in their subject. I'll step back and let someone else kick of the discussion on this. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Fri Jul 13 18:53:51 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24133 for ; Fri, 13 Jul 2001 18:53:50 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA15567; Fri, 13 Jul 2001 18:53:15 -0400 (EDT) Resent-Date: Fri, 13 Jul 2001 18:53:15 -0400 (EDT) Resent-Message-Id: <200107132253.SAA15567@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA15544 for ; Fri, 13 Jul 2001 18:53:10 -0400 (EDT) Received: from mail.cruzio.com (root@mail.cruzio.com [63.249.64.37]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA32705 for ; Fri, 13 Jul 2001 18:53:10 -0400 Received: from Tycho (dsl3-63-249-84-213.cruzio.com [63.249.84.213]) by mail.cruzio.com with SMTP id PAA28254 for ; Fri, 13 Jul 2001 15:53:03 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Fri, 13 Jul 2001 15:50:30 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: Mailing list outage: acl, dav-dev, interop Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5154 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: Content-Transfer-Encoding: 7bit Well, as Murphy would have it, while Greg Stein is away on his honeymoon, the mailing list software he maintains has stopped working. Unfortunately, we never established any procedures for how to handle this kind of situation... :-( I'm pretty sure this affects all "@webdav.org" and "@lyra.org" mailing lists, including "acl@webdav.org", "interop@webdav.org", and "dav-dev@lyra.org". An alternate mailing list for the interop event has been created. I just sent out a message to this list -- if you didn't receive such a message, and are planning on attending the interop event, please let me know. I expect the mailing lists will come back up on the 26th. - Jim From w3c-dist-auth-request@w3.org Sat Jul 14 14:14:39 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17445 for ; Sat, 14 Jul 2001 14:14:38 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA21006; Sat, 14 Jul 2001 14:13:27 -0400 (EDT) Resent-Date: Sat, 14 Jul 2001 14:13:27 -0400 (EDT) Resent-Message-Id: <200107141813.OAA21006@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA20890 for ; Sat, 14 Jul 2001 14:13:21 -0400 (EDT) Received: from mail.cruzio.com (root@mail.cruzio.com [63.249.64.37]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA30528 for ; Sat, 14 Jul 2001 14:13:19 -0400 Received: from Tycho (dsl3-63-249-84-213.cruzio.com [63.249.84.213]) by mail.cruzio.com with SMTP id LAA13165 for ; Sat, 14 Jul 2001 11:13:12 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Sat, 14 Jul 2001 11:10:38 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: Yet another London IETF schedule change Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5155 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: Content-Transfer-Encoding: 7bit After it was discovered that the WebDAV WG meeting was at the same time as the Application Area open meeting, the WebDAV WG meeting was moved to a different slot, still on Monday. So, the current meeting slot for the WebDAV WG at the London IETF meeting is: Monday, August 6: 15:30-17:30 DeltaV is still Wednesday, 13:00-15:00 Details on the London IETF can be found at: http://www.ietf.org/meetings/IETF-51.html I encourage people who are attending the London IETF meeting to go to the Applications Area open meeting (Monday, 9AM), since it's a good way to gain an overview of other standardization activities going on at the top of the protocol stack. Additionally, it would be interesting for WebDAV WG members to attend the meeting of the IMAP Extensions WG, also Monday, at 19:30-22:00. IMAPEXT is considering issues such as access control, and message ordering, ones that we have tackled in WebDAV as well. - Jim From w3c-dist-auth-request@w3.org Sun Jul 15 07:20:20 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05715 for ; Sun, 15 Jul 2001 07:20:20 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA06894; Sun, 15 Jul 2001 07:15:07 -0400 (EDT) Resent-Date: Sun, 15 Jul 2001 07:15:07 -0400 (EDT) Resent-Message-Id: <200107151115.HAA06894@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id HAA06872 for ; Sun, 15 Jul 2001 07:14:58 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37015.rational.com [192.229.37.15]) by tux.w3.org (8.9.3/8.9.3) with SMTP id HAA31681 for ; Sun, 15 Jul 2001 07:14:58 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Sun, 15 Jul 2001 07:22:10 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <36L1MF0H>; Sun, 15 Jul 2001 07:22:10 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103A38624@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV Date: Sun, 15 Jul 2001 07:22:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: rfc2818 issue: UNLOCK_BY_NON_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5156 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: I agree with Lisa that who can unlock a resource should be an access control issue (exposable and controllable through the access control protocol), and not something hard-wired into the locking protocol. I would extend this statement to say that this applies to any use of a lock token on a resource, not just to who can use it for UNLOCK. So I would remove the "only by owner" language in 2518, which states that only the "owner" of a lock token can use it, and replace it with "only a client with sufficient privileges". Cheers, Geoff -----Original Message----- From: Lisa Dusseault [mailto:lisa@xythos.com] Sent: Friday, July 13, 2001 6:07 PM To: Jason Crawford; WebDAV Subject: RE: rfc2818 issue: UNLOCK_BY_NON_LOCK_OWNER Well, since I was the one who brought it up, here are my thoughts. It seems not entirely unreasonable to have a system where the resource owner can remove locks on their resource, even locks that the resource owner did not create. With ACLs in the mix, this makes even more sense. After all, if somebody has the ability to grant permission whether or not somebody can lock a resource, they might as well have the ability to remove locks. To the client that had their lock disappear, it's just like the lock expired. They can try to get another. There may be changes they may have to merge. Now it doesn't have to be the resource owner that can do this. It can be entirely up to the implementation or the lock policy. This is made nicely possible in WebDAV because it makes the locktoken available for anybody to use to try to UNLOCK the resource. It just leaves it up to the implementation whether or not to allow this to succeed. lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Wednesday, July 11, 2001 10:41 PM > To: WebDAV > Subject: rfc2818 issue: UNLOCK_BY_NON_LOCK_OWNER > > > > > Okay All: I'm going through the issue list and am going to try > to present > two issues per week for a while. The first one up tonight is... > > ------------------------------------------------------------------ > UNLOCK_BY_NON_LOCK_OWNER > > At present, the specification is not explicit about who might be > capable of > grabbing a lock token via lock discovery and the submitting it in UNLOCK > (and/or for a subsequent write operation). It is OK for the resource owner > to grab the lock token and do UNLOCK/write? Is it OK to have a "grab lock > token" privilege that can be assigned to anyone? > ----------------------------------------------------------------- > > The issues list notes that this was raised by Lisa Dusseault in private > email (I believe to Jim). I also believe we discussed what is largely the > same issue briefly recently. I think you can find them in reverse > chronological order at... > > http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/index .html#351 in various threads mentioning lock discovery in their subject. I'll step back and let someone else kick of the discussion on this. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Mon Jul 16 06:12:41 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04728 for ; Mon, 16 Jul 2001 06:12:41 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA12007; Mon, 16 Jul 2001 06:11:12 -0400 (EDT) Resent-Date: Mon, 16 Jul 2001 06:11:12 -0400 (EDT) Resent-Message-Id: <200107161011.GAA12007@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA11987 for ; Mon, 16 Jul 2001 06:11:06 -0400 (EDT) Received: from d06lmsgate-3.uk.ibm.com (d06lmsgate-3.uk.ibm.com [195.212.29.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA26301 for ; Mon, 16 Jul 2001 06:11:06 -0400 Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147]) by d06lmsgate-3.uk.ibm.com (1.0.0) with ESMTP id LAA15942 for ; Mon, 16 Jul 2001 11:01:24 +0100 Received: from d06ml034.portsmouth.uk.ibm.com (d06ml034_cs0 [9.180.35.31]) by d06relay01.portsmouth.uk.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6GAAU341720 for ; Mon, 16 Jul 2001 11:10:30 +0100 To: "WebDAV" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Tim Ellison" Date: Mon, 16 Jul 2001 10:38:10 +0100 X-MIMETrack: Serialize by Router on D06ML034/06/M/IBM(Release 5.0.6 |December 14, 2000) at 16/07/2001 11:09:10 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: rfc2818 issue: UNLOCK_BY_NON_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5157 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: I agree with Lisa. Lisa wrote: > Well, since I was the one who brought it up, here are > my thoughts. > > It seems not entirely unreasonable to have a system > where the resource owner can remove locks on their > resource, even locks that the resource owner did not > create. With ACLs in the mix, this makes even more > sense. After all, if somebody has the ability to > grant permission whether or not somebody can lock a > resource, they might as well have the ability to remove > locks. > > To the client that had their lock disappear, it's just > like the lock expired. They can try to get another. > There may be changes they may have to merge. > > Now it doesn't have to be the resource owner that can > do this. It can be entirely up to the implementation > or the lock policy. This is made nicely possible in > WebDAV because it makes the locktoken available for > anybody to use to try to UNLOCK the resource. It just > leaves it up to the implementation whether or not to > allow this to succeed. From w3c-dist-auth-request@w3.org Mon Jul 16 08:45:37 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28336 for ; Mon, 16 Jul 2001 08:45:36 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA19031; Mon, 16 Jul 2001 08:38:56 -0400 (EDT) Resent-Date: Mon, 16 Jul 2001 08:38:56 -0400 (EDT) Resent-Message-Id: <200107161238.IAA19031@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id IAA19007 for ; Mon, 16 Jul 2001 08:38:45 -0400 (EDT) Received: from wgateout.merant.com ([193.129.81.248]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA05976 for ; Mon, 16 Jul 2001 08:38:45 -0400 Received: from stalmail.eu.merant.com ([10.130.13.220]) by wgateout.merant.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id NAA00018 for ; Mon, 16 Jul 2001 13:36:40 +0100 Received: by stalmail.eu.merant.com with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Jul 2001 13:38:29 +0100 Message-ID: <20CF1CE11441D411919C0008C7C5A13B0227E943@stalmail.eu.merant.com> From: Peter Raymond To: w3c-dist-auth@w3.org Date: Mon, 16 Jul 2001 13:38:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10DF4.36E1BEF0" Subject: A few comments on the ACL specification... Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5158 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: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C10DF4.36E1BEF0 Content-Type: text/plain; charset="iso-8859-1" Hi, I have read through the WebDAV Access Control Protocol specification (draft 6) and have a few comments/questions: 1) In section 1.1 where Terms are defined I think they are listed in the wrong order, it seems to make sense to me to explain ACE before we explain ACL, since one refers to the other. Similarly we should explain "Abstract Privilege" after we define ACE. 2) In the spec (section 1.1) we define "Protected Property" (which is also defined in the DeltaV specification), then in section 5.3 we say that DAV:current-user-privilege-set is a protected property, but it is computed. So I think the property more closely matches the DeltaV definition of a "Computed Property", could we include that in section 1.1? Also should we include these definitions in the list of "cross-dependencies" between the specifications in Section 20 at the end of the ACL spec? 3) In sections 5.3.1, 5.4.5, 8.1.4, 9.2.1, and 9.3.1 of the specification there are some foreign characters which I think should be double-quotes (I think these are just formatting errors). 4) In the later sections of the document we use the Precondition/Postcondition syntax, similar to the DeltaV specification, should we not include some definition of what pre/post conditions are and how they work (just like section 1.6 of the DeltaV specification). 5) In the specification we define the REPORT method and several reports, but it does not define the DAV:supported-report-set property. Should we also define that property so that an ACL aware client can tell if a given resource supports one of the ACL reports? P.S. Anyone know the status of the WebDAV bindings protocol? Is this working group editing this document or is it dead/experimental? Regards, -- Peter Raymond - MERANT Technical Architect (ADM) Tel: +44 (0)1727 813362 Fax: +44 (0)1727 869804 mailto:Peter.Raymond@merant.com WWW: http://www.merant.com ------_=_NextPart_001_01C10DF4.36E1BEF0 Content-Type: text/html; charset="iso-8859-1" A few comments on the ACL specification...

Hi,

I have read through the WebDAV Access Control Protocol specification (draft 6)
and have a few comments/questions:

1) In section 1.1 where Terms are defined I think they are listed in the wrong order,
it seems to make sense to me to explain ACE before we explain ACL, since
one refers to the other.  Similarly we should explain "Abstract Privilege" after
we define ACE.

2) In the spec (section 1.1) we define "Protected Property" (which is also defined in the
DeltaV specification), then in section 5.3 we say that DAV:current-user-privilege-set
is a protected property, but it is computed.  So I think the property more closely matches
the DeltaV definition of a "Computed Property", could we include that in section 1.1?
Also should we include these definitions in the list of "cross-dependencies" between the
specifications in Section 20 at the end of the ACL spec?

3) In sections 5.3.1, 5.4.5, 8.1.4, 9.2.1, and 9.3.1 of the specification there are some
foreign characters which I think should be double-quotes (I think these are just formatting
errors).

4) In the later sections of the document we use the Precondition/Postcondition syntax,
similar to the DeltaV specification, should we not include some definition of what
pre/post conditions are and how they work (just like section 1.6 of the DeltaV specification).

5) In the specification we define the REPORT method and several reports, but it does
not define the DAV:supported-report-set property.  Should we also define that property
so that an ACL aware client can tell if a given resource supports one of the ACL reports?

P.S. Anyone know the status of the WebDAV bindings protocol?  Is this working group
editing this document or is it dead/experimental?

Regards,
--
Peter Raymond - MERANT
Technical Architect (ADM)
Tel: +44 (0)1727 813362
Fax: +44 (0)1727 869804
mailto:Peter.Raymond@merant.com
WWW: http://www.merant.com


------_=_NextPart_001_01C10DF4.36E1BEF0-- From w3c-dist-auth-request@w3.org Mon Jul 16 12:18:05 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13224 for ; Mon, 16 Jul 2001 12:18:05 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA03459; Mon, 16 Jul 2001 12:16:34 -0400 (EDT) Resent-Date: Mon, 16 Jul 2001 12:16:34 -0400 (EDT) Resent-Message-Id: <200107161616.MAA03459@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA03406 for ; Mon, 16 Jul 2001 12:16:27 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA02077 for ; Mon, 16 Jul 2001 12:16:27 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id JAA11835; Mon, 16 Jul 2001 09:16:28 -0700 (PDT) From: "Jim Whitehead" To: "Peter Raymond" , Date: Mon, 16 Jul 2001 09:13:50 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20CF1CE11441D411919C0008C7C5A13B0227E943@stalmail.eu.merant.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: RE: A few comments on the ACL specification... Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5159 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: Content-Transfer-Encoding: 7bit Thank you for your detailed review of the ACL specification -- I'm a bit swamped right now to reply to each comment, but I'll give them detailed consideration when creating the -07 spec. > P.S. Anyone know the status of the WebDAV bindings protocol? > Is this working group editing this document or is it dead/experimental? This document is currently quiescent. It current status is that it has passed through a working group last call for comments period, which generated significant comments. These comments need to be integrated into the next version of the draft, and then another WG last call needs to be held. I am hopeful to get to this in the next few months, since I feel this draft needs to be done before we can bring 2518 to Draft standard status, since the bindings specification contains numerous fixes to the DAV containment model. - Jim From w3c-dist-auth-request@w3.org Tue Jul 17 06:41:10 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08167 for ; Tue, 17 Jul 2001 06:41:10 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA29969; Tue, 17 Jul 2001 06:37:24 -0400 (EDT) Resent-Date: Tue, 17 Jul 2001 06:37:24 -0400 (EDT) Resent-Message-Id: <200107171037.GAA29969@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA29949 for ; Tue, 17 Jul 2001 06:37:17 -0400 (EDT) Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA08966 for ; Tue, 17 Jul 2001 06:37:16 -0400 Received: from cs.bris.ac.uk (actually host lunaleka.cs.bris.ac.uk) by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Tue, 17 Jul 2001 11:37:10 +0100 Received: from cs.bris.ac.uk (lama [137.222.102.207]) by cs.bris.ac.uk (8.9.3/8.9.3) with ESMTP id LAA24770 for ; Tue, 17 Jul 2001 11:35:10 +0100 (BST) Message-ID: <3B5414DE.F1D38BBC@cs.bris.ac.uk> Date: Tue, 17 Jul 2001 11:35:10 +0100 From: "B. Shadgar" Organization: Bristol Computer Science Dept X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: WebDAV Resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5160 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: Content-Transfer-Encoding: 7bit Hi, I am wondering if anybody let me know or reference me which project and software support databases as it's resources, while using webdav features to have access control on the objects of database like tables, views and queries? And how they use of Webdav to implement access control. Bita Shadgar. From w3c-dist-auth-request@w3.org Tue Jul 17 07:08:57 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA12329 for ; Tue, 17 Jul 2001 07:08:57 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA00796; Tue, 17 Jul 2001 07:04:46 -0400 (EDT) Resent-Date: Tue, 17 Jul 2001 07:04:46 -0400 (EDT) Resent-Message-Id: <200107171104.HAA00796@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id HAA00776 for ; Tue, 17 Jul 2001 07:04:37 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA10844 for ; Tue, 17 Jul 2001 07:04:37 -0400 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id GAA79546; Tue, 17 Jul 2001 06:57:08 -0500 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.226.57]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6HB4a038112; Tue, 17 Jul 2001 07:04:37 -0400 Importance: Normal To: "B. Shadgar" Cc: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Steve K Speicher" Date: Tue, 17 Jul 2001 07:05:16 -0400 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Build M9_05202001 Beta 2|May 20, 2001) at 07/17/2001 07:04:36 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: WebDAV Resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5161 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: >I am wondering if anybody let me know or reference me which project and >software support databases as it's resources, while using webdav >features to have access control on the objects of database like tables, >views and queries? And how they use of Webdav to implement access >control. Lotus Domino RNext claims it will support WebDAV as you described. See http://www.informationweek.com/thisweek/story/IWK20010614S0003 - Steve From w3c-dist-auth-request@w3.org Tue Jul 17 07:47:30 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA17150 for ; Tue, 17 Jul 2001 07:47:30 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA02063; Tue, 17 Jul 2001 07:43:27 -0400 (EDT) Resent-Date: Tue, 17 Jul 2001 07:43:27 -0400 (EDT) Resent-Message-Id: <200107171143.HAA02063@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id HAA02039 for ; Tue, 17 Jul 2001 07:43:22 -0400 (EDT) Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA13764 for ; Tue, 17 Jul 2001 07:43:22 -0400 Received: from cs.bris.ac.uk (actually host lunaleka.cs.bris.ac.uk) by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Tue, 17 Jul 2001 12:43:10 +0100 Received: from cs.bris.ac.uk (lama [137.222.102.207]) by cs.bris.ac.uk (8.9.3/8.9.3) with ESMTP id MAA26342 for ; Tue, 17 Jul 2001 12:42:41 +0100 (BST) Message-ID: <3B5424B0.34F5C750@cs.bris.ac.uk> Date: Tue, 17 Jul 2001 12:42:41 +0100 From: "B. Shadgar" Organization: Bristol Computer Science Dept X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: multipart/mixed; boundary="------------A580AEFDE3E4DD811E9AFA31" Subject: [Fwd: WebDAV Resources] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5162 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: This is a multi-part message in MIME format. --------------A580AEFDE3E4DD811E9AFA31 Content-Type: multipart/alternative; boundary="------------9EF1C7A08693619DBCBDB51C" --------------9EF1C7A08693619DBCBDB51C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Does any body know any software or project else? Thanks. Bita Shadgar. --------------9EF1C7A08693619DBCBDB51C Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Does any body know any software or project else?

Thanks.
Bita Shadgar.

  --------------9EF1C7A08693619DBCBDB51C-- --------------A580AEFDE3E4DD811E9AFA31 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: Received: from dirc.bris.ac.uk (dirc.bris.ac.uk [137.222.10.51]) by cs.bris.ac.uk (8.9.3/8.9.3) with ESMTP id MAA25497 for ; Tue, 17 Jul 2001 12:04:47 +0100 (BST) Received: from e21.nc.us.ibm.com by dirc.bris.ac.uk with SMTP-SLOPPY with ESMTP; Tue, 17 Jul 2001 12:04:39 +0100 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id GAA79546; Tue, 17 Jul 2001 06:57:08 -0500 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.226.57]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6HB4a038112; Tue, 17 Jul 2001 07:04:37 -0400 Importance: Normal Sensitivity: Subject: Re: WebDAV Resources To: "B. Shadgar" Cc: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: Steve K Speicher Date: Tue, 17 Jul 2001 07:05:16 -0400 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Build M9_05202001 Beta 2|May 20, 2001) at 07/17/2001 07:04:36 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Mozilla-Status2: 00000000 >I am wondering if anybody let me know or reference me which project and >software support databases as it's resources, while using webdav >features to have access control on the objects of database like tables, >views and queries? And how they use of Webdav to implement access >control. Lotus Domino RNext claims it will support WebDAV as you described. See http://www.informationweek.com/thisweek/story/IWK20010614S0003 - Steve --------------A580AEFDE3E4DD811E9AFA31-- From w3c-dist-auth-request@w3.org Tue Jul 17 13:05:56 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21067 for ; Tue, 17 Jul 2001 13:05:55 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA23229; Tue, 17 Jul 2001 13:04:33 -0400 (EDT) Resent-Date: Tue, 17 Jul 2001 13:04:33 -0400 (EDT) Resent-Message-Id: <200107171704.NAA23229@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA23209 for ; Tue, 17 Jul 2001 13:04:28 -0400 (EDT) Received: from front1.mail.megapathdsl.net (front1.mail.megapathdsl.net [66.80.60.31]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA22003 for ; Tue, 17 Jul 2001 13:04:28 -0400 Received: from [216.36.75.57] (HELO beaver) by front1.mail.megapathdsl.net (CommuniGate Pro SMTP 3.4.8a) with SMTP id 2294581 for w3c-dist-auth@w3.org; Tue, 17 Jul 2001 10:00:39 -0700 From: "Lisa Dusseault" To: Date: Tue, 17 Jul 2001 10:04:03 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: Topics for Agenda for IETF London Webdav mtg Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5163 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: Content-Transfer-Encoding: 7bit I'm planning what to put on the agenda for the meeting Monday Aug 3. Please let me and/or the list know what you're interested in covering if you're attending. Overall topics: - RFC2518 issues - ACLs - DASL Anything I'm missing? lisa From w3c-dist-auth-request@w3.org Tue Jul 17 13:14:05 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23057 for ; Tue, 17 Jul 2001 13:14:04 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA23845; Tue, 17 Jul 2001 13:09:52 -0400 (EDT) Resent-Date: Tue, 17 Jul 2001 13:09:52 -0400 (EDT) Resent-Message-Id: <200107171709.NAA23845@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA23820 for ; Tue, 17 Jul 2001 13:09:44 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA22639 for ; Tue, 17 Jul 2001 13:09:44 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id KAA26251; Tue, 17 Jul 2001 10:09:43 -0700 (PDT) From: "Jim Whitehead" To: "B. Shadgar" , "WebDAV" Date: Tue, 17 Jul 2001 10:07:04 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3B5414DE.F1D38BBC@cs.bris.ac.uk> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: RE: WebDAV Resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5164 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: Content-Transfer-Encoding: 7bit > I am wondering if anybody let me know or reference me which project and > software support databases as it's resources, while using webdav > features to have access control on the objects of database like tables, > views and queries? And how they use of Webdav to implement access > control. I suppose it depends on how literally I read your request. I'm not sure I know of any servers that treat an entire database as a single WebDAV resource (well, I suppose you could store an entire Access database file on any DAV server...) As for servers that use a database for their internal representation and storage of resources and properties, several of the WebDAV servers do this. My understanding is that Xythos WebFile server, Exchange 2000, Oracle Internet File System, and Intraspect 4 are all database backed -- undoubtedly there are others as well. - Jim From w3c-dist-auth-request@w3.org Tue Jul 17 13:32:02 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27689 for ; Tue, 17 Jul 2001 13:32:01 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA24798; Tue, 17 Jul 2001 13:23:10 -0400 (EDT) Resent-Date: Tue, 17 Jul 2001 13:23:10 -0400 (EDT) Resent-Message-Id: <200107171723.NAA24798@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA24745 for ; Tue, 17 Jul 2001 13:22:37 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA24109; Tue, 17 Jul 2001 13:22:18 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23758; Tue, 17 Jul 2001 13:16:53 -0400 (EDT) Message-Id: <200107171716.NAA23758@ietf.org> From: The IESG To: AAA Working Group , ACAP Working Group , ADSLMIB Working Group , AFT Working Group , AGENTX Working Group , APEX Working Group , ATOMMIB Working Group , AVT Working Group , BEEP Working Group , BGMP Working Group , BMWG Working Group , BRIDGE Working Group , CALSCH Working Group , CAT Working Group , CCAMP Working Group , CNRP Working Group , DELTAV Working Group , DHC Working Group , DIFFSERV Working Group , DISMAN Working Group , DNSEXT Working Group , DNSOP Working Group , ECM Working Group , EDIINT Working Group , ENTMIB Working Group , ENUM Working Group , EOS Working Group , FAX Working Group , FRNETMIB Working Group , FTPEXT Working Group , GEOPRIV Working Group , GRIP Working Group , GSMP Working Group , HUBMIB Working Group , IDMR Working Group , IDN Working Group , IDR Working Group , IDWG Working Group , IFMIB Working Group , IMAPEXT Working Group , IMPP Working Group , IPCDN Working Group , IPFC Working Group , IPNGWG Working Group , IPO Working Group , IPORPR Working Group , IPP Working Group , IPPM Working Group , IPS Working Group , IPSEC Working Group , IPSP Working Group , IPSRA Working Group , IPTEL Working Group , ISIS Working Group , ISSLL Working Group , ITRACE Working Group , KINK Working Group , KRB-WG Working Group , L2TPEXT Working Group , LDAPBIS Working Group , LDAPEXT Working Group , LDUP Working Group , MALLOC Working Group , MANET Working Group , MBONED Working Group , MEGACO Working Group , MIDCOM Working Group , MMUSIC Working Group , MOBILEIP Working Group , MPLS Working Group , MSDP Working Group , MSEC Working Group , MSGTRK Working Group , MULTI6 Working Group , NASREQ Working Group , NAT Working Group , NFSV4 Working Group , NGTRANS Working Group , NNTPEXT Working Group , OPENPGP Working Group , OSPF Working Group , OTP Working Group , PILC Working Group , PIM Working Group , PKIX Working Group , POISSON Working Group , POLICY Working Group , PPPEXT Working Group , PPVPN Working Group , PROVREG Working Group , PWE3 Working Group , RAP Working Group , RESCAP Working Group , RIP Working Group , RMONMIB Working Group , RMT Working Group , ROHC Working Group , RSERPOOL Working Group , RUN Working Group , SACRED Working Group , SEAMOBY Working Group , SECSH Working Group , SIGTRAN Working Group , SIMPLE Working Group , SIP Working Group , SMIME Working Group , SMING Working Group , SNMPCONF Working Group , SNMPV3 Working Group , SPIRITS Working Group , SSM Working Group , STIME Working Group , SYSLOG Working Group , TEWG Working Group , TLS Working Group , TN3270E Working Group , TRADE Working Group , TSVWG Working Group , UDLR Working Group , URN Working Group , USEFOR Working Group , USWG Working Group , VPIM Working Group , VRRP Working Group , WEBDAV Working Group , WEBI Working Group , WTS Working Group , XMLDSIG Working Group , ZEROCONF Working Group cc: iesg@ietf.org Date: Tue, 17 Jul 2001 13:16:53 -0400 Subject: Note Well Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5165 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: Greetings, This is the revised text of the NOTE WELL statement. ------------------------------------------------------ NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. From w3c-dist-auth-request@w3.org Tue Jul 17 14:06:05 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27691 for ; Tue, 17 Jul 2001 13:32:02 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA25229; Tue, 17 Jul 2001 13:28:07 -0400 (EDT) Resent-Date: Tue, 17 Jul 2001 13:28:07 -0400 (EDT) Resent-Message-Id: <200107171728.NAA25229@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA25158 for ; Tue, 17 Jul 2001 13:27:47 -0400 (EDT) Received: from roam.psg.com (H-135-207-10-122.research.att.com [135.207.10.122]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA24620; Tue, 17 Jul 2001 13:27:48 -0400 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MYb7-0000LK-00; Tue, 17 Jul 2001 13:25:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rsent-To: eos@ops.ietf.org Approved: snmp From: The IESG To: AAA Working Group , ACAP Working Group , ADSLMIB Working Group , AFT Working Group , AGENTX Working Group , APEX Working Group , ATOMMIB Working Group , AVT Working Group , BEEP Working Group , BGMP Working Group , BMWG Working Group , BRIDGE Working Group , CALSCH Working Group , CAT Working Group , CCAMP Working Group , CNRP Working Group , DELTAV Working Group , DHC Working Group , DIFFSERV Working Group , DISMAN Working Group , DNSEXT Working Group , DNSOP Working Group , ECM Working Group , EDIINT Working Group , ENTMIB Working Group , ENUM Working Group , EOS Working Group , FAX Working Group , FRNETMIB Working Group , FTPEXT Working Group , GEOPRIV Working Group , GRIP Working Group , GSMP Working Group , HUBMIB Working Group , IDMR Working Group , IDN Working Group , IDR Working Group , IDWG Working Group , IFMIB Working Group , IMAPEXT Working Group , IMPP Working Group , IPCDN Working Group , IPFC Working Group , IPNGWG Working Group , IPO Working Group , IPORPR Working Group , IPP Working Group , IPPM Working Group , IPS Working Group , IPSEC Working Group , IPSP Working Group , IPSRA Working Group , IPTEL Working Group , ISIS Working Group , ISSLL Working Group , ITRACE Working Group , KINK Working Group , KRB-WG Working Group , L2TPEXT Working Group , LDAPBIS Working Group , LDAPEXT Working Group , LDUP Working Group , MALLOC Working Group , MANET Working Group , MBONED Working Group , MEGACO Working Group , MIDCOM Working Group , MMUSIC Working Group , MOBILEIP Working Group , MPLS Working Group , MSDP Working Group , MSEC Working Group , MSGTRK Working Group , MULTI6 Working Group , NASREQ Working Group , NAT Working Group , NFSV4 Working Group , NGTRANS Working Group , NNTPEXT Working Group , OPENPGP Working Group , OSPF Working Group , OTP Working Group , PILC Working Group , PIM Working Group , PKIX Working Group , POISSON Working Group , POLICY Working Group , PPPEXT Working Group , PPVPN Working Group , PROVREG Working Group , PWE3 Working Group , RAP Working Group , RESCAP Working Group , RIP Working Group , RMONMIB Working Group , RMT Working Group , ROHC Working Group , RSERPOOL Working Group , RUN Working Group , SACRED Working Group , SEAMOBY Working Group , SECSH Working Group , SIGTRAN Working Group , SIMPLE Working Group , SIP Working Group , SMIME Working Group , SMING Working Group , SNMPCONF Working Group , SNMPV3 Working Group , SPIRITS Working Group , SSM Working Group , STIME Working Group , SYSLOG Working Group , TEWG Working Group , TLS Working Group , TN3270E Working Group , TRADE Working Group , TSVWG Working Group , UDLR Working Group , URN Working Group , USEFOR Working Group , USWG Working Group , VPIM Working Group , VRRP Working Group , WEBDAV Working Group , WEBI Working Group , WTS Working Group , XMLDSIG Working Group , ZEROCONF Working Group cc: iesg@ietf.org Message-Id: Date: Tue, 17 Jul 2001 13:25:25 -0400 Subject: Note Well Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5166 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: Content-Transfer-Encoding: 7bit Greetings, This is the revised text of the NOTE WELL statement. ------------------------------------------------------ NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. From w3c-dist-auth-request@w3.org Tue Jul 17 22:43:35 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA19779 for ; Tue, 17 Jul 2001 22:43:34 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA18134; Tue, 17 Jul 2001 22:27:21 -0400 (EDT) Resent-Date: Tue, 17 Jul 2001 22:27:21 -0400 (EDT) Resent-Message-Id: <200107180227.WAA18134@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id WAA18111 for ; Tue, 17 Jul 2001 22:27:14 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA17292 for ; Tue, 17 Jul 2001 22:27:14 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id TAA25187 for ; Tue, 17 Jul 2001 19:27:21 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Tue, 17 Jul 2001 19:24:38 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: FW: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5167 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: Content-Transfer-Encoding: 7bit Jason had trouble sending a message to the DAV list -- let's see if this one goes through... - Jim -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Tuesday, July 17, 2001 7:12 PM To: ejw@cse.ucsc.edu Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Jim, The following note doesn't seem to have reached the list. You might want to probe for errors with the list server... ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com ---------------------- Forwarded by Jason Crawford/Watson/IBM on 07/17/2001 10:11 PM --------------------------- Jason Crawford 07/17/2001 04:26 PM To: "Clemm, Geoff" cc: WebDAV From: Jason Crawford/Watson/IBM@IBMUS Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC (Document link: Jason Crawford) Can have a few more people speak up on the above thread. So far we've just heard from Geoff and Lisa. Any comments on either of their postings? Any additional comments? ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Wed Jul 18 00:55:01 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA09610 for ; Wed, 18 Jul 2001 00:55:01 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA22293; Wed, 18 Jul 2001 00:39:18 -0400 (EDT) Resent-Date: Wed, 18 Jul 2001 00:39:18 -0400 (EDT) Resent-Message-Id: <200107180439.AAA22293@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id AAA22269 for ; Wed, 18 Jul 2001 00:39:13 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id AAA26591 for ; Wed, 18 Jul 2001 00:39:12 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id AAA245412; Wed, 18 Jul 2001 00:36:44 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.96.1.0) with ESMTP id f6I4WNN30062; Wed, 18 Jul 2001 00:32:23 -0400 Importance: Normal To: "Clemm, Geoff" Cc: WebDAV X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Wed, 18 Jul 2001 00:38:30 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at 07/18/2001 12:38:39 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5168 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: Can have a few more people speak up on the above thread. So far we've just heard from Geoff and Lisa. Any comments on either of their postings? Any additional comments? ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Wed Jul 18 04:24:33 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA28095 for ; Wed, 18 Jul 2001 04:24:33 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA28888; Wed, 18 Jul 2001 04:23:45 -0400 (EDT) Resent-Date: Wed, 18 Jul 2001 04:23:45 -0400 (EDT) Resent-Message-Id: <200107180823.EAA28888@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA28863 for ; Wed, 18 Jul 2001 04:23:34 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA12221 for ; Wed, 18 Jul 2001 04:23:32 -0400 Received: from maggie [192.168.1.2] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Wed, 18 Jul 2001 10:22:22 +0200 From: "Stefan Eissing" To: "WebDAV" Date: Wed, 18 Jul 2001 10:22:20 +0200 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-MDRemoteIP: 192.168.1.2 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5169 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: Content-Transfer-Encoding: 7bit > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > > Can have a few more people speak up on the above thread. So far we've > just heard from Geoff and Lisa. Any comments on either of their postings? > Any additional comments? > As an implementor of server and client software using WebDAV, I would have gladly skipped the mechanisms known as lock-null resources. As Geoff pointed out in this thread, there are alternatives for clients to live without them (although not quite as comfortable). But the choice to include lock-null has been made in the past and I see more trouble with abandoning it, than keeping it. Every implementation I've seen (and that might be too few) implements lock-null correctly. Apart from certain software from Seattle based companies: their server has an incomplete implementation, which works only for ordinary resources. It works good enough for the Seattle client software which uses this feature. Now, if WebDAV removes lock-null, every server implementor would have to support it anyway, because 90% of the users use those Seattle clients. I therefore see nothing to gain on the server side by abandoning lock-null. On the client side, lock-null is a comfortable thing to use. So there is nothing to gain either. So, I'd say: let's embrace and extend lock-null resources. From w3c-dist-auth-request@w3.org Wed Jul 18 05:17:53 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04929 for ; Wed, 18 Jul 2001 05:17:53 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA01556; Wed, 18 Jul 2001 05:17:53 -0400 (EDT) Resent-Date: Wed, 18 Jul 2001 05:17:53 -0400 (EDT) Resent-Message-Id: <200107180917.FAA01556@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA01535 for ; Wed, 18 Jul 2001 05:17:43 -0400 (EDT) Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA17028 for ; Wed, 18 Jul 2001 05:17:44 -0400 Received: from cs.bris.ac.uk (actually host lunaleka.cs.bris.ac.uk) by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Wed, 18 Jul 2001 10:17:11 +0100 Received: from cs.bris.ac.uk (lama [137.222.102.207]) by cs.bris.ac.uk (8.9.3/8.9.3) with ESMTP id KAA17306 for ; Wed, 18 Jul 2001 10:16:06 +0100 (BST) Message-ID: <3B5553D6.808A1BBA@cs.bris.ac.uk> Date: Wed, 18 Jul 2001 10:16:06 +0100 From: "B. Shadgar" Organization: Bristol Computer Science Dept X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: WebDAV levels Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5170 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: Content-Transfer-Encoding: 7bit Hi, It would be appreciated if you let me know what the WebDAV level 1 and WebDAV level 2 are. Are they the same as Class 1 and Class 2 in RFC 2518? Or if you reference me to find out about them. Thanks indeed, Shadgar. From w3c-dist-auth-request@w3.org Wed Jul 18 06:28:22 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA19529 for ; Wed, 18 Jul 2001 06:28:21 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA04398; Wed, 18 Jul 2001 06:27:24 -0400 (EDT) Resent-Date: Wed, 18 Jul 2001 06:27:24 -0400 (EDT) Resent-Message-Id: <200107181027.GAA04398@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA04378 for ; Wed, 18 Jul 2001 06:27:21 -0400 (EDT) Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA22780 for ; Wed, 18 Jul 2001 06:27:21 -0400 Received: from cs.bris.ac.uk (actually host lunaleka.cs.bris.ac.uk) by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Wed, 18 Jul 2001 11:27:12 +0100 Received: from cs.bris.ac.uk (lama [137.222.102.207]) by cs.bris.ac.uk (8.9.3/8.9.3) with ESMTP id LAA19136; Wed, 18 Jul 2001 11:26:38 +0100 (BST) Message-ID: <3B55645D.E5764138@cs.bris.ac.uk> Date: Wed, 18 Jul 2001 11:26:37 +0100 From: "B. Shadgar" Organization: Bristol Computer Science Dept X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ejw@cse.ucsc.edu, w3c-dist-auth@w3.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: RE: WebDAV Resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5171 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: Content-Transfer-Encoding: 7bit >> I am wondering if anybody let me know or reference me which project and >> features to have access control on the objects of database like tables, >> views and queries? And how they use of Webdav to implement access >> control. >I'm not sure I know of any servers that treat an entire database as a single >WebDAV resource (well, I suppose you could store an entire Access database >file on any DAV server...) By definition of WebDAV in RFC 2518, it that possible to consider a whole database as a resource? Or the resource in this document just stands for files and directories. Bita Shadgar. From w3c-dist-auth-request@w3.org Wed Jul 18 10:05:10 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29440 for ; Wed, 18 Jul 2001 10:05:09 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA18979; Wed, 18 Jul 2001 10:01:41 -0400 (EDT) Resent-Date: Wed, 18 Jul 2001 10:01:41 -0400 (EDT) Resent-Message-Id: <200107181401.KAA18979@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA18953 for ; Wed, 18 Jul 2001 10:01:33 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37015.rational.com [192.229.37.15]) by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA18233 for ; Wed, 18 Jul 2001 10:01:33 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Wed, 18 Jul 2001 10:09:02 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <36L1SV95>; Wed, 18 Jul 2001 10:09:02 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103A38D4B@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV Date: Wed, 18 Jul 2001 10:09:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5172 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: From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] As an implementor of server and client software using WebDAV, I would have gladly skipped the mechanisms known as lock-null resources. As Geoff pointed out in this thread, there are alternatives for clients to live without them (although not quite as comfortable). It's probably worth noting that a client gains little or nothing from the use of lock-null resources. In the common case, the user has selected either "Open" or "New" from some user interface. In the Open case, the user is expecting an error if the resource does not exist, so having LOCK return 404 actually makes the client protocol simpler. In the New case, the user is expecting an error if the resource already exists, so a PUT/If-None-Match can be used to determine if the resource does not exist, followed by a LOCK to verify the resource can be write locked. In case the user interface does not distinguish between Open and New, the client just follows the LOCK call with a: if status is 404 then PUT/If-None-Match # ignore status from this request LOCK and otherwise uses the exact same code it would have used if lock null resources were supported. (Note: the "PUT" would whatever is the right call to create a null resource of the right type, e.g. MKCOL for collections, MKACTIVITY for activities, or whatever). But the choice to include lock-null has been made in the past and I see more trouble with abandoning it, than keeping it. Every implementation I've seen (and that might be too few) implements lock-null correctly. You need to look at the Microsoft IIS implementation. When a LOCK is applied to an unmapped URI, it just automatically preceded the LOCK with a PUT with a 0 length body. The result is a regular locked resource, not a lock null resource. In particular, MKCOL will fail on that resource, and when you remove the lock, you still have the 0 length resource (i.e. it doesn't disappear, as a lock null resource is required to do). Note: Our implementation is likely to act the same way, probably for the same reasons as Microsoft, i.e. we support multiple protocols accessing our repository, and none of the other protocols have anything remotely resembling lock null resources. Apart from certain software from Seattle based companies: their server has an incomplete implementation, which works only for ordinary resources. It works good enough for the Seattle client software which uses this feature. Now, if WebDAV removes lock-null, every server implementor would have to support it anyway, because 90% of the users use those Seattle clients. I therefore see nothing to gain on the server side by abandoning lock-null. Having your server support the behavior expected by IIS is easy, just automatically create a 0-length resource. It is real lock-null behavior (which is not implemented by IIS) which is the problem. In the revised protocol, we can warn clients about the various ways that existing servers deal with a LOCK applied to an unmapped URI, but could increase interoperability in the future by stating that a LOCK to an unmapped URI SHOULD return a 404. On the client side, lock-null is a comfortable thing to use. So there is nothing to gain either. If you care about interoperability, it is not comfortable to use because it is not implemented uniformly, so you have to special case around the alternative implementations. The client code will be simpler if it just doesn't use lock null resources at all. So, I'd say: let's embrace and extend lock-null resources. Lock-null resources are very unlikely to be embraced by implementors who must care about multiple protocols accessing their repositories (and commercial vendors are almost all in that situation). Any attempt to embrace (much less extend) lock-null resources will result in interoperability problems. If they were the only good way to provide a key client use case, I'd be willing to live with the interoperability problems, but since the lock-null use cases are easily supported without lock-null resources, I see no reason to persist (much less, increase) these problems. Cheers, Geoff From w3c-dist-auth-request@w3.org Wed Jul 18 13:35:03 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18530 for ; Wed, 18 Jul 2001 13:35:03 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA05746; Wed, 18 Jul 2001 13:34:38 -0400 (EDT) Resent-Date: Wed, 18 Jul 2001 13:34:38 -0400 (EDT) Resent-Message-Id: <200107181734.NAA05746@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA05723 for ; Wed, 18 Jul 2001 13:34:34 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA27308 for ; Wed, 18 Jul 2001 13:34:34 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id KAA07944; Wed, 18 Jul 2001 10:34:34 -0700 (PDT) From: "Jim Whitehead" To: "B. Shadgar" , "WebDAV" Date: Wed, 18 Jul 2001 10:31:54 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3B5553D6.808A1BBA@cs.bris.ac.uk> Subject: RE: WebDAV levels Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5174 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: Content-Transfer-Encoding: 7bit > It would be appreciated if you let me know what the WebDAV level 1 and > WebDAV level 2 are. Are they the same as Class 1 and Class 2 in RFC > 2518? Or if you reference me to find out about them. They are one and the same. Level 1 = Class 1, Level 2 = Class 2. - Jim From w3c-dist-auth-request@w3.org Wed Jul 18 13:35:04 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18541 for ; Wed, 18 Jul 2001 13:35:04 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA05625; Wed, 18 Jul 2001 13:33:57 -0400 (EDT) Resent-Date: Wed, 18 Jul 2001 13:33:57 -0400 (EDT) Resent-Message-Id: <200107181733.NAA05625@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA05605 for ; Wed, 18 Jul 2001 13:33:53 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA27193 for ; Wed, 18 Jul 2001 13:33:53 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id KAA07830; Wed, 18 Jul 2001 10:33:53 -0700 (PDT) From: "Jim Whitehead" To: , "WebDAV" Date: Wed, 18 Jul 2001 10:31:13 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3B55645D.E5764138@cs.bris.ac.uk> Subject: RE: WebDAV Resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5173 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: Content-Transfer-Encoding: 7bit > By definition of WebDAV in RFC 2518, it that possible to consider a > whole database as a resource? Or the resource in this document just > stands for files and directories. The concept of a "resource" is intentionally loose. Basically, a resource is an abstraction. Since the notion of a database is an abstraction, just as a cell in a database is too, either could be considered resources. A resource can be mapped to a URI, URN, or URL. So, if you write a server implementation that maps an entire database as a resource, and maps it to a URL, then yes, it is possible to consider a database as a whole resource. Similarly, if you write a server implementation that maps individual database cells to a resource, then assigns each cell a distinct URL, then it is possible to consider a database cell as a Web resource. WebDAV defines operations for working with Web resources via HTTP, so the effect of a DAV operation on the underlying repository depends on the mapping of resources to abstractions in that repository. The "official" definition of a resource can be found in RFC 2396: http://www.ics.uci.edu/pub/ietf/uri/rfc2396.txt Resource A resource can be anything that has identity. Familiar examples include an electronic document, an image, a service (e.g., "today's weather report for Los Angeles"), and a collection of other resources. Not all resources are network "retrievable"; e.g., human beings, corporations, and bound books in a library can also be considered resources. The resource is the conceptual mapping to an entity or set of entities, not necessarily the entity which corresponds to that mapping at any particular instance in time. Thus, a resource can remain constant even when its content---the entities to which it currently corresponds---changes over time, provided that the conceptual mapping is not changed in the process. - Jim From w3c-dist-auth-request@w3.org Wed Jul 18 13:38:04 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19337 for ; Wed, 18 Jul 2001 13:38:03 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA05995; Wed, 18 Jul 2001 13:36:43 -0400 (EDT) Resent-Date: Wed, 18 Jul 2001 13:36:43 -0400 (EDT) Resent-Message-Id: <200107181736.NAA05995@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA05975 for ; Wed, 18 Jul 2001 13:36:40 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA27759 for ; Wed, 18 Jul 2001 13:36:39 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id KAA08365 for ; Wed, 18 Jul 2001 10:36:42 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Wed, 18 Jul 2001 10:34:02 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: FW: mod_dav / webdav questions (case sensitiveness / symbolic links) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5175 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: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I've added stefan.van.der.eijk@philips.com to the accept2 list, so future emails from this address will go through to the list. - Jim -----Original Message----- From: stefan.van.der.eijk@philips.com [mailto:stefan.van.der.eijk@philips.com] Sent: Tuesday, July 17, 2001 11:57 PM To: dav-dev@lyra.org; w3c-dist-auth@w3.org Subject: [Moderator Action] mod_dav / webdav questions (case sensitiveness / symbolic links) Hello, I hope this is the right forum to ask these questions, if not, please ignore them. At the project I'm working on at the moment we're looking into using webdav for content uploads. We've installed a apache webserver with mod_dav on a solaris box, which works fine (people are quite enthousiastic about it). At the moment we've got a few issues with the mod_dav that I can't find answers to: - Behaviour of mod_dav with symbolic links. In the area's where we want to manage content there are a few symbolic links. These symbolic links do show up (and can be clicked through) with on the "normal" webserver, but when opening the URL in a webfolder (we're using IE5 as a dav client) the symbolic links don't show up. When I enter the URL of the symbolic link in the URL bar of the webfolder, the webfolder of the symbolic link does show up. Is there a way to configure the webserver so that symbolic links do showup in the webfolders? - Case sensitive / case insensitive behaviour. Some of the directories have capital letters, like "NL", these directories show up in lowercase in IE5's webfolder --> "nl". This means that when you click on the "nl" folder it can't be found by the webserver. Can this be considered to be a bug in MS IE5? At the moment we're considering using lowercase for all content, which eliminates this issue. Is this behaviour known and are there any ways to fix it? Kind Regards, met vriendelijke groet, Stefan van der Eijk Philips Corporate/IT Tel: +31 40 27 83966 Building VB-B 086 Fax: +31 40 27 83722 Boschdijk 525 Gsm: +31 6 21 580253 PO Box 90050 Email: stefan.van.der.eijk@philips.com 5600 PB Eindhoven From w3c-dist-auth-request@w3.org Wed Jul 18 14:13:12 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26640 for ; Wed, 18 Jul 2001 14:13:11 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA08725; Wed, 18 Jul 2001 14:12:53 -0400 (EDT) Resent-Date: Wed, 18 Jul 2001 14:12:53 -0400 (EDT) Resent-Message-Id: <200107181812.OAA08725@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA08705 for ; Wed, 18 Jul 2001 14:12:49 -0400 (EDT) Received: from front2.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA32315 for ; Wed, 18 Jul 2001 14:12:49 -0400 Received: from [216.36.75.57] (HELO beaver) by front2.mail.megapathdsl.net (CommuniGate Pro SMTP 3.4.8a) with SMTP id 2506123; Wed, 18 Jul 2001 11:08:10 -0700 From: "Lisa Dusseault" To: "Jim Whitehead" , , "WebDAV" Date: Wed, 18 Jul 2001 11:12:15 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Subject: RE: WebDAV Resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5176 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: Content-Transfer-Encoding: 7bit > So, if you write a server implementation that maps an entire database as a > resource, and maps it to a URL, then yes, it is possible to consider a > database as a whole resource. Similarly, if you write a server > implementation that maps individual database cells to a resource, then > assigns each cell a distinct URL, then it is possible to consider > a database > cell as a Web resource. Although both these are possible, I've always thought that mapping rows to resources and tables to collections was the most useful. The MSDAIPP component used by MS clients (you can see its name in the User-Agent header if you sniff) takes this approach in a way: it presents an OLEDB interface to the client software developer which treats every file and collection as a row. lisa From w3c-dist-auth-request@w3.org Sat Jul 21 22:41:08 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA27663 for ; Sat, 21 Jul 2001 22:41:08 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA24813; Sat, 21 Jul 2001 22:39:07 -0400 (EDT) Resent-Date: Sat, 21 Jul 2001 22:39:07 -0400 (EDT) Resent-Message-Id: <200107220239.WAA24813@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id WAA24791 for ; Sat, 21 Jul 2001 22:38:58 -0400 (EDT) Received: from shell.rawbw.com (root@shell.rawbw.com [198.144.192.42]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA22982 for ; Sat, 21 Jul 2001 22:38:58 -0400 Received: from beaver ([198.144.203.248]) by shell.rawbw.com (8.11.1/8.11.1) with SMTP id f6M2cl842062; Sat, 21 Jul 2001 19:38:47 -0700 (PDT) From: "Lisa Dusseault" To: Cc: "Webdav WG" Date: Sat, 21 Jul 2001 19:38:50 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: Agenda for webdav Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5177 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: Content-Transfer-Encoding: 7bit WebDAV Working Group (webdav) Monday, August 06 at 1530-1730 ============================== Chair: Jim Whitehead (Absent) Lisa Dusseault (Temporary) AGENDA: 1) Chair; agenda bashing 5 min 2) Interop Event Report Larry Masinter 15 min 3) RFC 2518 Issues New issues from Interop: Lisa Dusseault Existing issues discussion: TBD http://www.ics.uci.edu/pub/ietf/webdav/protocol/issues.html 1 hour 4) Access Control status and issues Led by: TBD http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-06.htm 20 min 4) DASL Revival Lisa Dusseault http://www.webdav.org/dasl/protocol/draft-dasl-protocol-00.html 20 min From w3c-dist-auth-request@w3.org Mon Jul 23 07:11:38 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10662 for ; Mon, 23 Jul 2001 07:11:37 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA23963; Mon, 23 Jul 2001 06:05:30 -0400 (EDT) Resent-Date: Mon, 23 Jul 2001 06:05:30 -0400 (EDT) Resent-Message-Id: <200107231005.GAA23963@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA23893 for ; Mon, 23 Jul 2001 06:05:19 -0400 (EDT) Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA30018 for ; Mon, 23 Jul 2001 06:05:19 -0400 Received: from cs.bris.ac.uk (actually host lunaleka.cs.bris.ac.uk) by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Mon, 23 Jul 2001 11:05:17 +0100 Received: from cs.bris.ac.uk (lama [137.222.102.207]) by cs.bris.ac.uk (8.9.3/8.9.3) with ESMTP id LAA01641; Mon, 23 Jul 2001 11:03:44 +0100 (BST) Message-ID: <3B5BF680.D08E6662@cs.bris.ac.uk> Date: Mon, 23 Jul 2001 11:03:44 +0100 From: Bita Shadgar Organization: Bristol Computer Science Dept X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Lisa Dusseault , w3c-dist-auth@w3.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: WebDAV Resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5178 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: Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > So, if you write a server implementation that maps an entire database as a > > resource, and maps it to a URL, then yes, it is possible to consider a > > database as a whole resource. Similarly, if you write a server > > implementation that maps individual database cells to a resource, then > > assigns each cell a distinct URL, then it is possible to consider > > a database > > cell as a Web resource. > > Although both these are possible, I've always thought that mapping rows to > resources and tables to collections was the most useful. The MSDAIPP > component used by MS clients (you can see its name in the User-Agent header > if you sniff) takes this approach in a way: it presents an OLEDB interface > to the client software developer which treats every file and collection as a > row. > > lisa Do you know any software or project which has had such above resource( rows as resources)? I 've looked at webDAV homepage, however I couldn't find. Bita. From w3c-dist-auth-request@w3.org Mon Jul 23 13:36:52 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09518 for ; Mon, 23 Jul 2001 13:36:51 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA18922; Mon, 23 Jul 2001 13:31:22 -0400 (EDT) Resent-Date: Mon, 23 Jul 2001 13:31:22 -0400 (EDT) Resent-Message-Id: <200107231731.NAA18922@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA18894 for ; Mon, 23 Jul 2001 13:31:16 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA16520 for ; Mon, 23 Jul 2001 13:31:15 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA66894; Mon, 23 Jul 2001 13:28:44 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6NHOIq178486; Mon, 23 Jul 2001 13:24:18 -0400 Importance: Normal To: "Clemm, Geoff" Cc: WebDAV X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Mon, 23 Jul 2001 13:12:05 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at 07/23/2001 01:30:41 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5179 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: I'd like to conclude this issue, but I've not heard any anything to suggest that we have agreement. Discussion has been light. Stefan and Lisa, do you have a response to Geoff's response to your postings? Has anyone decided they agree with each another position? Would someone else like to speak up and take/defend a position? J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Mon Jul 23 13:52:07 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10650 for ; Mon, 23 Jul 2001 13:52:06 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA20491; Mon, 23 Jul 2001 13:51:23 -0400 (EDT) Resent-Date: Mon, 23 Jul 2001 13:51:23 -0400 (EDT) Resent-Message-Id: <200107231751.NAA20491@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA20471 for ; Mon, 23 Jul 2001 13:51:19 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA19117 for ; Mon, 23 Jul 2001 13:51:19 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA338540 for ; Mon, 23 Jul 2001 13:48:49 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6NHiNq178490 for ; Mon, 23 Jul 2001 13:44:23 -0400 Importance: Normal To: WebDAV X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Mon, 23 Jul 2001 13:32:01 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at 07/23/2001 01:50:45 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: rfc2818 issue: UNLOCK_BY_NON_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5180 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: << I agree with Lisa that who can unlock a resource should be an access control issue (exposable and controllable through the access control protocol), and not something hard-wired into the locking protocol. >> Lisa, Geoff and Tim have all agreed along these lines and noone has disagreed. My next question is... What should 2518 say then? Nothing and leave a void? Explicitly delegate to the ACL spec? The only suggestion so far is... << I would extend this statement to say that this applies to any use of a lock token on a resource, not just to who can use it for UNLOCK. So I would remove the "only by owner" language in 2518, which states that only the "owner" of a lock token can use it, and replace it with "only a client with sufficient privileges". >> Is this the change to 2518 that we want? Any other suggestions? Let's hear from you? J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Mon Jul 23 14:05:28 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11811 for ; Mon, 23 Jul 2001 14:05:27 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA20658; Mon, 23 Jul 2001 13:58:29 -0400 (EDT) Resent-Date: Mon, 23 Jul 2001 13:58:29 -0400 (EDT) Resent-Message-Id: <200107231758.NAA20658@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA20638 for ; Mon, 23 Jul 2001 13:58:24 -0400 (EDT) Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA19734 for ; Mon, 23 Jul 2001 13:58:24 -0400 Received: from grumman (ip112.indianapolis14.in.pub-ip.psi.net [38.33.128.112]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with SMTP id NAA12212 for ; Mon, 23 Jul 2001 13:58:09 -0400 (EDT) From: "Keith Wannamaker" To: Date: Mon, 23 Jul 2001 12:54:52 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103A38521@SUS-MA1IT01> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5181 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: Content-Transfer-Encoding: 7bit | The current implementations have demonstrated that lock null resources | are not a basis for interoperability. This statement has been mentioned several times, in one form or another, in this thread. Do you have documentation or test cases for these interoperability problems? When I did the initial locknull implementation for mod_dav, it seemed to me that the notion of a lock-null resource as presented in 2518 was very clear and logical. On what have implementors disagreed? It seems to me that we gain more from the work already done and implemented to clarify, if needed, rather than abandon. Keith From w3c-dist-auth-request@w3.org Mon Jul 23 21:44:36 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA07736 for ; Mon, 23 Jul 2001 21:44:35 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA18565; Mon, 23 Jul 2001 21:43:18 -0400 (EDT) Resent-Date: Mon, 23 Jul 2001 21:43:18 -0400 (EDT) Resent-Message-Id: <200107240143.VAA18565@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA18542 for ; Mon, 23 Jul 2001 21:43:13 -0400 (EDT) Received: from shell.rawbw.com (root@shell.rawbw.com [198.144.192.42]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA02695 for ; Mon, 23 Jul 2001 21:43:13 -0400 Received: from beaver ([198.144.203.248]) by shell.rawbw.com (8.11.1/8.11.1) with SMTP id f6O1gQ816820; Mon, 23 Jul 2001 18:42:30 -0700 (PDT) From: "Lisa Dusseault" To: "Jason Crawford" , "Clemm, Geoff" Cc: "WebDAV" Date: Mon, 23 Jul 2001 18:42:25 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5182 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: Content-Transfer-Encoding: 7bit My sense of the room at the Interop was that clients already relied on the ability to LOCK resources which don't previously exist, then do PUT. The only functionality which is under question, IMHO, is: - whether clients can do LOCK then MKCOL (or MKACTIVITY, etc) - whether the null or empty resource goes away when unlocked I'm happy with the current behaviour as specified by RFC2518 -- after all, we implemented it that way. I'm not totally attached to the ability to turn a lock-null resource into a collection, or make it disappear when unlocked. lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Monday, July 23, 2001 10:12 AM > To: Clemm, Geoff > Cc: WebDAV > Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC > > > > > > I'd like to conclude this issue, but I've not heard any anything > to suggest > that we have agreement. Discussion has been light. > > Stefan and Lisa, do you have a response to Geoff's response to your > postings? Has anyone decided they agree with each another position? > Would someone else like to speak up and take/defend a position? > > J. > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Tue Jul 24 04:17:23 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03692 for ; Tue, 24 Jul 2001 04:17:22 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA05542; Tue, 24 Jul 2001 04:16:19 -0400 (EDT) Resent-Date: Tue, 24 Jul 2001 04:16:19 -0400 (EDT) Resent-Message-Id: <200107240816.EAA05542@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA05522 for ; Tue, 24 Jul 2001 04:16:07 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA02899 for ; Tue, 24 Jul 2001 04:16:06 -0400 Received: from maggie [192.168.1.2] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Tue, 24 Jul 2001 10:15:49 +0200 From: "Stefan Eissing" To: "Lisa Dusseault" , "Jason Crawford" , "Clemm, Geoff" Cc: "WebDAV" Date: Tue, 24 Jul 2001 10:15:48 +0200 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: X-MDRemoteIP: 192.168.1.2 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5183 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: Content-Transfer-Encoding: 7bit > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > > My sense of the room at the Interop was that clients already relied on the > ability to LOCK resources which don't previously exist, then do PUT. > > The only functionality which is under question, IMHO, is: > - whether clients can do LOCK then MKCOL (or MKACTIVITY, etc) > - whether the null or empty resource goes away when unlocked > > I'm happy with the current behaviour as specified by RFC2518 -- after all, > we implemented it that way. I'm not totally attached to the > ability to turn > a lock-null resource into a collection, or make it disappear when > unlocked. This summarizes also my ideas. WebDAV should stick to the LOCK behaviour of null-resources, when followed by a PUT. I think there are no interop problems when LOCK->MKCOL is discontinued or when the resource, created by a LOCK on a null-resource, stays after lock timeout. In fact, changing RFC2518 in this way, will make live for server implementors much easier and probably result in more compliant implementations. //Stefan > lisa > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > > Sent: Monday, July 23, 2001 10:12 AM > > To: Clemm, Geoff > > Cc: WebDAV > > Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC > > > > > > > > > > > > I'd like to conclude this issue, but I've not heard any anything > > to suggest > > that we have agreement. Discussion has been light. > > > > Stefan and Lisa, do you have a response to Geoff's response to your > > postings? Has anyone decided they agree with each another position? > > Would someone else like to speak up and take/defend a position? > > > > J. > > > > ------------------------------------------ > > Phone: 914-784-7569, ccjason@us.ibm.com > > > From w3c-dist-auth-request@w3.org Tue Jul 24 04:25:31 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03782 for ; Tue, 24 Jul 2001 04:25:31 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA05884; Tue, 24 Jul 2001 04:24:54 -0400 (EDT) Resent-Date: Tue, 24 Jul 2001 04:24:54 -0400 (EDT) Resent-Message-Id: <200107240824.EAA05884@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA05844 for ; Tue, 24 Jul 2001 04:24:46 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA03554 for ; Tue, 24 Jul 2001 04:24:46 -0400 Received: from maggie [192.168.1.2] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Tue, 24 Jul 2001 10:24:05 +0200 From: "Stefan Eissing" To: "Keith Wannamaker" , Date: Tue, 24 Jul 2001 10:24:04 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: X-MDRemoteIP: 192.168.1.2 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5184 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: Content-Transfer-Encoding: 7bit > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Keith Wannamaker > > | The current implementations have demonstrated that lock null resources > | are not a basis for interoperability. > > This statement has been mentioned several times, in one form or > another, in this thread. Do you have documentation or test cases > for these interoperability problems? One example is Microsoft IIS which does not implement lock-null resources as specified in 2518. E.g. MKCOL will not work and lock-null resources will not disappear after lock timeout. > When I did the initial locknull implementation for mod_dav, it seemed > to me that the notion of a lock-null resource as presented in 2518 > was very clear and logical. On what have implementors disagreed? mod_dav is an excellent implementation. > It seems to me that we gain more from the work already done and > implemented to clarify, if needed, rather than abandon. > The point made is that the specified behaviour might not be worth the effort. Limiting the lock-null requirements could result in making (server) implementations easier without giving up any functionality. The benefit for clients would be that more servers will comply to the spec. //Stefan From w3c-dist-auth-request@w3.org Tue Jul 24 06:23:45 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05660 for ; Tue, 24 Jul 2001 06:23:45 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA10414; Tue, 24 Jul 2001 06:19:50 -0400 (EDT) Resent-Date: Tue, 24 Jul 2001 06:19:50 -0400 (EDT) Resent-Message-Id: <200107241019.GAA10414@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA10393 for ; Tue, 24 Jul 2001 06:19:46 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA12810 for ; Tue, 24 Jul 2001 06:19:46 -0400 Received: from lisa [192.168.1.2] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Tue, 24 Jul 2001 12:19:33 +0200 From: "Julian F. Reschke" To: Date: Tue, 24 Jul 2001 12:19:32 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 X-MDRemoteIP: 192.168.1.2 X-Return-Path: julian.reschke@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: Interop testing and Oracle IFS, was: Oracle IFS vs. Microsoft Webfolders Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5185 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: Content-Transfer-Encoding: 7bit Hi, during the interop testing event, did anybody try to access an Oracle IFS (see [1] for a description of the problems we encountered last month when trying this...). Regards, Julian [1] From w3c-dist-auth-request@w3.org Tue Jul 24 11:22:47 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24381 for ; Tue, 24 Jul 2001 11:22:47 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA27584; Tue, 24 Jul 2001 11:21:55 -0400 (EDT) Resent-Date: Tue, 24 Jul 2001 11:21:55 -0400 (EDT) Resent-Message-Id: <200107241521.LAA27584@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA27564 for ; Tue, 24 Jul 2001 11:21:51 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA16395 for ; Tue, 24 Jul 2001 11:21:52 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id IAA18660 for ; Tue, 24 Jul 2001 08:21:48 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Tue, 24 Jul 2001 08:19:03 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: FW: A query Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5186 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: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: sathyanarayanan_s [mailto:sathyanarayanan_s@infy.com] Sent: Monday, July 23, 2001 3:12 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] A query Hi, I require a clarification in the functioning of the WebDAV. Consider a set up like below : S1 W1 S2 S1 and S2 are two normal servers, while W1 is a webserver with the DAV inculcated. If I want to get a file F1 from W1(at directory D1 say) to S1(at directory D2) I can say : COPY /~D1/F1 HTTP/1.1 Host: www.W1.com Destination: http://www.S1/D2/F1 W1 would then transfer the file from W1 ro S1. What should happen if I want to stream the file from S2 to S1 via W1 ? Would the following transaction be performed by W1 ? COPY /~D1/F1 HTTP/1.1 Host: www.S2.com Destination: http://www.S1/D2/F1 If no, then what should be transaction to be sent across to W1? If yes, then : Would W1 create a file and retain a copy for itself while transferring it to S1 ? Any sort of clarification would be most welcome. Thanks, Sathya From w3c-dist-auth-request@w3.org Tue Jul 24 11:49:47 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26297 for ; Tue, 24 Jul 2001 11:49:46 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA29701; Tue, 24 Jul 2001 11:43:34 -0400 (EDT) Resent-Date: Tue, 24 Jul 2001 11:43:34 -0400 (EDT) Resent-Message-Id: <200107241543.LAA29701@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA29680 for ; Tue, 24 Jul 2001 11:43:30 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37015.rational.com [192.229.37.15]) by tux.w3.org (8.9.3/8.9.3) with SMTP id LAA19593 for ; Tue, 24 Jul 2001 11:43:30 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Tue, 24 Jul 2001 11:50:46 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <36L19PT0>; Tue, 24 Jul 2001 11:50:46 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103B61BFE@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Tue, 24 Jul 2001 11:50:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5187 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: From: Keith Wannamaker [mailto:Keith@Wannamaker.org] | The current implementations have demonstrated that lock null resources | are not a basis for interoperability. This statement has been mentioned several times, in one form or another, in this thread. Do you have documentation or test cases for these interoperability problems? When I did the initial locknull implementation for mod_dav, it seemed to me that the notion of a lock-null resource as presented in 2518 was very clear and logical. On what have implementors disagreed? It seems to me that we gain more from the work already done and implemented to clarify, if needed, rather than abandon. I tried to address these points in my 7/18/01 response to Stefan (included below). To summarize, the interoperability problem can be found in the IIS implementation. It is not a question about the definition of lock null resources in 2518 being unclear (I believe it is very clear), but rather that lock null resources are incompatible with repositories that support access via multiple protocols (which includes most major commercial repositories), since no other protocol supports a "pseudo-resource" of this kind. Since the lock null use cases are easily handled without the use of lock null resources, removing them from the protocol will increase interoperability without losing any functionality. Cheers, Geoff From: Clemm, Geoff [mailto:gclemm@Rational.Com] Sent: Wednesday, July 18, 2001 10:09 AM Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] As an implementor of server and client software using WebDAV, I would have gladly skipped the mechanisms known as lock-null resources. As Geoff pointed out in this thread, there are alternatives for clients to live without them (although not quite as comfortable). It's probably worth noting that a client gains little or nothing from the use of lock-null resources. In the common case, the user has selected either "Open" or "New" from some user interface. In the Open case, the user is expecting an error if the resource does not exist, so having LOCK return 404 actually makes the client protocol simpler. In the New case, the user is expecting an error if the resource already exists, so a PUT/If-None-Match can be used to determine if the resource does not exist, followed by a LOCK to verify the resource can be write locked. In case the user interface does not distinguish between Open and New, the client just follows the LOCK call with a: if status is 404 then PUT/If-None-Match # ignore status from this request LOCK and otherwise uses the exact same code it would have used if lock null resources were supported. (Note: the "PUT" would whatever is the right call to create a null resource of the right type, e.g. MKCOL for collections, MKACTIVITY for activities, or whatever). But the choice to include lock-null has been made in the past and I see more trouble with abandoning it, than keeping it. Every implementation I've seen (and that might be too few) implements lock-null correctly. You need to look at the Microsoft IIS implementation. When a LOCK is applied to an unmapped URI, it just automatically preceded the LOCK with a PUT with a 0 length body. The result is a regular locked resource, not a lock null resource. In particular, MKCOL will fail on that resource, and when you remove the lock, you still have the 0 length resource (i.e. it doesn't disappear, as a lock null resource is required to do). Note: Our implementation is likely to act the same way, probably for the same reasons as Microsoft, i.e. we support multiple protocols accessing our repository, and none of the other protocols have anything remotely resembling lock null resources. Apart from certain software from Seattle based companies: their server has an incomplete implementation, which works only for ordinary resources. It works good enough for the Seattle client software which uses this feature. Now, if WebDAV removes lock-null, every server implementor would have to support it anyway, because 90% of the users use those Seattle clients. I therefore see nothing to gain on the server side by abandoning lock-null. Having your server support the behavior expected by IIS is easy, just automatically create a 0-length resource. It is real lock-null behavior (which is not implemented by IIS) which is the problem. In the revised protocol, we can warn clients about the various ways that existing servers deal with a LOCK applied to an unmapped URI, but could increase interoperability in the future by stating that a LOCK to an unmapped URI SHOULD return a 404. On the client side, lock-null is a comfortable thing to use. So there is nothing to gain either. If you care about interoperability, it is not comfortable to use because it is not implemented uniformly, so you have to special case around the alternative implementations. The client code will be simpler if it just doesn't use lock null resources at all. So, I'd say: let's embrace and extend lock-null resources. Lock-null resources are very unlikely to be embraced by implementors who must care about multiple protocols accessing their repositories (and commercial vendors are almost all in that situation). Any attempt to embrace (much less extend) lock-null resources will result in interoperability problems. If they were the only good way to provide a key client use case, I'd be willing to live with the interoperability problems, but since the lock-null use cases are easily supported without lock-null resources, I see no reason to persist (much less, increase) these problems. Cheers, Geoff From w3c-dist-auth-request@w3.org Tue Jul 24 11:59:56 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27039 for ; Tue, 24 Jul 2001 11:59:56 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA00793; Tue, 24 Jul 2001 11:56:00 -0400 (EDT) Resent-Date: Tue, 24 Jul 2001 11:56:00 -0400 (EDT) Resent-Message-Id: <200107241556.LAA00793@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA00768 for ; Tue, 24 Jul 2001 11:55:55 -0400 (EDT) Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA21399 for ; Tue, 24 Jul 2001 11:55:55 -0400 Received: from grumman (ip189.indianapolis14.in.pub-ip.psi.net [38.33.128.189]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with SMTP id LAA17704 for ; Tue, 24 Jul 2001 11:55:53 -0400 (EDT) From: "Keith Wannamaker" To: Date: Tue, 24 Jul 2001 10:52:38 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Subject: RE: A query Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5188 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: Content-Transfer-Encoding: 7bit | -----Original Message----- | Consider a set up like below : | | S1 W1 S2 | | S1 and S2 are two normal servers, while W1 is a webserver with the DAV | inculcated. | | If I want to get a file F1 from W1(at directory D1 say) to S1(at | directory D2) I can say : | | COPY /~D1/F1 HTTP/1.1 | Host: www.W1.com | Destination: http://www.S1/D2/F1 | | W1 would then transfer the file from W1 ro S1. Yes, assuming S1 supports PUT and W1 supports COPYs onto remote servers. Although this is allowed in the dav spec, Xythos is the only server I know of that has implemented it. | What should happen if I want to stream the file from S2 to S1 via W1 ? | Would the following transaction be performed by W1 ? This is not possible with the current webdav spec. The source file must reside on a DAV-enabled server, or at least one that makes sense of a COPY request. However, Xythos' dav implementation makes this possible by supporting COPY with a Source: header. So you could perform your request with two transactions: COPY /temp HTTP/1.1 Host: www.W1.com Source: http://www.s2.com/D1/F1 COPY /temp HTTP/1.1 Host: www.W1.com Destination: http://www.s1.com/D1/F1 Again, assuming S1 supports PUT and W1 is an Xythos Dav server. Keith From w3c-dist-auth-request@w3.org Tue Jul 24 12:12:05 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28118 for ; Tue, 24 Jul 2001 12:12:04 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA02452; Tue, 24 Jul 2001 12:08:17 -0400 (EDT) Resent-Date: Tue, 24 Jul 2001 12:08:17 -0400 (EDT) Resent-Message-Id: <200107241608.MAA02452@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA02432 for ; Tue, 24 Jul 2001 12:08:13 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37015.rational.com [192.229.37.15]) by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA23053 for ; Tue, 24 Jul 2001 12:08:13 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Tue, 24 Jul 2001 12:14:33 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <36L19R0J>; Tue, 24 Jul 2001 12:14:33 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103B61C15@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV Date: Tue, 24 Jul 2001 12:14:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: A query Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5189 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: From: sathyanarayanan_s [mailto:sathyanarayanan_s@infy.com] Consider a set up like below : S1 W1 S2 S1 and S2 are two normal servers, while W1 is a webserver with the DAV inculcated. What should happen if I want to stream the file from S2 to S1 via W1 ? Would the following transaction be performed by W1 ? COPY /~D1/F1 HTTP/1.1 Host: www.S2.com Destination: http://www.S1/D2/F1 No, the transaction would be performed by www.S2.com (since that is the host you sent it to). W1 is never mentioned in this request, and therefore is not involved in processing it. If no, then what should be transaction to be sent across to W1? Some have asked for a Source: header for COPY to allow you to copy to a WebDAV server (the Destination: header only lets you COPY from a WebDAV server). If both a Source and Destination header were supported at the same time by a server, you could get the functionality you are asking for. But note that a non-WebDAV server does not have collections, so even if you tried to copy something that looked like a collection (e.g. copying /x/y, when there is a resource /x/y/foo.html), unless you are copying from a WebDAV server, you would just copy the content of whatever GET would return from /x/y, and not a collection (or any properties, since only WebDAV resources have properties). I would probably vote against such a Source header for COPY, because of these edge cases around copying a collection, but I could be swayed (:-). Cheers, Geoff From w3c-dist-auth-request@w3.org Tue Jul 24 12:18:03 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28641 for ; Tue, 24 Jul 2001 12:18:03 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA02923; Tue, 24 Jul 2001 12:13:44 -0400 (EDT) Resent-Date: Tue, 24 Jul 2001 12:13:44 -0400 (EDT) Resent-Message-Id: <200107241613.MAA02923@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA02892 for ; Tue, 24 Jul 2001 12:13:39 -0400 (EDT) Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA23746 for ; Tue, 24 Jul 2001 12:13:39 -0400 Received: from grumman (ip189.indianapolis14.in.pub-ip.psi.net [38.33.128.189]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with SMTP id MAA27994 for ; Tue, 24 Jul 2001 12:13:38 -0400 (EDT) From: "Keith Wannamaker" To: Date: Tue, 24 Jul 2001 11:10:22 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103B61BFE@SUS-MA1IT01> Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5190 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: Content-Transfer-Encoding: 7bit | -----Original Message----- | It is real lock-null | behavior (which is not implemented by IIS) which is the problem. Well, IIS 5 & 6 also do not support depth infinity locks. In addition, neither implement tagged-list preconditions correctly. At the interop event, Exchange 2000 was even giving me 424 responses to HEAD requests. The point is, of course, there are plenty of other servers that have implemented locknull correctly and fully. You're throwing away a tremendous amount of work away if you pull it from the spec. The other reason I disagree with dropping it is that there had to be a reason that lock-null was chosen as the solution to the lost update problem rather than the alternatives you suggest. Perhaps someone else can speak to this, as I imagine this road has already been traveled. Keith From w3c-dist-auth-request@w3.org Tue Jul 24 12:28:07 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29343 for ; Tue, 24 Jul 2001 12:28:06 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA04223; Tue, 24 Jul 2001 12:22:35 -0400 (EDT) Resent-Date: Tue, 24 Jul 2001 12:22:35 -0400 (EDT) Resent-Message-Id: <200107241622.MAA04223@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA04203 for ; Tue, 24 Jul 2001 12:22:31 -0400 (EDT) Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA24718 for ; Tue, 24 Jul 2001 12:22:32 -0400 Received: from grumman (ip189.indianapolis14.in.pub-ip.psi.net [38.33.128.189]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with SMTP id MAA00756 for ; Tue, 24 Jul 2001 12:22:31 -0400 (EDT) From: "Keith Wannamaker" To: Date: Tue, 24 Jul 2001 11:19:15 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5191 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: Content-Transfer-Encoding: 7bit Er, 204, whatever :-) Keith | -----Original Message----- | At the interop event, Exchange 2000 was even giving me 424 responses | to HEAD requests. ^^^ From w3c-dist-auth-request@w3.org Tue Jul 24 19:59:54 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02057 for ; Tue, 24 Jul 2001 19:59:54 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA27984; Tue, 24 Jul 2001 19:52:42 -0400 (EDT) Resent-Date: Tue, 24 Jul 2001 19:52:42 -0400 (EDT) Resent-Message-Id: <200107242352.TAA27984@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA27960 for ; Tue, 24 Jul 2001 19:52:38 -0400 (EDT) Received: from gremlin.ics.uci.edu (mmdf@gremlin.ics.uci.edu [128.195.1.70]) by tux.w3.org (8.9.3/8.9.3) with SMTP id TAA08354 for ; Tue, 24 Jul 2001 19:52:37 -0400 Received: from ics.uci.edu ( needles.ics.uci.edu [128.195.20.211] ) by gremlin-relay.ics.uci.edu id aa18672 ; 24 Jul 2001 16:52 PDT Message-ID: <3B5E0A3C.CE030864@ics.uci.edu> Date: Tue, 24 Jul 2001 16:52:28 -0700 From: Joachim Feise Reply-To: jfeise@ics.uci.edu Organization: University of California, Irvine X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,de-DE MIME-Version: 1.0 To: "Julian F. Reschke" CC: w3c-dist-auth@w3.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Interop testing and Oracle IFS, was: Oracle IFS vs. Microsoft Webfolders Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5192 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: Content-Transfer-Encoding: 7bit "Julian F. Reschke" wrote: > > Hi, > > during the interop testing event, did anybody try to access an Oracle IFS > (see [1] for a description of the problems we encountered last month when > trying this...). > > Regards, Julian > > [1] The same issues as you reported. I didn't try OPTIONS, but PROPFIND returns Fri, 20 Jul 2001 19:09:05 GMT ENGLISH getetag_blah Fri, 20 Jul 2001 19:09:05 GMT ... and locking is not supported. Cheers, -Joe From w3c-dist-auth-request@w3.org Wed Jul 25 02:32:11 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02081 for ; Wed, 25 Jul 2001 02:32:11 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA10040; Wed, 25 Jul 2001 02:26:22 -0400 (EDT) Resent-Date: Wed, 25 Jul 2001 02:26:22 -0400 (EDT) Resent-Message-Id: <200107250626.CAA10040@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id CAA10008 for ; Wed, 25 Jul 2001 02:26:17 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37015.rational.com [192.229.37.15]) by tux.w3.org (8.9.3/8.9.3) with SMTP id CAA07632 for ; Wed, 25 Jul 2001 02:26:17 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Wed, 25 Jul 2001 02:33:52 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <36LFAGWY>; Wed, 25 Jul 2001 02:33:52 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103B61DBA@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Wed, 25 Jul 2001 02:33:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5193 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: From: Keith Wannamaker [mailto:Keith@Wannamaker.org] The point is, of course, there are plenty of other servers that have implemented locknull correctly and fully. You're throwing away a tremendous amount of work away if you pull it from the spec. If implementing locknull correctly and fully involved a tremendous amount of work, that is already one strike against it, unless it is required for some important use case. It has been demonstrated that lock null resources are not required for the use case that has commonly been used to motivate their existence. We already have an interoperability problem because of the inherent conflict between lock null resources and multi-protocol repositories, but we have an opportunity to: - free subsequent implementors from the burden of lock null resources - increase interoperability by avoiding an unnecessary construct that has at least one major inconsistent implementation today. The other reason I disagree with dropping it is that there had to be a reason that lock-null was chosen as the solution to the lost update problem rather than the alternatives you suggest. Perhaps someone else can speak to this, as I imagine this road has already been traveled. I believe that the degree to which 2518 will just be carried forward unchanged into the next draft is a striking example of the high quality of work resulting from the IETF process, the WebDAV working group, and the authors of 2518. But there will be some lessons learned in going from proposed standard to draft standard, and I believe that the removal of lock null resources is one of them. Cheers, Geoff From w3c-dist-auth-request@w3.org Wed Jul 25 02:46:16 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02082 for ; Wed, 25 Jul 2001 02:32:11 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA10077; Wed, 25 Jul 2001 02:26:29 -0400 (EDT) Resent-Date: Wed, 25 Jul 2001 02:26:29 -0400 (EDT) Resent-Message-Id: <200107250626.CAA10077@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id CAA10051 for ; Wed, 25 Jul 2001 02:26:24 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37015.rational.com [192.229.37.15]) by tux.w3.org (8.9.3/8.9.3) with SMTP id CAA07635 for ; Wed, 25 Jul 2001 02:26:25 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Wed, 25 Jul 2001 02:33:57 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <36LFAGXC>; Wed, 25 Jul 2001 02:33:57 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103B61DBD@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV Date: Wed, 25 Jul 2001 02:34:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5194 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: From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > I'm not totally attached to the ability to turn a lock-null > resource into a collection, or make it disappear when unlocked. This summarizes also my ideas. WebDAV should stick to the LOCK behaviour of null-resources, when followed by a PUT. I think there are no interop problems when LOCK->MKCOL is discontinued or when the resource, created by a LOCK on a null-resource, stays after lock timeout. In fact, changing RFC2518 in this way, will make live for server implementors much easier and probably result in more compliant implementations. This would be fine with me as well. It basically says that if a LOCK is applied to an unmapped URI, the LOCK is automatically preceded with a PUT with a zero-length body. As Stefan and Lisa say, having a zero length resource remain when the LOCK is removed will not cause a problem with existing clients, and clients that care about IIS already cannot expect to be able to apply MKCOL to a "lock null" resource. If we didn't already have clients that expected a LOCK on an unmapped URI to succeed, I'd prefer to just say that the LOCK just returns 404 on an unmapped URI, but I can live with this compromise proposal. Cheers, Geoff From w3c-dist-auth-request@w3.org Wed Jul 25 11:02:14 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28613 for ; Wed, 25 Jul 2001 11:01:36 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA05527; Wed, 25 Jul 2001 10:56:15 -0400 (EDT) Resent-Date: Wed, 25 Jul 2001 10:56:15 -0400 (EDT) Resent-Message-Id: <200107251456.KAA05527@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA05507 for ; Wed, 25 Jul 2001 10:56:08 -0400 (EDT) Received: from hermes.eurgw.xerox.com (root@hermes.ext.eurgw.xerox.com [212.120.143.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA07292 for ; Wed, 25 Jul 2001 10:56:07 -0400 Received: from eurodns2.eur.xerox.com (eurodns2.eur.xerox.com [13.202.66.10]) by hermes.eurgw.xerox.com (8.9.3/8.9.3) with ESMTP id PAA04274 for ; Wed, 25 Jul 2001 15:55:59 +0100 (BST) Received: from eurgbrbh01.emeacinops.xerox.com (eurgbrbh01.eur.xerox.com [13.202.66.71]) by eurodns2.eur.xerox.com (8.9.3/8.9.3) with ESMTP id PAA21445 for ; Wed, 25 Jul 2001 15:55:57 +0100 (BST) Received: by eurgbrbh01.eur.xerox.com with Internet Mail Service (5.5.2651.58) id ; Wed, 25 Jul 2001 15:55:56 +0100 Received: from gbrwgcbh01.wgc.gbr.xerox.com ([13.200.2.175]) by eurgbrbh01.emeacinops.xerox.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id PPQZPJZZ; Wed, 25 Jul 2001 15:55:50 +0100 Received: by gbrwgcbh01.wgc.gbr.xerox.com with Internet Mail Service (5.5.2650.21) id <3TCTGNZA>; Wed, 25 Jul 2001 15:55:52 +0100 Message-ID: <59697CCC6CE3D411B4CD00805FBB77672875EB@gbrwgcms03.wgc.gbr.xerox.com> From: "Hall, Shaun" To: "'W3C WebDAV Mailing List'" Date: Wed, 25 Jul 2001 15:55:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: Possible minor correction for MOVE Example in RFC 2518 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5195 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: Couldn't see anything about this in the issues list and its minor. RFC2518 Section 8.9.6 Example of MOVE request. In the description below the example, it states "This means that the resource /container/C2/ could not be moved. However because there was an error copying /container/C2, none of the /containerC2's members were copied". Er shouldn't the words "copying" and "copied" in the description be changed to "moving" and "moved" respectively as its a MOVE request ? The MOVE example appears to be a cut/paste/modify of the COPY example in sec 8.8.8, which would explain things. Mmm, when have you seen that before ? Oh yes, writing source code :-) Cheers Shaun Hall Xerox Europe From w3c-dist-auth-request@w3.org Wed Jul 25 12:38:53 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08590 for ; Wed, 25 Jul 2001 12:38:52 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA13205; Wed, 25 Jul 2001 12:35:45 -0400 (EDT) Resent-Date: Wed, 25 Jul 2001 12:35:45 -0400 (EDT) Resent-Message-Id: <200107251635.MAA13205@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA13183 for ; Wed, 25 Jul 2001 12:35:41 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA21585 for ; Wed, 25 Jul 2001 12:35:40 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id JAA22039 for ; Wed, 25 Jul 2001 09:35:42 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Wed, 25 Jul 2001 09:32:57 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: FW: Web Dav Consultant Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5196 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: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: Cindy Larason [mailto:clarason@webmastersvi.com] Sent: Wednesday, July 25, 2001 6:11 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] Web Dav Consultant I need Web Dav on my server, is there anyone here who has done this enough and can help? Email me. I would like to do a phone consultation if possible. From w3c-dist-auth-request@w3.org Fri Jul 27 06:10:53 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04965 for ; Fri, 27 Jul 2001 06:10:53 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA13519; Thu, 26 Jul 2001 21:22:36 -0400 (EDT) Resent-Date: Thu, 26 Jul 2001 21:22:36 -0400 (EDT) Resent-Message-Id: <200107270122.VAA13519@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA13499 for ; Thu, 26 Jul 2001 21:22:32 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA26955 for ; Thu, 26 Jul 2001 21:22:32 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id SAA13658 for ; Thu, 26 Jul 2001 18:22:37 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Thu, 26 Jul 2001 18:19:47 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C115FF.8D6F2600" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: FW: [Moderator Action] Fw: Web Folder Behavior Example Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5197 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: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C115FF.8D6F2600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I have added to the accept2 list. - Jim -----Original Message----- From: Robert Thompson [mailto:rdthomp1@home.com] Sent: Wednesday, July 25, 2001 7:36 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] Fw: Web Folder Behavior Example Can anyone on this list point me to any example code for implementing a Web Folder Behavior? Am I understanding correct that a Web Folder Behavior allows viewing of folders on a server from IE in a customizable way, similar to the way Windows 98 Active Desktop Folders can be customized using thte Web View and Folder HTT's? I've read several articles from MSDN, but have yet to be able to come up with an example. I have a Windows 2000 Advanced Server and I'm working with Windows 98 and 2000 on the client side with IE5. Thanks much for any tips, Robert ----- Original Message ----- From: Jim Whitehead To: Robert Thompson Sent: Wednesday, July 25, 2001 3:50 PM Subject: RE: Web Folder Behavior Example Hi Robert, Well, the best I can do is recommend that you look through MSDN, which you've already done. At this point, I'd recommed that you send a question to the dav-dev and main WebDAV working group lists mailto:w3c-dist-auth@w3.org to see if anyone there has a better idea. - Jim -----Original Message----- From: Robert Thompson [mailto:rdthomp1@home.com] Sent: Tuesday, July 24, 2001 2:53 AM To: ejw@ics.uci.edu Subject: Web Folder Behavior Example Hello Jim, I saw your post on [dav-dev] was wondering if you could point me to any example code for implementing a Web Folder Behavior. Am I understanding correct that a Web Folder Behavior allows viewing of folders on a server from IE in a customizable way, similar to the way Windows 98 Active Desktop Folders can be customized using thte Web View and Folder HTT's? I've read a bunch of articles from MSDN, but have yet to be able to come up with an example. I have a Windows 2000 Advanced Server and I'm working with Windows 98 and 2000 on the client side. Thanks much for any tips, Robert ------=_NextPart_000_0000_01C115FF.8D6F2600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Accidentally caught by the spam filter.  = I have=20 added <rdthomp1@home.com> = to the=20 accept2 list.
 
-=20 Jim
-----Original Message-----
From: Robert Thompson=20 [mailto:rdthomp1@home.com]
Sent: Wednesday, July 25, 2001 7:36 = PM
To: w3c-dist-auth@w3.org
Subject: [Moderator = Action] Fw:=20 Web Folder Behavior Example

Can anyone on this list point me to any = example=20 code for implementing a Web Folder Behavior?=20
 
Am I understanding correct that a Web = Folder=20 Behavior allows viewing of folders on a server from IE in a customizable = way,=20 similar to the way Windows 98 Active Desktop Folders can be customized = using=20 thte Web View and Folder HTT's?
 
I've read several articles from MSDN, = but have yet=20 to be able to come up with an example.  I have a Windows 2000 = Advanced=20 Server and I'm working with Windows 98 and 2000 on the client side with=20 IE5.
 
Thanks much for any tips,
Robert
 
----- Original Message -----=20
From: Jim = Whitehead
Sent: Wednesday, July 25, 2001 3:50 PM
Subject: RE: Web Folder Behavior Example

Hi=20 Robert,
 
Well,=20 the best I can do is recommend that you look through MSDN, which you've = already=20 done. At this point, I'd recommed that you send a question to the = dav-dev and=20 main WebDAV working group lists mailto:w3c-dist-auth@w3.org to see if = anyone there=20 has a better idea.
 
-=20 Jim
-----Original Message-----
From: Robert Thompson=20 [mailto:rdthomp1@home.com]
Sent: Tuesday, July 24, 2001 2:53 = AM
To: ejw@ics.uci.edu
Subject: Web Folder = Behavior=20 Example

Hello Jim,
 
I saw your post on [dav-dev] was = wondering if you=20 could point me to any example code for implementing a Web Folder=20 Behavior.
 
Am I understanding correct that a Web = Folder=20 Behavior allows viewing of folders on a server from IE in a = customizable way,=20 similar to the way Windows 98 Active Desktop Folders can be customized = using=20 thte Web View and Folder HTT's?
 
I've read a bunch of articles from = MSDN, but have=20 yet to be able to come up with an example.  I have a Windows 2000 = Advanced Server and I'm working with Windows 98 and 2000 on the client = side.
 
Thanks much for any = tips,
Robert
------=_NextPart_000_0000_01C115FF.8D6F2600-- From w3c-dist-auth-request@w3.org Sun Jul 29 23:33:51 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14335 for ; Sun, 29 Jul 2001 23:33:47 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA15590; Sun, 29 Jul 2001 23:31:54 -0400 (EDT) Resent-Date: Sun, 29 Jul 2001 23:31:54 -0400 (EDT) Resent-Message-Id: <200107300331.XAA15590@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id XAA15567 for ; Sun, 29 Jul 2001 23:31:49 -0400 (EDT) Received: from shell.rawbw.com (root@shell.rawbw.com [198.144.192.42]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA09165 for ; Sun, 29 Jul 2001 23:31:48 -0400 Received: from beaver ([198.144.203.248]) by shell.rawbw.com (8.11.1/8.11.1) with SMTP id f6U3VX894773 for ; Sun, 29 Jul 2001 20:31:41 -0700 (PDT) From: "Lisa Dusseault" To: "Webdav WG" Date: Sun, 29 Jul 2001 20:31:31 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: Reason for disappearing lock-null resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5198 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: Content-Transfer-Encoding: 7bit I may be smokin' something, or maybe I'm just smokin' -- but I think I reconstructed why lock-null resources were designed to disappear when their locks go away. It's because lock-null resources may be created accidentally, then they may not be removable if the user doesn't have delete permission. Say I'm trying to lock Ch1.doc, but Jim renames it to Intro.doc. If I have write permission in the directory, my innocent lock request will create a Lock Null Resource. Now I try to clean up my mistake -- but Jim hasn't granted me delete permissions on the collections so I can't. Now, since there's a way of saying "LOCK this thingy only if it still exists by the time you get around to processing my request", this motivation may not be a trump. Such a mechanism does exist: use the If header with some handy existence-proving token -- like an ETag! However, clients haven't been told to do this and I betcha very few do. If we think this motivation is important, it may be safer to either keep the magic disappearing lock-null resource behaviour, or make the recommendation to send If header with LOCK whenever locking an existing resource. (I still can't rationalize why you have to be able to turn a lock-null resource into a collection though) Lisa From w3c-dist-auth-request@w3.org Mon Jul 30 22:02:12 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA09136 for ; Mon, 30 Jul 2001 22:02:12 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA20255; Mon, 30 Jul 2001 21:58:04 -0400 (EDT) Resent-Date: Mon, 30 Jul 2001 21:58:04 -0400 (EDT) Resent-Message-Id: <200107310158.VAA20255@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA20232 for ; Mon, 30 Jul 2001 21:57:53 -0400 (EDT) Received: from inet-mail4.oraclecorp.com (inet-mail4.oracle.com [148.87.2.204]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA10257 for ; Mon, 30 Jul 2001 21:57:53 -0400 Received: from gmgw02.us.oracle.com (gmgw02.us.oracle.com [130.35.249.110]) by inet-mail4.oraclecorp.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f6V1p8M25769 for ; Mon, 30 Jul 2001 18:51:08 -0700 (PDT) Received: from oracle.com (ikirnos-pc.us.oracle.com [130.35.68.81]) by gmgw02.us.oracle.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f6V1vLn14846 for ; Mon, 30 Jul 2001 18:57:21 -0700 (PDT) Message-ID: <3B6610D5.92C83A69@oracle.com> Date: Mon, 30 Jul 2001 18:58:45 -0700 From: Ilya Kirnos X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <3906C56A7BD1F54593344C05BD1374B103B61DBD@SUS-MA1IT01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5199 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: Content-Transfer-Encoding: 7bit > This would be fine with me as well. It basically says that if a LOCK > is applied to an unmapped URI, the LOCK is automatically preceded with > a PUT with a zero-length body. As Stefan and Lisa say, having a > zero length resource remain when the LOCK is removed will not cause > a problem with existing clients, and clients that care about IIS already > cannot expect to be able to apply MKCOL to a "lock null" resource. > If we didn't already have clients that expected a LOCK on an unmapped > URI to succeed, I'd prefer to just say that the LOCK just returns 404 > on an unmapped URI, but I can live with this compromise proposal. I agree: my first choice would be for abandoning the concept of a null lock, but if people feel strongly they should be kept, the semantics should be changed to allow the server to create an actual file to track the lock. Among other things, this allows other protocols to have at least a shot at playing nice with DAV locks. This point (interoperability with other protocols) has been brought up a couple of times in this discussion already, and is an important consideration for the server I'm working on (Oracle iFS), and I suspect for others as well. It can't just be ignored. -ilya From w3c-dist-auth-request@w3.org Tue Jul 31 03:01:10 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08336 for ; Tue, 31 Jul 2001 03:01:09 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA04961; Tue, 31 Jul 2001 03:00:19 -0400 (EDT) Resent-Date: Tue, 31 Jul 2001 03:00:19 -0400 (EDT) Resent-Message-Id: <200107310700.DAA04961@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA04931 for ; Tue, 31 Jul 2001 03:00:05 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA03755 for ; Tue, 31 Jul 2001 03:00:05 -0400 Received: (qmail 29882 invoked by uid 0); 31 Jul 2001 07:00:00 -0000 Received: from p3ee2465d.dip.t-dialin.net (HELO lisa) (62.226.70.93) by mail.gmx.net (mail06) with SMTP; 31 Jul 2001 07:00:00 -0000 From: "Julian Reschke" To: "Ilya Kirnos" , Date: Tue, 31 Jul 2001 09:00:00 +0200 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3B6610D5.92C83A69@oracle.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5200 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: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Ilya Kirnos > Sent: Tuesday, July 31, 2001 3:59 AM > To: w3c-dist-auth@w3.org > Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC > > > > This would be fine with me as well. It basically says that if a LOCK > > is applied to an unmapped URI, the LOCK is automatically preceded with > > > a PUT with a zero-length body. As Stefan and Lisa say, having a > > zero length resource remain when the LOCK is removed will not cause > > a problem with existing clients, and clients that care about IIS > already > > cannot expect to be able to apply MKCOL to a "lock null" resource. > > > If we didn't already have clients that expected a LOCK on an unmapped > > URI to succeed, I'd prefer to just say that the LOCK just returns 404 > > on an unmapped URI, but I can live with this compromise proposal. > > I agree: my first choice would be for abandoning the concept of a null > lock, but if people feel strongly they should be kept, the semantics > should be changed to allow the server to create an actual file to track > the lock. > > Among other things, this allows other protocols to have at least a shot > at playing nice with DAV locks. This point (interoperability with other > protocols) has been brought up a couple of times in this discussion > already, and is an important consideration for the server I'm working on > (Oracle iFS), and I suspect for others as well. It can't just be > ignored. Hi. If you happen to work on Oracle IFS, would it be possible to give us some feedback on the WebDAV compliance issues listed in ? Thanks, Julian From w3c-dist-auth-request@w3.org Tue Jul 31 05:00:55 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10177 for ; Tue, 31 Jul 2001 05:00:54 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA14026; Tue, 31 Jul 2001 05:00:20 -0400 (EDT) Resent-Date: Tue, 31 Jul 2001 05:00:20 -0400 (EDT) Resent-Message-Id: <200107310900.FAA14026@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA13993 for ; Tue, 31 Jul 2001 05:00:10 -0400 (EDT) Received: from hermes.eurgw.xerox.com (root@hermes.ext.eurgw.xerox.com [212.120.143.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA13688 for ; Tue, 31 Jul 2001 05:00:10 -0400 Received: from eurodns2.eur.xerox.com (eurodns2.eur.xerox.com [13.202.66.10]) by hermes.eurgw.xerox.com (8.9.3/8.9.3) with ESMTP id KAA01222; Tue, 31 Jul 2001 10:00:02 +0100 (BST) Received: from eurgbrbh01.emeacinops.xerox.com (eurgbrbh01.eur.xerox.com [13.202.66.71]) by eurodns2.eur.xerox.com (8.9.3/8.9.3) with ESMTP id JAA06229; Tue, 31 Jul 2001 10:00:00 +0100 (BST) Received: from gbrwgcbh01.wgc.gbr.xerox.com ([13.200.2.175]) by eurgbrbh01.emeacinops.xerox.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id PPQZ6PJS; Tue, 31 Jul 2001 09:59:58 +0100 Received: by gbrwgcbh01.wgc.gbr.xerox.com with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Jul 2001 10:00:01 +0100 Message-ID: <59697CCC6CE3D411B4CD00805FBB77672875F9@gbrwgcms03.wgc.gbr.xerox.com> From: "Hall, Shaun" To: "'Ilya Kirnos'" , w3c-dist-auth@w3.org Date: Tue, 31 Jul 2001 09:59:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5201 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: Bits snipped, all IMHO. > -----Original Message----- > From: Ilya Kirnos [mailto:ilya.kirnos@oracle.com] > Sent: 31 July 2001 02:59 > To: w3c-dist-auth@w3.org > Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC > > I agree: my first choice would be for abandoning the concept > of a null > lock, but if people feel strongly they should be kept, the semantics > should be changed to allow the server to create an actual > file to track > the lock. I don't think LNRs should be changed at all. You could use a file to track the lock if you wish and you won't be deviating from the RFC. The RFC doesn't place restrictions on implementation (in this case LNRs) - you can basically use whatever you want, so why are you suggesting that the semantics should be changed ? Its an implementation problem, not a protocol problem. > > > -ilya > Regards Shaun Hall Xerox Europe From w3c-dist-auth-request@w3.org Tue Jul 31 05:22:51 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10430 for ; Tue, 31 Jul 2001 05:22:50 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA15219; Tue, 31 Jul 2001 05:22:16 -0400 (EDT) Resent-Date: Tue, 31 Jul 2001 05:22:16 -0400 (EDT) Resent-Message-Id: <200107310922.FAA15219@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA15167 for ; Tue, 31 Jul 2001 05:22:00 -0400 (EDT) Received: from io.mds.rmit.edu.au (io.mds.rmit.edu.au [131.170.70.10]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA15610 for ; Tue, 31 Jul 2001 05:22:00 -0400 Received: by io.mds.rmit.edu.au (Postfix, from userid 301) id 7949249B67; Tue, 31 Jul 2001 19:21:09 +1000 (EST) Date: Tue, 31 Jul 2001 19:21:09 +1000 From: Alan Kent To: w3c-dist-auth@w3.org Message-ID: <20010731192109.K14768@io.mds.rmit.edu.au> References: <59697CCC6CE3D411B4CD00805FBB77672875F9@gbrwgcms03.wgc.gbr.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <59697CCC6CE3D411B4CD00805FBB77672875F9@gbrwgcms03.wgc.gbr.xerox.com>; from Hall, Shaun on Tue, Jul 31, 2001 at 09:59:59AM +0100 Subject: Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5202 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: On Tue, Jul 31, 2001 at 09:59:59AM +0100, Hall, Shaun wrote: > I don't think LNRs should be changed at all. > > You could use a file to track the lock if you wish and you won't be > deviating from the RFC. > > The RFC doesn't place restrictions on implementation (in this case LNRs) - > you can basically use whatever you want, so why are you suggesting that the > semantics should be changed ? > > Its an implementation problem, not a protocol problem. My understanding of the current state of play is that the RFC allows a LNR to be created which may be either a placeholder for a collection or a non-collection resource. Some implementations want to create a temporary file for a lock to store properties or stop other systems behind the scenes creating the same reseource - which wont work because MKCOL will then fail because a file exists. Some existing implementations (I think it was IIS and/or Apache) if you unlock without doing a PUT or MKCOL leave a dead file behind. I think this not conformant to the the RFC. My general feeling was enough people said "LNR should stay", so it had been recommended to change the RFC so that (1) existing implementations could be considered conformant and (2) new implementations could use a file simplifying compatibility with other systems. This is why I thought it had been proposed that the RFC be changed so LNR's are only for PUT and not MKCOL, and so that servers were not *required* to clean up if a LOCK was followed by an UNLOCK without a PUT. The above may be wrong - I don't have the RFC handy. The above is simply what I understood of the current state of play. Alan From w3c-dist-auth-request@w3.org Tue Jul 31 08:48:23 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14340 for ; Tue, 31 Jul 2001 08:48:23 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA24686; Tue, 31 Jul 2001 08:44:44 -0400 (EDT) Resent-Date: Tue, 31 Jul 2001 08:44:44 -0400 (EDT) Resent-Message-Id: <200107311244.IAA24686@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id IAA24666 for ; Tue, 31 Jul 2001 08:44:31 -0400 (EDT) Received: from hermes.eurgw.xerox.com (root@hermes.ext.eurgw.xerox.com [212.120.143.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA03750 for ; Tue, 31 Jul 2001 08:44:30 -0400 Received: from eurodns2.eur.xerox.com (eurodns2.eur.xerox.com [13.202.66.10]) by hermes.eurgw.xerox.com (8.9.3/8.9.3) with ESMTP id NAA28454; Tue, 31 Jul 2001 13:44:20 +0100 (BST) Received: from eurgbrbh01.emeacinops.xerox.com (eurgbrbh01.eur.xerox.com [13.202.66.71]) by eurodns2.eur.xerox.com (8.9.3/8.9.3) with ESMTP id NAA10412; Tue, 31 Jul 2001 13:44:19 +0100 (BST) Received: from gbrwgcbh01.wgc.gbr.xerox.com ([13.200.2.175]) by eurgbrbh01.emeacinops.xerox.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id PPQZ7MLP; Tue, 31 Jul 2001 13:44:18 +0100 Received: by gbrwgcbh01.wgc.gbr.xerox.com with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Jul 2001 13:44:20 +0100 Message-ID: <59697CCC6CE3D411B4CD00805FBB77672875FB@gbrwgcms03.wgc.gbr.xerox.com> From: "Hall, Shaun" To: "'Alan Kent'" , w3c-dist-auth@w3.org Date: Tue, 31 Jul 2001 13:44:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5203 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: Not criticising/bashing the vendors/implementors... > -----Original Message----- > From: Alan Kent [mailto:ajk@mds.rmit.edu.au] > Sent: 31 July 2001 10:21 > To: w3c-dist-auth@w3.org > Subject: Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC > > > On Tue, Jul 31, 2001 at 09:59:59AM +0100, Hall, Shaun wrote: > > I don't think LNRs should be changed at all. > > > > You could use a file to track the lock if you wish and you won't be > > deviating from the RFC. > > > > The RFC doesn't place restrictions on implementation (in > this case LNRs) - > > you can basically use whatever you want, so why are you > suggesting that the > > semantics should be changed ? > > > > Its an implementation problem, not a protocol problem. > > My understanding of the current state of play is that the RFC allows > a LNR to be created which may be either a placeholder for a collection > or a non-collection resource. Agreed. > > Some implementations want to create a temporary file for a > lock to store > properties or stop other systems behind the scenes creating the > same reseource - which wont work because MKCOL will then fail because > a file exists. Implementation problem. The server should delete the file before it creates the collection (assuming all tests have passed). Yes it takes system resources (CPU time etc). Lets remember folks that in one sense, WebDAV turns the web into a writable medium, and writing is slower than reading. > > Some existing implementations (I think it was IIS and/or Apache) if > you unlock without doing a PUT or MKCOL leave a dead file behind. > I think this not conformant to the the RFC. Agreed. In the current spec, the server should delete the file. Again implementation problem. > > My general feeling was enough people said "LNR should stay", so it had > been recommended to change the RFC so that > > (1) existing implementations could be considered conformant and > > (2) new implementations could use a file simplifying compatibility > with other systems. > > This is why I thought it had been proposed that the RFC be changed so > LNR's are only for PUT and not MKCOL, and so that servers were not > *required* to clean up if a LOCK was followed by an UNLOCK without > a PUT. Some people have suggested to do away with LNRs completely, not just for MKCOL. The purpose of LNRs are to "lock the name" (RFC 2518 sec 7.4), which is in line for PUTs and MKCOLs. If you drop support for MKCOLs, then you might confuse readers as you've diluted this statement. What happens if you don't support LNRs for MKCOL? As an example, two requests are submitted by two different users to a server, one to perform a MKCOL (without LNR support) and one to create an LNR (LOCK), both with the same URL. Say the MKCOL is executed first, then the LOCK (LNR) second. The MKCOL succeeds and creates a collection that isn't locked. The LOCK request (attempting to create an LNR) is then performed on this newly created collection. What will happen? Since LOCK requests do not distinguish locking null resources from existing resources, the server will most likely lock the newly created collection. This could cause problems for the user who created the collection because they are not the owner of the lock. The above wouldn't happen if you used LNRs for MKCOL as well, because the 2nd LOCK request would fail. > > The above may be wrong - I don't have the RFC handy. The above is > simply what I understood of the current state of play. > > Alan > Corrections, comments etc welcome. Regards Shaun Hall Xerox Europe From w3c-dist-auth-request@w3.org Tue Jul 31 10:17:24 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17173 for ; Tue, 31 Jul 2001 10:17:24 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA01211; Tue, 31 Jul 2001 10:15:20 -0400 (EDT) Resent-Date: Tue, 31 Jul 2001 10:15:20 -0400 (EDT) Resent-Message-Id: <200107311415.KAA01211@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA01138 for ; Tue, 31 Jul 2001 10:15:01 -0400 (EDT) Received: from shell.rawbw.com (root@shell.rawbw.com [198.144.192.42]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA16697 for ; Tue, 31 Jul 2001 10:15:01 -0400 Received: from beaver ([198.144.203.248]) by shell.rawbw.com (8.11.1/8.11.1) with SMTP id f6VDxK836126; Tue, 31 Jul 2001 06:59:35 -0700 (PDT) From: "Lisa Dusseault" To: "Hall, Shaun" , "'Alan Kent'" , Date: Tue, 31 Jul 2001 06:59:19 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <59697CCC6CE3D411B4CD00805FBB77672875FB@gbrwgcms03.wgc.gbr.xerox.com> Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5204 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: Content-Transfer-Encoding: 7bit > Say the MKCOL is executed first, then the LOCK (LNR) second. The MKCOL > succeeds and creates a collection that isn't locked. The LOCK request > (attempting to create an LNR) is then performed on this newly created > collection. What will happen? Since LOCK requests do not > distinguish locking > null resources from existing resources, the server will most > likely lock the > newly created collection. THIS is, I believe, an actual problem. Even with lock-null resources the way they are, clients MUST be able to tell the difference between a LOCK that created a new thing, and a LOCK that locked an existing thing. There's a simple way to do this: 201 vs. 200. I believe it was only an oversight that the list of error codes for lock does not include 201, and I consider it an errata for 2518. > This could cause problems for the user > who created > the collection because they are not the owner of the lock. Assuming the user could tell if they created a new collection or not -- what's the problem? > The above wouldn't happen if you used LNRs for MKCOL as well, because the > 2nd LOCK request would fail. I do not think that is correct. The second lock request would lock the existing collection -- as you said two paragraphs up. Lisa From w3c-dist-auth-request@w3.org Tue Jul 31 18:02:22 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25802 for ; Tue, 31 Jul 2001 18:02:21 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA25441; Tue, 31 Jul 2001 17:36:35 -0400 (EDT) Resent-Date: Tue, 31 Jul 2001 17:36:35 -0400 (EDT) Resent-Message-Id: <200107312136.RAA25441@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA25421 for ; Tue, 31 Jul 2001 17:36:20 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA04785 for ; Tue, 31 Jul 2001 17:36:20 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA407932; Tue, 31 Jul 2001 17:33:47 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6VLS5A50004; Tue, 31 Jul 2001 17:28:05 -0400 Importance: Normal To: "Hall, Shaun" , "'W3C WebDAV Mailing List'" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Tue, 31 Jul 2001 17:35:47 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at 07/31/2001 05:35:46 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: Possible minor correction for MOVE Example in RFC 2518 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5205 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: Entered on the issues list. I assume no discussion is necessary... ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com "Hall, Shaun" @w3.org on 07/25/2001 10:55:26 AM Sent by: w3c-dist-auth-request@w3.org To: "'W3C WebDAV Mailing List'" cc: Subject: Possible minor correction for MOVE Example in RFC 2518 Couldn't see anything about this in the issues list and its minor. RFC2518 Section 8.9.6 Example of MOVE request. In the description below the example, it states "This means that the resource /container/C2/ could not be moved. However because there was an error copying /container/C2, none of the /containerC2's members were copied". Er shouldn't the words "copying" and "copied" in the description be changed to "moving" and "moved" respectively as its a MOVE request ? The MOVE example appears to be a cut/paste/modify of the COPY example in sec 8.8.8, which would explain things. Mmm, when have you seen that before ? Oh yes, writing source code :-) Cheers Shaun Hall Xerox Europe From w3c-dist-auth-request@w3.org Tue Jul 31 22:44:05 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA18656 for ; Tue, 31 Jul 2001 22:44:04 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA03872; Tue, 31 Jul 2001 22:20:00 -0400 (EDT) Resent-Date: Tue, 31 Jul 2001 22:20:00 -0400 (EDT) Resent-Message-Id: <200108010220.WAA03872@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id WAA03852 for ; Tue, 31 Jul 2001 22:19:56 -0400 (EDT) Received: from io.mds.rmit.edu.au (io.mds.rmit.edu.au [131.170.70.10]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA28970 for ; Tue, 31 Jul 2001 22:19:55 -0400 Received: by io.mds.rmit.edu.au (Postfix, from userid 301) id 8C11F49B67; Wed, 1 Aug 2001 12:19:17 +1000 (EST) Date: Wed, 1 Aug 2001 12:19:17 +1000 From: Alan Kent To: w3c-dist-auth@w3.org Message-ID: <20010801121917.A17914@io.mds.rmit.edu.au> References: <59697CCC6CE3D411B4CD00805FBB77672875FB@gbrwgcms03.wgc.gbr.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <59697CCC6CE3D411B4CD00805FBB77672875FB@gbrwgcms03.wgc.gbr.xerox.com>; from Hall, Shaun on Tue, Jul 31, 2001 at 01:44:18PM +0100 Subject: Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5206 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: On Tue, Jul 31, 2001 at 01:44:18PM +0100, Hall, Shaun wrote: > The purpose of LNRs are to "lock the name" (RFC 2518 sec 7.4), which is in > line for PUTs and MKCOLs. If you drop support for MKCOLs, then you might > confuse readers as you've diluted this statement.... Personally, I am not too stressed whichever way things go - I have not implemented locking yet! :-) Regarding LNR's being dropped - yes, it was suggested, but I think enough people said "it should stay" so that it will not be removed. There was another problem area brought up, which I can appreciate. Its that LOCK for some implementations cannot be guaranteed to be implemented fully and correctly. For example, consider WebDAV being an interface onto a UNIX file system. (In my own case, its on to a database containing web resource objects such as collections and files. Sticking with a UNIX file system is easier to explain.) So there is a WebDAV library sitting above the file system API. Users of WebDAV always come in via the WebDAV library. Other applications however can go directly to the file system. +----------------+ +----------------+ | | | | | Application 1 | | Application 2 | | | | | +----------------+ +----------------+ | | +----------------+ | | | | | WebDAV Layer | | | | / +----------------+ / \ / +----------------+ | | | File System | | | +----------------+ If the WebDAV layer implements LOCK itself, then it can protect a web resource against other WebDAV clients, but it cannot protect itself against other applications going in via a different API. The solution is for the WebDAV layer to translate the LOCK request into a file sytem lock request. Then the lock will be honoured by all applications (not just WebDAV clients). Lock null resources however have unusual semantics in terms of what most other systems implement. I don't think the UNIX file system, for example, has the concept of locking a file name so other applications cannot use it without a file being created. There are possible solutions. For example, create a file, lock it, then if the WebDAV client issues a MKCOL, delete the file and create a directory instead and hope another application does not sneak in with a race condition and create the directory first. (Deleting the file I believe will delete the lock.) But this defeats the purpose of a lock, doesn't it? It does reduce the chance of a race condition, but it is not a guarantee. To summarise: I can implement LNR in the WebDAV layer easily. But as soon as the underlying data store is accessible by an means other than WebDAV, the locking model (for a 100% correct implementation of locks) must be pushed down into a common layer. I believe the problem with the WebDAV LNR is that it is not a commonly implemented scheme for locking by other systems, so it will be hard for implementors to implement correctly according to the spec. The choices (in my opinion) then are (1) Its ok for implementors to not implement locking safely - its just an aid for applications, not something they should rely on. (2) Locking is only to protect against other WebDAV clients and not against anything else (3) WebDAV is only for use when the underlying storage model supports the LNR concept (4) The locking model needs to change I think (3) is not an appropriate choice for WebDAV as it restricts its scope too much (I don't know of any other system that supports LNR). I think (2) is silly - what is the purpose of locking if they don't work? I think the real choices are (1) or (4). With the current WebDAV spec, (1) is the only choice to me. Alan